From: "Andrew Newton (andy)" <a...@hxr.us> Date: Monday, March 4, 2024 at 12:23 PM To: James Mitchell <james.mitch...@iana.org> Cc: "regext@ietf.org" <regext@ietf.org> Subject: Re: [Ext] Re: [regext] RDAP and link context
On Fri, Mar 1, 2024 at 6:57 PM James Mitchell <james.mitch...@iana.org<mailto:james.mitch...@iana.org>> wrote: The new gTLD Response profile (https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf) says … “a value with the RDAP lookup path that generated the RDAP response.”, requirements 2.6.3 and 2.10. Unless you are referring to another document, this is quite different from the RDAP base URL. I would interpret requests under this profile for /domains/EXAMPLE.COM and /domains/example.com to set the link context to /domains/EXAMPLE.COM and /domains/example.com respectively (or less contrived, lookups for /domain/xn--bcher-kva and /domain/b%C3%BCcher to have different link contexts) I was thinking of 2.4.6 which sets the link context to the Base URL of the registrar, which seems mighty useful. I agree with your interpretation of 2.6.3 and 2.10 It seems a shame that the spec did not allow the undefined link context to be interpreted as the request URI. However we are where we are and the link context is now mandatory. If someone can shed some light on the utility of the link context then I can look to support that with our server. Otherwise I’ll likely hold onto on the RFC 7483 requirements for links. What's the issue with setting it to the request URI? The server can’t pre-compute a response where multiple URIs map to one object – one has to patch any pre-computed response prior to sending back on the wire. This is a use of compute resources for what seems to be no benefit. I could have the response link the request.path to a canonical path, and anchor links of that canonical path, but this seems like busywork. -andy
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
