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.