Andy, Yes, that is the plan as I understand it, and your second mail is what made it click for me. You asked for a link straight to the resource in your very first mail on this in July, and it took me until now to see why that cannot be the base relation. The explicit redirect has to hand the client the URL of an object, and a base URL can never be that, so the rdap-base relations have no place in a document whose mechanism is a redirect. What crosses the authority boundary there is a direct pointer, and rdap-related-up, -down, -top and -bottom are the right names for it, registered in the redirects draft next to rdap-bootstrap. My subordinate case is then simply a user of it: a registry that knows a holder-designated server answers a redirects0_ref request for rdap-related-down with the holder's object, and keeps redirecting unchanged clients exactly as it does today, which is the requirement Tom held me to.
So there are two families with two different targets, and I was wrong in July to say the redirect alone made the direct pointer unnecessary. The related ones point at an object and can be followed or redirected to. The base ones point at a service, the client builds its query against the target, and that is what discovery and enumeration of a delegation need. On where the base family gets registered, I would go with your instinct and put it in rdap-extensions. A base URL that the client must process is a general RDAP notion and not something specific to holders or to number resources, Section 5.2 there already deals with referrals that need processing, the RPKI draft has the same need behind its rdap-help relation, and as you said at the start the gTLD profile already carries one under the very broad about. That last one also answers my own objection on issue 11, where I argued against a bare rdap-base from my use case only: the undirected form clearly has a home, and I have no objection to it as long as the directional ones are there too. I am glad to send you, Jasdip and Tom text for the five definitions, starting from Section 8 of my -01. The one thing I would ask is that the media type and the rule that the client constructs its query against the target are stated there once, so every extension that uses them inherits the same behaviour. If that lands, my draft gets smaller and better, and closer to what Tom suggested in July, a document for the holder-designated case that still mandates the redirect. It stops registering anything and is written on top of the two families: when a registry advertises which, the redirect that stays mandatory, the reverse link from the holder side and the bound on hops. I will restructure -02 that way once you confirm, and I will mirror this on issues 11 and 12 so the record sits in one place. One question back so I get the timing right. The datatracker shows extensions as waiting for a revised draft in the working group. Is it still open enough to take five link relations, or would you rather I carry the registrations in -02 for now and we move them later? All the best, Kaveh On Thu, Sep 17, 2026 09:03 PM, Andy Newton <[email protected]> wrote: > I just realized I didn't fully go through this... > > On 9/17/26 2:03 PM, Andy Newton wrote: > > Hi Kaveh, > > > > Just for clarity, is this the understanding for the plan? > > > > 1. draft-ietf-regext-rdap-referrals will register "rdap-related-up", > "rdap-related-down", "rdap-related-bottom" and "rdap-related-top". > > Even though the draft name is referrals, it is really doing redirect. The > rdap-base* relationships can't go be used by a redirect and therefore these > should go in this referrals draft. > > > 2. draft-ranjbar-regext-rdap-subordinate (and its successor) will > register "rdap-base", "rdap-base-up", "rdap-base-down", "rdap-base-bottom" > and "rdap-base-top". > > These could also go into the draft-ietf-regext-rdap-extensions draft since > rdap-base is used by many extensions. That might be better. > > -andy, no hats >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
