Andy, Apologies for the slow reply. I like the direction: "related" already carries the meaning of a link to something authoritative elsewhere, and it avoids the argument about what "base" means in RDAP, which was your objection and a fair one. Directional as Jasdip suggested, so rdap-related-down and rdap-related-up, advertised additively while the registry still redirects for transport.
One thing I want to be sure we mean the same way before I change the draft. In my text the target is the base URL of the holder's RDAP service, which the client queries against, and not the subordinate object itself. If rdap-related-down keeps that target and the draft says so plainly, I am happy to take the name in -02. If you had in mind that it points straight at the object, that is a different relation and I think we would want both, so tell me which you meant. Either way I will note it against the issues you opened on the referrals repo, so the naming gets settled in one place. All the best, K. On Thu, Aug 06, 2026 08:49 PM, "Andrew Newton (andy)" <[email protected]> wrote: > Perhaps we can lean on the "related" relationship already present in > the domain space and create "rdap-related-down", etc.... How does that > sound? > > -andy, no hats. > > On Tue, Jul 21, 2026 at 3:01 AM Kaveh Ranjbar > <[email protected]> wrote: > > > > Andy, > > > > Thank you, and I think you have caught a real imprecision in how I > described this, so let me fix it rather than defend it. > > > > You are right that "base" has a settled meaning in RDAP: a URL the > client processes to build a query, not one it simply dereferences. That is > exactly what these relations point at. The target of rdap-base-down is the > base URL of the holder's RDAP service, and a client reaching it constructs > the subordinate query against that base; it does not fetch the link and > expect an object back. So "base" is the correct word, and my earlier > "directly dereferenceable" was the loose part, not the name. I will make > the text say plainly that the target is a base URL the client queries > against, so nothing is left to infer. > > > > On needing something that points directly to the resource: for the case > this draft is scoped to, I think that is the redirect, not a new relation. > A client that wants the specific subordinate object follows the redirect to > it, which is your mechanism, and rdap-base-down is only the discovery > signal that a downstream service exists and where its base is. So I do not > think this use needs a cross-boundary direct-object relation. If other > cases in the referrals work want one, I am glad to help define it, but it > is separable from this. > > > > If, knowing all that, you still read "base" as misleading, I am open to > a stem that better signals a cross-boundary base URL. I would just rather > settle it with you, here and in the issues, than freeze it early. > > > > Thank you also for opening the issues on the referrals repo. That is > exactly where I hoped this would go, and I will follow and work them there, > the naming and the no-redirects extension especially. To keep the on-list > record complete, the points we converged on are folded into a -01 I am > posting today: Jasdip's directional rdap-base-down and rdap-base-up split, > the registry MUST still redirect for transport with the relation advertised > additively, which was Tom's backwards-compatibility point, and the scope > narrowed to the off-bootstrap holder-run case. > > > > All the best, > > K. > > > > On Sat, Jul 18, 2026 12:53 PM, "Andrew Newton (andy)" <[email protected]> > wrote: > >> > >> Hi, > >> > >> I created a bunch of issues in github on what I believe we discussed: > >> > >> https://github.com/gbxyz/draft-ietf-regext-rdap-referrals/issues > >> > >> All that said, I am fine with rdap-base-down/up but I think we need > >> something that can point directly to the resource. If we are saying > >> that rdap-up/down/top/bottom are that direct pointer, my understanding > >> was that those relationships are not expected to cross authoritative > >> boundaries. And I am fine with those relationships staying that way, > >> but we would need a new one. rdap-base-down/up contain the "rdap-base" > >> which, as used with other RDAP terminology, means a URL that the > >> client must process to obtain the full RDAP URL, as opposed to simply > >> dereferencing the URL. > >> > >> My apologies if I am confused or have caused confusion. > >> > >> -andy, no hats > >> > >> On Fri, Jul 17, 2026 at 2:47 PM Kaveh Ranjbar <[email protected]> > wrote: > >> > > >> > Tom, Andy, Jasdip, > >> > > >> > Thank you, all three of you. That was exactly the review I was hoping > for, and it has left the draft in a much better place than it started. > >> > > >> > To capture where we landed so that -01 reflects it: the server MUST > still redirect for transport, so an unchanged client continues to receive > the most-specific record with no change on its side; it MAY additionally > advertise rdap-base-down on the covering object, so a client that cares can > discover the delegation and cross the authority boundary deliberately; and > a no_redirects flag lets a client ask for the registry's own record > alongside the child's. I will take Jasdip's rdap-base-down / rdap-base-up > split, so direction is explicit at the point of use and RFC 9910's rdap-up > stays exactly as it is. Scope stays narrow: the holder-run server below the > covering allocation, off the bootstrap, and not the in-system RIR and NIR > cases, which need none of this. > >> > > >> > On where it lives, I have no strong preference and would rather > follow the chairs: either a section in the referrals draft, or a small > INR-specific document defining rdap-base-down/up and the no-redirect flag. > Happy to go whichever way causes least confusion, and glad to pick it up in > Vienna. > >> > > >> > I will fold all of this into -01 once the submission tool reopens. > >> > > >> > All the best, > >> > Kaveh > >> > > >> > On Thu, Jul 16, 2026 02:41 AM, Tom Harrison <[email protected]> wrote: > >> >> > >> >> Hi Kaveh, > >> >> > >> >> On Wed, Jul 15, 2026 at 05:29:38PM +0100, Kaveh Ranjbar wrote: > >> >> > I think one word has been doing too much work in this exchange, and > >> >> > your LACNIC example is what made it clear to me, so thank you for > >> >> > it. > >> >> > > >> >> > I have not been proposing the relation in place of the redirect. I > >> >> > have been proposing it on top of one. The registry still redirects > >> >> > for transport, so an unchanged client asking for the more specific > >> >> > resource lands on the holder's record exactly as it does today. > That > >> >> > is the whole of your backwards compatibility concern, and I want to > >> >> > meet it head on: the most specific answer stays reachable with no > >> >> > client change. rdap-base-down is not the path to that answer, it is > >> >> > a second, optional thing on the covering object that says a > >> >> > subordinate service exists and lets a client that cares enumerate > >> >> > and cross the boundary deliberately. no_redirects is the third > >> >> > piece, for a client that wants the registry's own record as well as > >> >> > the child's. Redirect for compatibility, relation for discovery, > >> >> > flag for the parent. Not one instead of another. > >> >> > > >> >> > On registro.br, I read that as the in-system case rather than a > >> >> > counter to it. registro.br is a registry, and LACNIC redirects to > it > >> >> > because LACNIC has been configured to: the pointer lives in the > >> >> > system and the bootstrap-plus-redirect chain reaches it. That is > >> >> > exactly the RIR and NIR situation I agreed needs no new machinery. > >> >> > The case the draft is scoped to is narrower: a holder running RDAP > >> >> > for delegations below its own allocation, records the RIR keeps out > >> >> > of its database by design, on a server no one has configured the > RIR > >> >> > to point at. Where the holder does register that pointer with the > >> >> > registry, I am happy for the server to redirect, and to say so with > >> >> > a MUST, which I think is the requirement you asked for earlier. > What > >> >> > the relation adds in that case is only what the bare redirect > cannot > >> >> > give: that a delegation exists at all, and that answering it > crossed > >> >> > out of the registry's own data. > >> >> > > >> >> > So I think we are closer than the last few mails suggest. If I > write > >> >> > -01 as "the server MUST still redirect, and MAY additionally > >> >> > advertise rdap-base-down, with no_redirects available to a client > >> >> > that wants both records," does that resolve the compatibility > >> >> > objection for you? > >> >> > >> >> Yep, that sounds fine to me, thanks. > >> >> > >> >> -Tom > > > > _______________________________________________ > > regext mailing list -- [email protected] > > To unsubscribe send an email to [email protected] >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
