On Thu, Jul 09, 2026 at 09:48:49PM +0100, Kaveh Ranjbar wrote: > On Thu, Jul 09, 2026 01:49 PM, Andy Newton <[email protected]> wrote: >> Some comments as I catch up on this... >> >> An "rdap-base" relationship is a good idea to standardize as it >> also appears in the gTLD profile, though that uses the very broad >> "about" relationship. But that profile doesn't specify any special >> handling, so it is mostly for informative purposes to the end-user. >> >> But if you want to be client-friendly, also offer a link directly >> to the resource. Requiring them to do special handling before >> dereferencing blunts adoption. If a client can just re-use the same >> logic to follow "rdap-up" or "related", that is much simpler.
At least for IP resources, it seems like the most client-friendly approach would be either to respond with the relevant object (when there is no subordinate RDAP server), or to redirect (via HTTP 301 or similar) the client to the server that has the relevant object (where a subordinate RDAP server exists). That approach has two main benefits: - It aligns better with the RFC 9224 bootstrap logic, which (for IP resources) permits more-specific entries, and directs clients to go to the server for the most-specific entry, without an intermediate jump through a server with a less-specific entry. - It aligns better with the RFC 9082 query logic, which (again, for IP resources) permits a server to have multiple overlapping entries, and requires the server to return the most-specific entry. This is especially relevant here, because if the registry supports subordinate RDAP server registration per the draft's text, then clients will get different answers depending on whether an account holder is opting for registering subordinate objects within the registry itself, or for registering those objects within a standalone RDAP server (since in the first case, they get the most-specific object, while in the second case, they get a covering object containing a link). Making both cases consistent seems like a good idea. >> Additionally, this has problems at the HTTP layer with redirects. >> Most clients rely on the HTTP libraries to handle redirects and >> therefore won't be able to do any special handling. Which brings >> me to... >> >> On 08-07-2026 8:51 PM, Tom Harrison wrote: >>> 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). >> >> This is not a good idea. While it seems to work on paper, it does >> not work well in practice. If you `curl ... | jq` the data piped is >> the content from the redirect. jq never sees the content in the >> redirect. This is true for "curl -L" (i.e. "follow redirects"), but by default curl will just return the redirect body, so at least in the somewhat unusual case of a motivated user who has access only to curl, it's possible for them to see that content. More relevantly, though, RDAP itself (per earlier comments, and at least as far as IP resources are concerned) is primarily about sending to the client the most-specific available resource. Optimising for that use case seems sensible, particularly when the alternative approach will require client software updates merely to maintain existing expectations around response handling. > And thank you for the redirect-with-content point. You put the > practical case against it better than I did: curl piping to jq only > ever sees the post-redirect body, and any client that lets its HTTP > stack follow redirects, which is most of them, never sees the > registry content carried in the redirect. A link relation the client > chooses to follow keeps the parent's response and the child's > response as two clean, separately addressable documents, which is > what the up and down walk needs. It's not as though automatic redirects of themselves inhibit the retrieval of the record from the parent registry. For example, a parent registry opting to support subordinate RDAP registries along with automatic redirection might implement a flag that disables redirects for a given request. The subordinate registry would then include an "up"-relation link making use of that flag. Such an approach also has the benefit of being more aligned with existing behaviour, and not requiring client software updates. -Tom _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
