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-bounces@ietf.org> on behalf of "Andrew Newton (andy)" <andy@hxr.us>
Date: Wednesday, February 28, 2024 at 4:03 AM
To: James Mitchell <james.mitchell@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.mitchell@iana.org<mailto:james.mitchell@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]