Hi Gavin, I've only given this a passing look but have a few comments:
The registrar example is given as domain/link[rel=related]. I assume the use of the related relation is defined in ICANN's RDAP profile; it might be best to be explicit. It is worth noting that the server may not know the link's content-type and therefore cannot be expected to match the requested Accept: header. This may be important where a server uses a relation type for another purpose. You should consider limiting redirects to known/assumed RDAP URLs. If the server doesn't have a RDAP URL for a registrar (or requested relation), how should it respond? Consider the nic.tld names that have a special registrar as an example. I would assume that a 404 would be misleading for a client given it wouldn't know whether the resource or relation does not exist. The path-based approach works where target of the initial redirect is the organization that can answer for the desired object, but not if there is an intermediate organization. This may be outside the design goals, but a hypothetical TLD -> 2LD -> Registrar relationship would see the intent lost on the first redirect, unless the first redirecting server knew the capabilities of the intermediate. Getting outside my knowledge here, there may be such relationships in the number space when considering transfers between RIRs then referrals to LIRs. Repeatedly following some relations would not make sense, e.g. rdap-up. Again, may be outside the goals of this draft. James On 12/16/25, 6:06 AM, "Gavin Brown" <[email protected] <mailto:[email protected]>> wrote: 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] > <mailto:[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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-referrals/__;!!PtGJab4!9PGwa6CqmlTRpSKSbMcOcxH6TDa_KApHOd_eQ99vHmb6uTk-MgYNuM5CO-ReHm08cx79zRi6D7pcC66SAuN5sF56WsajEJc$ > > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-referrals/__;!!PtGJab4!9PGwa6CqmlTRpSKSbMcOcxH6TDa_KApHOd_eQ99vHmb6uTk-MgYNuM5CO-ReHm08cx79zRi6D7pcC66SAuN5sF56WsajEJc$> > [datatracker[.]ietf[.]org] > > There is also an HTML version available at: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-regext-rdap-referrals-01.html__;!!PtGJab4!9PGwa6CqmlTRpSKSbMcOcxH6TDa_KApHOd_eQ99vHmb6uTk-MgYNuM5CO-ReHm08cx79zRi6D7pcC66SAuN5sF56rhoftc0$ > > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-regext-rdap-referrals-01.html__;!!PtGJab4!9PGwa6CqmlTRpSKSbMcOcxH6TDa_KApHOd_eQ99vHmb6uTk-MgYNuM5CO-ReHm08cx79zRi6D7pcC66SAuN5sF56rhoftc0$> > [ietf[.]org] > > A diff from the previous version is available at: > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-referrals-01__;!!PtGJab4!9PGwa6CqmlTRpSKSbMcOcxH6TDa_KApHOd_eQ99vHmb6uTk-MgYNuM5CO-ReHm08cx79zRi6D7pcC66SAuN5sF56FUjBceM$ > > <https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-referrals-01__;!!PtGJab4!9PGwa6CqmlTRpSKSbMcOcxH6TDa_KApHOd_eQ99vHmb6uTk-MgYNuM5CO-ReHm08cx79zRi6D7pcC66SAuN5sF56FUjBceM$> > [author-tools[.]ietf[.]org] > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org <https://www.icann.org> _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
