Hi Gavin, Andy,
After perusing the draft more carefully, wanted to share few more observations (in no particular order): "/referrals0_ref/<relation>/<lookup path>” … Should this not be "referrals0_ref/<relation>/<lookup path>” without the leading slash since we want this path to be relative? In case there were a successor extension in the future (say, “referrals1”), would it help to return the “referrals0” extension id in the returned Content-Type header for the redirection response, as part of the “exts_list” parameter value for “application/rdap+json”? Since this is more likely for more generic relation types (say, “alternate” or “related”), how should the server behave when there is a possibility to pick from multiple links for the given relation type? Do we want to allow “self” in <relation> since (IIUC) it could become an attack vector (redirection loop)? In examples, replace 200 with 3xx? “Servers which implement this specification MUST include the string "referrals0" in the "rdapConformance" array in all RDAP responses.” … Should this exclude search responses given the applicability of this extension to just lookups? Including in the help response should be ok. In the returned Location header, could a relative URI be returned? Looks like it could if the “href” for the selected link was so. Not sure if it would help to include such an example for clarity. Thanks, Jasdip From: Gavin Brown <[email protected]> Date: Tuesday, December 16, 2025 at 9:06 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [regext] Re: [Ext] I-D Action: draft-ietf-regext-rdap-referrals-01.txt 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 to [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 to [email protected]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
