[regext] Re: [Ext] draft-brown-rdap-referrals and http redirects?

[Pawel Kowalik]

Hi Jasdip, I am referring to the problem definition from Gavin’s presentation in Bangkok [1]. [1] https://datatracker.ietf.org/meeting/122/materials/slides-122-regext-efficient-rdap-referrals-00.pdf Kind regards Pawel Kowalik  On 22. Aug 2025, at 16:34, Jasdip Singh <jasd...@arin.net> wrote:  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 <kowa...@denic.de> Date: Friday, August 22, 2025 at 3:29 AM To: Jasdip Singh <jasd...@arin.net>, Gavin Brown <gavin.br...@icann.org> Cc: regext@ietf.org <regext@ietf.org> 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 <gavin.br...@icann.org> Date: Thursday, August 21, 2025 at 11:19 AM To: Pawel Kowalik <kowa...@denic.de> Cc: regext@ietf.org <regext@ietf.org> 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 <kowa...@denic.de> 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 -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org

_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org