Re: draft-ietf-regext-rdap-referrals-03 early Httpdir review

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

Received on Tuesday, 10 March 2026 17:03:22 UTC