Pawel, Your zone-cut point is the right one to press on, and I think it is where rdap-base shines rather than where it struggles.
You are correct that a genuinely multi-level delegation has to be walked one authority boundary at a time, and that bar.foo.gov.example resolves cleanly only if .gov.example advertises the cut down to foo.gov.example, and foo.gov.example advertises the cut down to the holder. That is not an accident of the design, it is the design. rdap-base is meant to be the RDAP analogue of an NS delegation: it marks the RDAP zone cut in-band, on the covering object, at exactly the boundary where authority changes. A client that follows it never has to consult a public suffix list or any other out-of-band heuristic to find where the cut is, because each authoritative server states its own cut. Clients falling back on the PSL to locate the boundary is precisely the failure mode the explicit relation removes. Two things keep that from becoming a burden in the common case. First, the ordinary single delegation, registry to holder, is one hop rather than a label-by-label descent: the client reaches the registry through the RFC 9224 bootstrap, gets the most specific object the registry actually holds, and the link is on that object. Only real nesting, a sub-registry beneath a registered domain that itself delegates further, produces multiple hops, and there each hop advertising rdap-base is what makes the descent deterministic instead of heuristic. Second, a client that does not implement rdap-base is exactly as well off as it is today: it stops at the covering object, having lost nothing. On provisioning we are fully aligned, and thank you for saying it plainly: out-of-band is the right answer until demand justifies touching a provisioning protocol. Your [xxx].de sub-zone operators are the latent case exactly. The draft deliberately does not ask them, or DENIC, to change how anything is provisioned; it only defines the discovery relation so that if one of those operators does stand up a conformant RDAP server, there is a standard in-band way for the parent object to point at it, rather than the knowledge living in someone's script. Whether any of them run RDAP today is the honest empirical question, and I would not build the case on a promise of demand. I would rather have the relation defined than need it and find it absent. All the best, Kaveh On Fri, Jul 10, 2026 05:21 PM, Pawel Kowalik <[email protected]> wrote: > Hi Kaveh, > > On 09.07.26 22:38, Kaveh Ranjbar wrote: > > Pawel, thank you, and you have the shape right: a holder that serves > > registration data for resources subordinate to a registry object, > > names below a registered domain, or more-specifics below an > > allocation, from its own conformant RDAP server, whether that holder > > is a public sub-registry or a private one. > > > > On the step you flag as tricky, I think it is actually the point the > > design turns on, so let me be precise. The referral is not attached to > > a query for bar.foo.example; it is attached to foo.example, the object > > the .example registry does hold. A client that wants bar.foo.example > > walks to the most specific object the registry answers, foo.example, > > reads the rdap-base link there, and follows it down to the holder's > > server, which serves bar.foo.example and links back up to foo.example > > with an "up" link (for a domain object; "rdap-up" for number > > resources). So the registry returning 404 for bar.foo.example is > > expected and off the path: the chain is parent object, then rdap-base > > referral, then holder, and it never depends on the registry answering > > for a name it does not hold. That is what keeps it loop-safe and lets > > both ends stay authoritative for what they actually maintain. > > PK> ok, this means the client needs to traverse the tree from the top. > This also means that TLD registries running also 3rd level would have to > add the same mechanism to direct from .gov.example response to itself so > that RDAP client resolving bar.foo.gov.example can ask .gov.example, > foo.gov.example and finally land with a server of foo.gov.example > knowing bar.foo.gov.example. Otherwise clients would need heuristics or > other sources (e.g. public suffix list) to know the right "RDAP zone cut". > > > [...] > > The one genuinely open piece is your last one: how the registry comes > > to hold the holder's referral URL in the first place. That is a > > provisioning question, and I have deliberately kept it separate from > > the discovery semantics in the draft. It could be an EPP extension, a > > registration-time attribute, or an out-of-band arrangement; in the > > running code it is provisioned programmatically. I think the WG can > > settle the discovery relation first and treat provisioning as its own > > layer, and I would value your and DENIC's view on which provisioning > > path is realistic for a name registry. > > PK> I agree, the provisioning is a different layer. This can be > out-of-band until the use case becomes popular to justify extending of > provisioning protocol. There are some operators running [xxx].de as a > sub-zones in registry-like manner. So far we didn't hear of such need > and tbh I don't know if they even run an RDAP server. > > Kind Regards, > Pawel > >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
