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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 04 March 2024 19:53 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5577C157931 for <regext@ietfa.amsl.com>; Mon, 4 Mar 2024 11:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5XttmYG-tph for <regext@ietfa.amsl.com>; Mon, 4 Mar 2024 11:53:30 -0800 (PST)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD5DC1524DC for <regext@ietf.org>; Mon, 4 Mar 2024 11:53:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=29612; q=dns/txt; s=VRSN; t=1709582010; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SvDeNARGCRm7brkmobI/TlSNjxl6ApQBG44fnxkaj3Y=; b=m3sm+3Aav8HjAUthq3jFo+2QKlbdesQTGxFC8jT09CcHCqjqP2d/F5h3 xk9MNKu7XxOJzntuk57OxAwa6naVaufLnR/UfUI1jbMkf6RRtCpqGrqXd hvxA37zyAVVkYZYW1tm2D4v8H6jZujzE6Md1j1dQ4fYABnYfQrRObshKP Vm/XwZp05eq3RYArl9E8Aqo/FEGzvTgYoj3Hzx5OHD1KSMRiUGpoEi7tF 72aMEnzg7G6iFISY9P4JA8Yx9xFKKP0EOxs5XqNfFcx+fUK27sAakk1Yn ipqFbbeDVSAnt0SZ2H1IRRfnCRmLq0B/XWtnZqSPEzk/JP/8/cCgsarQK g==;
X-CSE-ConnectionGUID: eOpuwaVdSpCZPq3sP7YWmg==
X-CSE-MsgGUID: t1/btlwNQkSl/urFnZhUig==
X-ThreatScanner-Verdict: Negative
IronPort-Data: A9a23:mSPbXq42Kd4HzRXeodKNGgxRtC7GchMFZxGqfqrLsTDasY5as4F+v mFOUT/XOvfcMWr0ct1xYIm+8htQ6JbRy9JrTQpkryAxEysa+MHIO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRG/ykTraCY3gtLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMS31GWNglaYCUpKrfrdwP9TlK6q4m9A5QRiPasjUGL2zBH5MrpOfcldEFOlGuG4LsbiL 87fwbew+H/u/htFIrtJRZ6iLyXm6paLVeS/oiI+t5qK23CulQRrukoPD8fwXG8M49m/t4sol IgS78zYpTABZcUgkMxFO/VRO38mYf0eoNcrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXAD0qdg2cjty6+6qQeNF13d8bc/jUOYxK7xmMzRmBZRonabr5Zfz1w/JohG52mMtJB+6Yb sZfdyB0alLLZBgn1lU/Ucp4xbjzwCCiKHsE+Dp5poJui4TX5Bdx17zpPdzfd9eJbdtYhEeDp 23AuW/+B3n2MfTFmGHfrCr32ocjmwvnAcUYCLmn0Mdpu1nU23Y9Di8WaFq09KzRZkmWHog3x 1Yv0ignqKUpskmqUtL9Uhm8iH+NuBdaXMBfe8U44RqBy7LPyw+DB25CSDNdAPQvssMnbTw6z BmUhLvBHzFgva2JYXOQ6rnSqim9URX5NkcIfyldUg0I84G65ZotlFTKT80mGqnzhMfzQHfu2 SuM6iM5gt3/kPI26klyxnif6xrEm3QDZlddCtn/No590j5EWQ==
IronPort-HdrOrdr: A9a23:i1jZiaoh6nWE+jYSlMK9+icaV5oHeYIsimQD101hICG9Kvbo8/ xHnJwguSMc+wxhP03I+OrwQ5VoLkm9yXcY2+Ms1PKZLWzbUQiTXftfBOnZsl7d8kTFn4Y36U 4jSdkdNDSaNzdHZLPBgTVQZOxP/DDoys2VbKzlvhFQpElRGthdBilCe36mLnE=
X-Talos-CUID: 9a23:wWETx2vhj15kX3lbE+QyzVSk6IsoVWXA037uL3SgIlRRUeaOcQChx6Zrxp8=
X-Talos-MUID: 9a23:Zrf7QgwTSBhDVbSLVmkbdnHwdk+aqLj3T0oRlYoggsq/MWttIRmbvjSKQ4Byfw==
X-IronPort-AV: E=Sophos;i="6.06,204,1705381200"; d="scan'208,217";a="29326034"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Mar 2024 14:53:28 -0500
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2507.035; Mon, 4 Mar 2024 14:53:28 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "james.mitchell@iana.org" <james.mitchell@iana.org>, "jasdips@arin.net" <jasdips@arin.net>, "andy@hxr.us" <andy@hxr.us>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] [Ext] Re: RDAP and link context
Thread-Index: AQHabZ689/3xwo9o8Ee9SAuBaG9Vg7EnxTNggABY5wCAACZugP//ulmQ
Date: Mon, 04 Mar 2024 19:53:28 +0000
Message-ID: <87be0c6ad418460b9e98dcfc752ac81e@verisign.com>
References: <E057A842-3FF6-4A0A-BD95-9CB8C047BBE9@iana.org> <CAAQiQRco_P-U2EzwXPOudpohUvO0kNhbBkkFBGKbrCG+ANUogA@mail.gmail.com> <A56D1534-E81E-4783-A731-B2ADC1D0E5EA@iana.org> <LV3PR15MB6453ADFFF1B4935F50F26444C95C2@LV3PR15MB6453.namprd15.prod.outlook.com> <59520332939e4bfcb6c64802f08226e5@verisign.com> <LV3PR15MB6453F00DE23B54A4D3145B9EC9232@LV3PR15MB6453.namprd15.prod.outlook.com> <96CE291D-4D92-48A2-A936-8F9625E77F49@iana.org>
In-Reply-To: <96CE291D-4D92-48A2-A936-8F9625E77F49@iana.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_87be0c6ad418460b9e98dcfc752ac81everisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/uUAkvvH--3cnRRwehkuB5OZZKAM>
Subject: Re: [regext] [Ext] Re: RDAP and link context
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 19:53:34 -0000

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.mitchell@iana.org>
Sent: Monday, March 4, 2024 1:59 PM
To: Jasdip Singh <jasdips@arin.net>; Hollenbeck, Scott <shollenbeck@verisign.com>; andy@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-bounces@ietf.org> on behalf of Jasdip Singh <jasdips@arin.net>
Date: Monday, March 4, 2024 at 8:41 AM
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, James Mitchell <james.mitchell@iana.org>, "andy@hxr.us" <andy@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 <shollenbeck@verisign.com>
Date: Monday, March 4, 2024 at 11:28 AM
To: Jasdip Singh <jasdips@arin.net>, james.mitchell@iana.org <james.mitchell@iana.org>, andy@hxr.us <andy@hxr.us>
Cc: regext@ietf.org <regext@ietf.org>
Subject: RE: [regext] [Ext] Re: RDAP and link context

From: regext <regext-bounces@ietf.org> On Behalf Of Jasdip Singh
Sent: Sunday, March 3, 2024 2:12 PM
To: James Mitchell <james.mitchell@iana.org>; Andrew Newton (andy) <andy@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