[regext] Re: Referrals to holder-designated RDAP servers for subordinate resources (draft-ranjbar-regext-rdap-subordinate-referrals-00)

[Kaveh Ranjbar <[e-mail]>]

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)" <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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
>