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]
