Hi Kaveh, On Mon, Jul 06, 2026 at 05:14:22PM +0100, Kaveh Ranjbar wrote: > The gap, in one paragraph: an RDAP walk from the IANA bootstrap ends > at the most specific object the registry operator's database holds, > the registered domain at a name registry or registrar, the covering > allocation or aggregated assignment at an RIR.
This is not necessarily the case. At APNIC, for example, we have the rdap.apnic.net server for data APNIC hosts directly, and several $nir.rdap.apnic.net servers for data that APNIC mirrors from the NIRs. If a user queries for a resource that has been delegated to an APNIC-region NIR for which APNIC mirrors data, then rdap.apnic.net will respond with an HTTP redirect to the relevant $nir.rdap.apnic.net server. More to the point, while no NIR in the APNIC region has set up their own RDAP server to which we can redirect clients via HTTP, each has the option of doing that, if they would prefer. The obvious concern here is that if a range has been delegated to a member, should a query for that exact range yield the RIR response, or the member's response? At APNIC, we handle this by performing the redirect to the 'member' server, while including the rdap.apnic.net response in the redirect itself, per https://raw.githubusercontent.com/APNIC-net/rdap-redirect-with-content/v1/apnic-rdap-redirect-with-content.txt, so that APNIC's delegation data is available to clients who are interested in it. In other words, it appears that it may be possible to address the use case here by way of HTTP redirects and the redirect_with_content extension, rather than by introducing a new link relation (which has the added problem that existing clients need to be updated to make use of it). On Wed, Jul 08, 2026 at 11:12:44PM +0100, Kaveh Ranjbar wrote: > -01 also (a) carries the relation in both lookup and search > responses, for names and number resources, (b) spells out how a > holder-designated server discovers the registry's base URL for the > reverse "up"/"rdap-up" link, via the RFC 9224 bootstrap registries, > and (c) registers "rdap-base" with IANA. On the RFC 9910 relations specifically, the intention was that the associated links would point to objects hosted by the responding server itself. From section 3.2.1: An INR object value may have a "parent" object and one or more "child" objects. The "parent" object is the next-least-specific object that exists in the relevant registry, while the "child" objects are the next-most-specific objects that exist in the relevant registry. (If it were cross-registry, then server implementors would be stuck trying to merge objects from multiple servers in the multiple-object response cases, and there wasn't an obvious way to deal with that problem.) -Tom _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
