Hi. Did some digging on this.
Right, RFC 7483 had only “href” as a MUST. RFC 7483bis (eventually RFC 9083) additionally made “rel” and “value” as MUST’s. Looks like the “rel” MUST came about because of RFC 8288 mandating so [1], and the RDAP Deployment Findings and Update draft highlighting so [2]. As for making “value” a MUST, the rationale is not very clear from [2]. It even passed the IESG review [3]. (Scott might be able to shed more light on this. :)) Agree that based on the link context (“value”) inconsistencies James highlighted, it’d be good to clarify the “value” MUST now that we are stuck with it. Jasdip [1] https://datatracker.ietf.org/doc/html/rfc8288#section-3.3 [2] https://mailarchive.ietf.org/arch/msg/regext/Hcq5l4FiDYhBeUjOpJ0O1qNnSOE/ [3] https://mailarchive.ietf.org/arch/msg/regext/IZdoJ_qbSvkrbYFOHWnxmcSOmMw/ From: regext <regext-boun...@ietf.org> on behalf of James Mitchell <james.mitch...@iana.org> Date: Friday, March 1, 2024 at 6:57 PM To: Andrew Newton (andy) <a...@hxr.us> Cc: regext@ietf.org <regext@ietf.org> Subject: Re: [regext] [Ext] Re: RDAP and link context Andy, 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) 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. James From: regext <regext-boun...@ietf.org> on behalf of "Andrew Newton (andy)" <a...@hxr.us> Date: Wednesday, February 28, 2024 at 4:03 AM To: James Mitchell <james.mitch...@iana.org> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [Ext] Re: [regext] RDAP and link context Hi James, RFC 7483 did not require the 'value' attribute, however when the standard was revised in RFC 9083 this attribute became required. I believe you are correct that a link context is not well defined. It is supposed to be the scope in which a link is to be understood. In a JSON response full of all sorts of other things (such as an RDAP response), that scope could be seen as the request URI that got that JSON response. However, that is just one interpretation. The new gTLD Response profile makes use of the 'value' attribute as the RDAP base URL for registrars, which I think is also a fair interpretation of the context of a link since the href is a specific URL that is a subset of a large group of URLs in which the base URL is the parent. If we want to start more strictly defining what that value should be, I think the rdap-extensions document is a better place than the rdap-x document. I don't know about making it optional again. Hopefully others who have a clearer recollection of the 7483 -> 9083 transition can provide better context - pun intended. :) -andy On Tue, Feb 27, 2024 at 6:56 PM James Mitchell <james.mitch...@iana.org<mailto:james.mitch...@iana.org>> wrote: Hi all, What is the purpose of the context URI in the links structure? From 9083: The "value" JSON value is the context URI as described by [RFC8288]. The "value", "rel", and "href" JSON values MUST be specified. My understanding is that the context URI is the request URI that generated the JSON response. Implementing this correctly presents problems for a valid server implementations given caching is non-trivial because one object can be located from more than one URI. For example, /domain/EXAMPLE.COM, /domain/example.com, /domain/eXaMpLe.cOm are all different context URIs even though we understand they will return the same object. For a less trivial example, consider a domain object matched by A-labels, U-labels, and any other labels that identify an object via UTS46 or variant processing. I’ve surveyed a few registries and noted inconsistent implementations of the spec: .org – link context is identical to the target for all links .com – link context is present for a singular self link and the context and relation type are absent for links in notices .xyz – link context is absent from all links I am not aware of any specifications where the link context is explicitly defined with the creation/definition of a link (e.g. HTTP link header, w3c HTML5 spec, Atom). Is the link object’s context/value used at all? Is it possible for a future update the RDAP spec to remove the link context, perhaps in RDAP-X? Thanks, James _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!6wtxV-3nYPBVhxPBkz6KCDxx_XA68cXcyj3vYvYB4A_vP10wDBCGSofrmfkjkyJpRUrwWmQU6RvkkMXUjQekng$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!6wtxV-3nYPBVhxPBkz6KCDxx_XA68cXcyj3vYvYB4A_vP10wDBCGSofrmfkjkyJpRUrwWmQU6RvkkMXUjQekng$> [ietf[.]org] _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!6wtxV-3nYPBVhxPBkz6KCDxx_XA68cXcyj3vYvYB4A_vP10wDBCGSofrmfkjkyJpRUrwWmQU6RvkkMXUjQekng$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!6wtxV-3nYPBVhxPBkz6KCDxx_XA68cXcyj3vYvYB4A_vP10wDBCGSofrmfkjkyJpRUrwWmQU6RvkkMXUjQekng$> [ietf[.]org]
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
