Hi Pawel, AFAIU, web links and Link headers (RFC 8288) are intended to provide referrals for additional information (read: other related resources) for a resource (context URI) through various target URIs, whereas an HTTP redirect helps reach the resource itself at another location (RDAP Bootstrap scenario).
Efficiently reaching the DNR registrar URI (and for that matter, any other additional information URI) through a redirection when querying a registry is an interesting idea (as you propose below) but it would be good to clarify first what use case(s) the Efficient RDAP Referrals draft is intending to solve. Cheers, Jasdip From: Pawel Kowalik <[email protected]> Date: Friday, August 22, 2025 at 3:29 AM To: Jasdip Singh <[email protected]>, Gavin Brown <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Ext] draft-brown-rdap-referrals and http redirects? Hi Jasdip, All you say is true, however having in mind the defined problem to be solved ("clients just want 1 piece of information: registrar RDAP link; we want to minimise the work server needs to do to deliver this response and likewise the payload size and client response processing") it seems to be oversized if all possible RDAP links need to be always provided. To assure for that server would likely need to do more work compared to providing link(s) of one rel type only. If I would use the conventions from soon-to-be-RFC draft-ietf-regext-rdap-rir-search, it may look like this (generalised to any type of relation): domains/relsearch/<relation>/<domain name> Further generalised <object_type>/relsearch/<relation>/<object_id> In particular for the "registrar" use case it would be: domains/relsearch/related/<domain name> As the registry does not actually have the "related" object returning 302 would be a perfectly valid response aligned with rfc7480 5.2. This will work only if there is only one link of "rel" == "related". Actually I didn't find any normative text that would define that "related" is a link to registrar at all and what cardinality it might have. Overloading a generic relation of rfc4287 shows some downside imho. For ips it would be ips/relsearch/up/<ip> which actually mimics rir-search and makes me wonder whether rir-search would not be returning 302 already in case parent IP would not be in the same registry. Kind Regards, Pawel On 21.08.25 18:04, Jasdip Singh wrote: Hi Gavin, Pawel, The Links header approach seems more equivalent to the current web links use in RDAP responses, vis-a-vis level 3 (HATEOAS) of Richardson Maturity Model. Given we generally have more than one web link in a response -- for “self", “related”, and other relation types. It might also help to consider if the suggested redirection could conflate with the RDAP Bootstrap (RFC 9224) redirections. Jasdip From: Gavin Brown <[email protected]><mailto:[email protected]> Date: Thursday, August 21, 2025 at 11:19 AM To: Pawel Kowalik <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [regext] Re: [Ext] draft-brown-rdap-referrals and http redirects? Hi Pawel, So something like GET /rdap/domain/example.com?redirectToRegistrar=1 which would result in a 302 response? That would certainly work. However I am not sure how well it conforms to HTTP semantics. (I think whatever approach we end up taking will need review by the HTTP folks) G. > On 21 Aug 2025, at 14:41, Pawel Kowalik > <[email protected]><mailto:[email protected]> wrote: > > Hi, > > Maybe a stupid idea, but if the clients are only interested to follow to the > registrar RDAP instead of reading RDAP of the parent registry, why would we > bother with returning any links if the parent RDAP could just return http > redirect? > > Of course this is not a use of redirect as in rfc7480 5.2, so would need a > special request parameter, but will for sure limit the amount to custom code > client needs to implement. > > curl can follow redirects, but cannot follow link headers afaik, not to > mention processing json output (which yes can be done with added tools, but > only over one hop). > > Kind Regards, > > Pawel > > <OpenPGP_0xABB62115F7BCDB04.asc> -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) 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]
