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. 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 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. 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. 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. All the best, Kaveh 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]
