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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
