Andy, thank you, this is the grounding I was after. Strong agree on client-friendliness, and it is the design intent: the referral is a plain, directly dereferenceable link to the holder's RDAP base URL for the subordinate resource, followed with the same logic a client already uses for rdap-up or related. No special handling before dereferencing. If a client has to pre-process the link to use it, adoption is dead, and as you note it also collides with how HTTP libraries transparently follow redirects.
That is also why I would rather carry this in a dedicated relation than lean on the broad about from the gTLD profile: about implies no special handling and is informative to the end user, whereas rdap-base's whole job is to say "the authoritative RDAP for resources subordinate to this object lives there, go follow it." Registering it as its own relation makes that explicit and lets a client opt into the walk deterministically. 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. This is the "belongs in the referrals draft as section X" feedback I was looking for. More than happy to write it up that way. Kaveh On Thu, Jul 09, 2026 01:49 PM, Andy Newton <[email protected]> wrote: > 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]
