Note that 9083 can’t be “fixed”. It’s a Standard RFC, not an Internet-Draft. 
Errata can be submitted, but that only applies if there’s an editorial or 
technical error. This sounds more like a desire for clarification, or text that 
describes how to interpret the requirement in an RDAP context. We could have 
done that in 9083, but we didn’t, so here we are. Maybe it can be done in a 
community authored profile document, or a best practice Internet-Draft.



Scott



From: James Mitchell <james.mitch...@iana.org>
Sent: Monday, March 4, 2024 1:59 PM
To: Jasdip Singh <jasd...@arin.net>; Hollenbeck, Scott 
<shollenb...@verisign.com>; a...@hxr.us
Cc: regext@ietf.org
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.

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<https://secure-web.cisco.com/1ozppVd2-WCWhJZEPqmbPWgcIYDxRzOcFlcERhpT7gWFx0HkCpg17dOgAmq4pd7AeuuirbIQ7hccm6J6J_cLFKKsLwd1IRFksNBuzZQkvXkeH_43IEth6Vg2tR3j_av8RTCCEdqNYGkGwjWReoB7nuUZL4ck3ZuhTVhl6R5CA53KUOA7jQAq5J6VmfB83INT6OqtPQVhiytykp017HlhRonTAJaJLWbgcx-zTldAFqkiulAotyeNmdufuraGpfnHYxtP7qb4tkWAMJBzqOxKLm3JmM3h8_N-MswOs1ZtMhBmr7kTvg1uIpeRm7mxfsPAZ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8288%23section-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://secure-web.cisco.com/1vAv7DOFpm75pMgYp5xDFb47-etPvNy009smiEdloud1S7FNWJr9L_c9ckm28fYJdejy0zXjPBqYBIz1niIXIwIkzouP7ZZtTEi-C4nKYgK1KbZb8cMrJtfJkSHNsXo4Yyz8lWqyPl5JQKvsay_8lH3Wef8sIoj1-0861pRNczTwpEK0ssWPvZl3dRSDyjudcqx6pUJZgESitAKrC4m1UI7mS5SubNrXbaFfaxYVSONyjZHBFAt4tvjg7g3KSVi2BzIKHGod8a2YfFtVtwFYFOYpLQjK-UOl3bPiDtU24hVAVD8FcvJv64EintWsHErNi/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8288%23section-3>
 of 
[RFC8288<https://secure-web.cisco.com/1DZSHLoQSR5aol8K1cNIPkC3fYe8fOqWTFygRh13EvJ4hwHq-FgdxnKsVyvOwg5PacMVa_Id9HMtt0gCHK8WKEhQCrV6B8QzypaMUvfBooZKo9ISqdZvlCgzZR1bXhf0O63f-OekTP8he0hVhYR44IvGocF9eU9iNjjmnRLFqas9wTOs1y2gAgHVEtZkyVpRdRnSveboJLiA4yksTQNYeF_EEKDQCdziAoL9Tm5_jUUhET8NfFtb7TgWggpzUQP6t9M9eZBa_0RNX4-BoeFb1-9RM1oxYREZnDdAnmw16ikoVt7lLtLRDkR1uVI4Xx8Z8/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9083%23RFC8288>].
  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 <regext-boun...@ietf.org> on behalf of Jasdip Singh 
<jasd...@arin.net>
Date: Monday, March 4, 2024 at 8:41 AM
To: "Hollenbeck, Scott" <shollenb...@verisign.com>, James Mitchell 
<james.mitch...@iana.org>, "a...@hxr.us" <a...@hxr.us>
Cc: "regext@ietf.org" <regext@ietf.org>
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 <shollenb...@verisign.com>
Date: Monday, March 4, 2024 at 11:28 AM
To: Jasdip Singh <jasd...@arin.net>, james.mitch...@iana.org 
<james.mitch...@iana.org>, a...@hxr.us <a...@hxr.us>
Cc: regext@ietf.org <regext@ietf.org>
Subject: RE: [regext] [Ext] Re: RDAP and link context

From: regext <regext-boun...@ietf.org> On Behalf Of Jasdip Singh
Sent: Sunday, March 3, 2024 2:12 PM
To: James Mitchell <james.mitch...@iana.org>; Andrew Newton (andy) <a...@hxr.us>
Cc: regext@ietf.org
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://secure-web.cisco.com/1I4L7oBl1Q-l3O6qhtdnFkTrEn0VtgAoTQgIChQrQcI3mJoyqNoOPMPT-eN6PaqU5xdCJcu0fWcCBdRoydfNFboRW4O36LQ4KtBlvwekDasiokrE4LyTNSm4r_58ryXFLCTvd4yLic6F_A7aEuYTpGeiucI0l7HaZA_d1JzL319eV9KFRxRFYRaTBl6iXP9g1Q4mA4agQheBexD5J-da9erqxuNa-qii_9Kshy53kQtJTVojcayl7X4OEsNPVKX_HW6C8lfKWexJYGVgsHuSc-F7vAoSrLhMoCTOkNPjv9Ko-hMAgJoMODvMAHsvEaE0s/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FkWZ9ix80uaUAHqXjJsf_L2IN-Ys%2F__%3B%21%21PtGJab4%2196Si9ZKlOG3GC7TFJeKZ5lVO-tZO2LtXGwEWvV7bOrVL_bfPOQtHLXY__xfumApzO51K0xaYAgiQmz7v8ru17Il_%24>



Blame RFC 5988.



[SAH] Scott

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to