Early Review of draft-ietf-regext-rdap-referrals-03
review-ietf-regext-rdap-referrals-03-httpdir-early-schwartz-2026-03-10-00

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".

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.
* 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.

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.  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". *
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.