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.
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
<https://www.rfc-editor.org/rfc/rfc9110.html#field.location> header
field, that can represent an indirect response to the request, as in the
303 (See Other) <https://www.rfc-editor.org/rfc/rfc9110.html#status.303>
status code.*
Best,
Mario
Il 16/12/2025 15:03, Gavin Brown ha scritto:
Greetings,
As discussed during the meeting in Montreal, here is an updated version of the
RDAP referrals draft, which switches to a path-based approach.
This draft also discusses how the server selects *which* link to use when
providing the referral, which was one of the open items that we presented on.
Feedback greatly appreciated!
Thanks,
Gavin.
On 16 Dec 2025, at 13:43,[email protected] wrote:
Internet-Draft draft-ietf-regext-rdap-referrals-01.txt is now available. It is
a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
Title: Efficient RDAP Referrals
Authors: Gavin Brown
Andy Newton
Name: draft-ietf-regext-rdap-referrals-01.txt
Pages: 7
Dates: 2025-12-16
Abstract:
This document describes an RDAP extension that allows RDAP clients to
request to be referred to a related RDAP record for a resource.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-referrals/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-referrals-01.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-referrals-01
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
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 [email protected]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
