Hi Benjamin,
Thanks for the review.
On 10-03-2026 12:03 PM, Benjamin Schwartz via Datatracker wrote:
Document: draft-ietf-regext-rdap-referrals
Title: Explicit RDAP Redirects
Reviewer: Benjamin Schwartz
Review result: Not Ready
Normally RDAP returns a large JSON object, some elements of which are
hyperlinks. This draft allows the client to specify their interest only in one
of those hyperlinks, with the selected link returned as an HTTP 307 response.
The stated goal of this new flow is to save "time, compute resources and
bandwidth".
Not just 307. This in section 3:
145 1. have an HTTP status code of 301 (Moved Permanently), 302 (Found),
146 303 (See Other), 307 (Temporary Redirect) or 308 (Permanent
147 Redirect, see Section 15.4.9 of [RFC9110]); and
Is 303 generally more appropriate for this usage?
Notes:
* The client doesn't know, a priori, whether a link of the requested type
exists. If it doesn't exist, the client gets a 404. This creates two problems:
1. Efficiency. If the client retries by requesting the full object, as seems
probable, then this flow is a pessimization. 2. Negotiation. The client has
no in-band signal as to whether the server supports this protocol extension.
If it does not, all redirect queries will return 404. This means (a) the
client never learns whether the server supports the feature and (b) the 404
cannot be relied on as evidence of nonexistence.
This is a good point. And I think the following in the draft is wrong:
91 While RDAP supports redirection of RDAP requests using HTTP
92 redirections (which use a 3xx HTTP status and the "Location" header
93 field, see Section 15.4 of [RFC9110]), it is not possible for RDAP
94 servers to know _a priori_ whether a client requesting an RDAP record
95 is doing so because it wants to retrieve a related RDAP record, or
96 its own, so it can only respond by providing the full RDAP response.
97 The client must then parse that response in order to extract the
98 relevant URL from the "links" property of the object.
The client should have a priori knowledge before using this extension, and
there are multiple ways for it to learn this. I think we need to fix this.
* Redirects indicate that "this resource might be available at a different
URI". It's not clear that it makes sense to model the resource in question
(Provider B's RDAP response) as a resource on Provider A's origin.
See my question above about 303.
Suggestions:
* Consider whether some clients would prefer a flow where the request
identifies the preferred link, but the full response is returned if that link
does not exist or the server does not support this feature.
Also a good point. We need to think about this. If I aim an RDAP client at an
RIR and ask for rdap-up, that resource may be on the origin and not somewhere
else.
For example, this
might be implementable using URL query parameters that are ignored if
unrecognized, and/or an Accept header that indicates which response types are
acceptable. * Consider returning the response as an ordinary response body of
type text/plain, text/uri-list, or application/json. This would avoid the
implication that Provider B's RDAP response resource exists on Provider A, and
would offer more flexibility in the kinds of responses that can be represented.
For example, it might become easier to distinguish "that link doesn't exist in
this JSON object" from "I don't recognize what kind of request this is". *
Also a good point. I think the easiest answer is that a 501 means "I don't recognize
this".
Another answer is this:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-x-media-type/
Consider employing JSONPath syntax, or a subset of JSONPath, to express the
query. This would open up a natural path to supporting clients with a
selective interest in any portion of the RDAP response, not only the "links"
element.
No thanks. That would make this a complicated and brittle solution. And I don't
think RDAP server operators would want to do that, as just sending the response
back is easier than hydrating it out of the database, then running a query
against it, and then throwing back an RFC 9083 compliant answer.
-andy, as an individual
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
