Re: [regext] [Ext] Re: RDAP and link context

[James Mitchell <[e-mail]>]

Thanks for the link, Scott.

It appears that the context was made mandatory because of an interpretation of “according to Section 3 of RFC5988, the members "value", "rel" and "href" are all required.”

This is correct by definition, however fails to consider web linking as a whole. RFC 8288 defines the HTTP Link header and it’s context having a default value (https://datatracker.ietf.org/doc/html/rfc8288#section-3.2). While the context (anchor) can be defined, it also warns that applications might reject links assigned to other resources (other contexts). Note also the third paragraph in the security considerations section that warns about trusting links with explicitly defined anchors/context. Furthermore, appendices A.1 and A.2 of RFC 8288 also describe the link context for HTML and Atom, but note in none of these is the context explicitly defined alongside the definition of the link.

The link context should not have been made mandatory. If you are to fix this, I would suggest text along the lines of:

A link must have a context, a relation type, and a target as described in Section 2 of [RFC8288]. By default, the context is the is the URI associated with the entire JSON response and does not need to be explicitly defined. The "value" JSON value can be used to assign a different context URI, however servers and clients should be aware of Section 3.2 and Section 5 of [RFC8288] when providing assigning different contexts. The JSON name/values of "rel", "href", "hreflang", "title", "media", and "type" correspond to values found in Section 3<https://www.rfc-editor.org/rfc/rfc8288#section-3> of [RFC8288<https://www.rfc-editor.org/rfc/rfc9083#RFC8288>].  A "related" link relation MUST NOT include an "href" URI that is the same as the "self" link relation "href" URI to reduce the risk of infinite client processing loops. Internationalized Domain Names (IDNs) returned in URIs SHOULD be consistently returned in LDH name format to allow clients to process these IDNs according to their capabilities.

Thanks,
James

From: regext <[e-mail]> on behalf of Jasdip Singh <[e-mail]>
Date: Monday, March 4, 2024 at 8:41 AM
To: "Hollenbeck, Scott" <[e-mail]>, James Mitchell <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [regext] [Ext] Re: RDAP and link context

Thanks, Scott. RFC 8288 (obsoletes RFC 5988) also retains this requirement (in section 2).

Jasdip


From: Hollenbeck, Scott <[e-mail]>
Date: Monday, March 4, 2024 at 11:28 AM
To: Jasdip Singh <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [regext] [Ext] Re: RDAP and link context
From: regext <[e-mail]> On Behalf Of Jasdip Singh
Sent: Sunday, March 3, 2024 2:12 PM
To: James Mitchell <[e-mail]>; Andrew Newton (andy) <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [regext] [Ext] Re: RDAP and link context


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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. :))
[SAH] The change was made in version -01 of draft-hollenbeck-regext-rfc7483bis (“Clarified that the "value", "rel" and "href" JSON values MUST be specified in the "links" array.”) Here’s the on-list discussion:

https://mailarchive.ietf.org/arch/msg/regext/kWZ9ix80uaUAHqXjJsf_L2IN-Ys/ [mailarchive.ietf.org]<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/regext/kWZ9ix80uaUAHqXjJsf_L2IN-Ys/__;!!PtGJab4!96Si9ZKlOG3GC7TFJeKZ5lVO-tZO2LtXGwEWvV7bOrVL_bfPOQtHLXY__xfumApzO51K0xaYAgiQmz7v8ru17Il_$>

Blame RFC 5988.

[SAH] Scott