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> 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 > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
