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]<mailto:[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]
