Hi, 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. 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 any client letting the HTTP library handle redirects, which is most. Even for browser-based clients using the option to get the redirect URL, they cannot get the content. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
