Hi Mario, > On 17 Dec 2025, at 4:42 pm, Mario Loffredo <[email protected]> wrote: > > Hi Gavin, > I reviewed the draft and here is my feedback: > 1) I believe "related" is too general a link relation type to trigger a > referral request from a domain registry to a domain registrar. To avoid > ambiguity, it would be appropriate to register a specific relation type at > IANA, such as "rdap-sponsor." It might also be helpful for servers to return > a consistent return code; that is, an object could contain multiple "related" > links but only one "rdap-sponsor" link. Therefore, the request for that link > could succeed or fail. The language in Section 3 does not help to clarify the > problem, since servers may apply different policies in returning any of the > links with the same relation type.
This draft does not currently *require* the use of "related" links for registrar RDAP records. It could define a new relationship type, but links with the "related" type (along with the "application/rdap+json" media type) are already widely supported on both client and server. > 2) Because the RDAP response to a referral request should not include a body, > using the GET method to receive a 200 return code as described in this draft > would not conform to its use in RDAP under Section 4.1 of RFC7480. > The HEAD method also could not be used, as it would need to determine the > existence of the data—in this case, the desired link—but not to return the > link itself. If, however, the server returns a 301/302 return code, using the > Location header for redirection would not comply with Section 5.2 of RFC7480. > This section refers to redirecting the original query, whereas in this case, > the Location header would contain a different one. > Perhaps a solution could be to use the 303 return code provided by section > 15.4 of RFC9110: > Redirection to a different resource, identified by the Location header field, > that can represent an indirect response to the request, as in the 303 (See > Other) status code. The 200 status codes in the examples are typos that will be fixed. The text of the draft does not contemplate using 200. Thanks, G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
