Tom, It has been a long time.
First a correction, because you are right and I was wrong to lean on that example. Without -L, curl shows you the redirect body, so a motivated operator with nothing but curl can indeed see the registry's content. I took Andy's point and pushed it further than it deserved. What survives is narrower: clients that delegate redirect handling to their HTTP library, which is most of them, never see the body carried in the 3xx. That is a real limitation of redirect-with-content, but it is not the argument I made. Now the substance, because I think we are solving two different problems and the thread has been treating them as one. Your proposal concerns how the answer is transported: return the object, or redirect to the server that holds it. This draft concerns how a client learns that a subordinate service exists at all. Those are separable, and I do not think they compete. Take the RIR case, which is the one you scoped your argument to. The premise here is that the registry does not hold the per-subordinate detail. Sub-allocation records are kept out of the RIR database on purpose, and the aggregation conventions exist precisely to keep them out. So when a client asks for a more-specific and the registry applies the most-specific-entry rule you cite, the most specific object the registry has is the covering allocation. It cannot return the subordinate object, because the subordinate object is not there. Which means a registry that wants to redirect must first be told, by the holder, where to redirect to. That is the same new piece of holder-designated configuration that "rdap-base" carries. Both designs require the registry to hold exactly the same datum. The only difference is whether it is visible to the client, or consumed silently to produce a 3xx. That difference matters in two ways. Discoverability. If the registry only redirects, a client can never learn that a delegation exists without guessing a subordinate query and seeing where it lands. It cannot ask "what is delegated below this allocation, and to whom". With the link present on the covering object, the answer is one lookup away, and a client that ignores the link is exactly as well off as it is today. Provenance. Under an automatic redirect, a client that did nothing new issues a query to the RIR and receives a document served by a third party. Nothing in that client's model tells it that it crossed an authority boundary. Under a link relation the boundary is explicit: the registry's own record answers the registry's query, and stepping across to holder-asserted data is a decision the client makes. For registration data used in abuse handling and by law enforcement, I would rather that boundary were visible than smooth. On bootstrap alignment. The delegation we are describing is not in the IANA bootstrap and realistically will not be. The bootstrap's more-specific entries are populated from RIR data, not by arbitrary holders, so a holder running RDAP for a sub-allocation inside its own allocation will not appear there. The behaviour you want, sending the client straight to the most specific server, therefore cannot be derived from the bootstrap in this case. It can only be imitated by the registry, out of holder-supplied configuration. That is the line I am trying to draw between a relation that points outward to a service the bootstrap can produce, and one that points to a service it cannot. On consistency, which I think is your strongest point, and I concede it is real. A holder that registers subordinate objects in the registry and a holder that runs its own server do produce differently shaped responses to the same query. But the shape is tracking something true. In the first case the registry is authoritative for those objects. In the second it is not. Smoothing that away with a transparent redirect makes the two look identical at exactly the moment they are most different. And on cost. A flag that disables redirects, plus a subordinate server that emits an "up" link carrying that flag, is a new query parameter, a new extension identifier, and coordinated behaviour at both ends. That may well be the right design, but it is not free of client updates either. If we are comparing, let us compare like with like: both proposals ask a client to learn something new in order to get the whole picture, and both degrade to today's behaviour for a client that learns nothing. So here is where I think this connects, and I would value your read. This draft was written as input to draft-ietf-regext-rdap-referrals, and I would rather its substance were merged there than progressed on its own. That work already defines an explicit redirect mechanism. If "rdap-base" is the advertisement and the referrals draft is the transport, then a registry implementing explicit redirects can do both: carry the link on the covering object, and redirect on the subordinate query, with your disable-redirect flag available to a client that wants the parent's record as well. The numbers case then needs nothing beyond that, and the names case, where there is no covering object and no most-specific rule to lean on, still has a way to express the delegation. Would that split work for you? If so I will make it explicit in -01, which I will post once the submission tool reopens after Vienna, and I will drop any text that reads as though the link relation were an alternative to redirects rather than a companion to them. All the best, Kaveh On Fri, Jul 10, 2026 04:52 AM, Tom Harrison <[email protected]> wrote: > 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]
