Jasdip, Thank you, and you are right about that sentence, so I will drop it.
If rdap-base is simply the base URL of the RDAP service for the context object, then the cross-boundary case is exactly what the directional forms are for. Putting it in the undirected definition blurs the one distinction the family is built on. It also fits the gTLD profile's existing use under about, which is a service pointer and not a claim about authority. The undirected form says only that, and rdap-base-down and rdap-base-up carry the crossing. On your question, yes, and they belong in the redirects draft. Andy's point on the 17th was that an explicit redirect has to hand the client the URL of an object and a base URL can never be that, so rdap-related-up, -down, -top and -bottom are registered there next to rdap-bootstrap, while the rdap-base family goes to extensions. Two families, two kinds of target, two homes. On sequencing I accept your caveat, and the RPKI dependency is the part that decides it. If extensions clears WGLC and IESG first then it is plainly the right home and my draft simply uses both families and registers nothing at all. If it starts to look like slipping, I would rather carry the five in my -02 as a holding position than have the RPKI draft wait on rdap-help, and move them once extensions turns over. Section 8 of my -01 already states that the registrations can move, citing the reconciliation of rdap-base-down with rdap-help as one of the reasons. K. On Mon, Sep 28, 2026 07:21 PM, Jasdip Singh <[email protected]> wrote: > Hi Kaveh, > > Thanks for listing these new relation types. Please see my comments below. > > Jasdip > > *From: *Kaveh Ranjbar <[email protected]> > *Date: *Monday, September 28, 2026 at 12:37 PM > *To: *[email protected] <[email protected]> > *Cc: *Jasdip Singh <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]> > *Subject: *Re: [regext] Re: Referrals to holder-designated RDAP servers > for subordinate resources > (draft-ranjbar-regext-rdap-subordinate-referrals-00) > > Andy, Jasdip, Tom, > > Rather than wait for an answer before making good on what I offered, here > is the text for the five base relations. I built it out from Section 8 of > my -01 and lined it up deliberately against the four object relations in > RFC 9910, so the pattern reads the same and the only thing that changes is > what the target is. > > Relation Name: rdap-base > Description: Refers to the base URL of an RDAP service that holds > registration data related to the context object. The client > constructs queries against the target; the target is not itself > dereferenced to obtain an object. Unlike the object relations of > [RFC9910], the target may be served under a different authority > than the context object. > > [JS] The last sentence might not be right since rdap-base-down should be > able to address this scenario, no? rdap-base is simply informing about the > base URL for the RDAP service in the context URL, IIUC. :) > > Reference: This document > > Relation Name: rdap-base-up > Description: Refers to the base URL of an RDAP service from which > the RDAP parent of the context object can be reached. It does not > alter the semantics of "rdap-up" in [RFC9910], which remains for > navigation to a parent object within a single authority. > Reference: This document > > Relation Name: rdap-base-down > Description: Refers to the base URL of an RDAP service that holds > RDAP child objects of the context object, including objects > delegated below the context object that the covering service does > not hold itself. > Reference: This document > > Relation Name: rdap-base-top > Description: Refers to the base URL of an RDAP service from which > the topmost RDAP parent of the context object can be reached. > Reference: This document > > Relation Name: rdap-base-bottom > Description: Refers to the base URL of an RDAP service that holds > the RDAP child objects of the context object that do not > themselves have child objects. > Reference: This document > > [JS] The rest of the relation types look right. > > Two things to state once at the head of the family than repeat in each > entry: that the target is a URL the client processes to construct a query > and not one it dereferences to get an object back, and the media type a > client should expect from the service it reaches. Put in one place, every > extension that uses the family inherits the same behaviour, and we avoid > five nearly identical paragraphs drifting apart over time. > > [JS] Right. > > The one place I have gone past -01 is top and bottom, which were not in my > text at all. I have written them to mirror RFC 9910 as closely as I can, > the topmost parent and the children that have no children of their own, > with the target being the service rather than the object. If you would > rather register only the directional pair for now and leave those two until > something actually needs them, that suits me, I would sooner the registry > stayed honest than complete. > > [JS] Going with all 5 new rdap-base* relation types now makes sense since > we are addressing hierachical tree for RDAP services. > > My question from the 17th still stands, because it decides what I do next. > The datatracker still shows extensions as waiting for a revised draft in > the working group. Is it open enough to take these, or would you rather I > carry the registrations in -02 for now and we move them once extensions > turns over? I will restructure -02 as soon as I know, and either way it > stops being a document that registers anything and becomes one about the > holder-designated case: which relation a registry advertises, the redirect > that stays mandatory, the reverse link from the holder side, and the bound > on hops. > > [JS] Since rdap-base-down is needed for the RDAP RPKI draft (in lieu of > rdap-help), would recommend moving these to the RDAP Extensions draft. > Beside, some of these you also need for your use cases. This of course > assumes that the RDAP Extensions draft would get out the door first > vis-a-vis WGLC and IESG reviews. :) > > One additional question: Are we still doing > rdap-related-{up|down|top|bottom} relation types and if so, which spec > would contain them? > > > On Thu, Sep 17, 2026 09:36 PM, Kaveh Ranjbar <[email protected]> > wrote: > > 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]
