Hi, Kaveh’s note aptly captures the discussion so far. :)
One more input: How about “rdap-base-down” and “rdap-base-up” relations, instead of “rdap-base”? They should help provide direction for a redirect when crossing server boundaries. That way, to Tom’s point, the semantics of “rdap-up” from RFC 9910 can stay as-is. Seems like one could stretch “rdap-up” semantics [1] to cross over to another server upstream but would be unnecessary if “rdap-base-up” suffices. Jasdip [1] https://www.rfc-editor.org/rfc/rfc9910.html#name-rdap-up-2 From: Kaveh Ranjbar <[email protected]> Date: Saturday, July 11, 2026 at 6:40 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [regext] Re: Referrals to holder-designated RDAP servers for subordinate resources (draft-ranjbar-regext-rdap-subordinate-referrals-00) Andy, That fetch-API detail is the nail in the coffin, and a cleaner one than the curl example. If the response type is opaqueredirect and the body is literally null, the browser is simply never going to hand that content to the client, however motivated the person at the keyboard is. So it stops being "awkward in some cases" and becomes "impossible for a large share of real RDAP clients." That is how I should have put it in the first place, so thank you, and I will. I also appreciate you calling out the authority boundary, because that is really the heart of what I care about here. The moment a query stops being answered by the registry's own data and starts being answered by the holder, something real has changed, and I would rather the client noticed that than have it papered over for them. It matters far more for registration data that feeds abuse work and law-enforcement requests than it does for a casual lookup. Your no_redirects idea is a good one, and I think it is basically Tom's disable-redirect flag wearing a different hat, which I take as a sign we are all circling the same answer. It also sits nicely with the way I split this to Tom: rdap-base is just the sign on the covering object saying "there is a subordinate service down here," the redirect or referral machinery is how you actually travel, and something like no_redirects is how a client says "give me the registry's own record too, not only the child's." A client that just wants the quick redirect still gets it. One that wants to see both records can ask for that instead. On the 9082 versus 9910 tension you raised, I think this draft lands roughly where you would want it. Both the up link and the rdap-base down link are things a client chooses to follow, not things that happen to it. Staying inside one authority is fine to do quietly, but crossing out of it, upward or sideways, feels like a call the client should make with its eyes open, and an explicit relation gives the client that choice rather than a redirect making it silently. I will pull all of this into -01 once the submission tool reopens after Vienna. All the best, Kaveh On Fri, Jul 10, 2026 01:33 PM, Andy Newton <[email protected]<mailto:[email protected]>> wrote: Hi Tom, On 7/9/26 11:52 PM, Tom Harrison wrote: >>> 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. It is not an issue of motivation. I pointed out the curl use case because it was easy to demonstrate, but for RDAP clients running in a browser, which are many and popular, this is a big outright limitation. Using the fetch API, you can switch the processing to manual to detect the redirect but you cannot get the content. https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect An opaque-redirect filtered response is a filtered response whose type is "opaqueredirect", status is 0, status message is the empty byte sequence, header list is « », **body is null**, and body info is a new response body info. > > 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. As Kaveh pointed out, there is an authority boundary being crossed. That is an important distinction. I do realize that the RIRs use redirects to deal with transferred resources, and that is technically a cross-boundary redirect. Maybe that wasn't a wise decision in hindsight... And it is probably my fault as I likely was the one who suggested it. Not that the behavior should change now (water under the bridge), but there is a split personality thing going on with the RFC 9082 ip lookup and the RFC 9910 searches, which apparently are not suppose to cross boundaries (sensible for down and bottom, but what about up and top). Perhaps the solution is the counter to the redirects extension... a no_redirects extension. -andy
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
