Hi James, Andy and I reviewed your note and believe it would be better to keep the RDAP-X and Versioning drafts separate.
The RDAP-X media type leverages the standard HTTP content negotiation using the Accept and Content-Type headers and is guaranteed to seamlessly work for any RDAP response scenario, including redirects and referrals. It would be helpful to keep the RDAP-X draft separate and focused on this HTTP axiom. We should though beef up the normative language in both drafts about how RDAP-X and Versioning relate. As for the “RDAP Extension Versioning” appendix in this draft, that could be removed given the Versioning draft addresses semantic versioning. The “Query Parameters Considered Harmful” appendix helps highlight the pitfalls vis-à-vis redirects and referrals, and in our opinion, should stay. Since the Versioning draft introduces a new term “extension version identifier” beside the standard “extension identifier” term, as part of the normative language beefing up, that would need addressing in the other drafts. Thanks, Jasdip From: Gould, James <jgould=40verisign....@dmarc.ietf.org> Date: Tuesday, August 20, 2024 at 4:28 PM To: jgould=40verisign....@dmarc.ietf.org <jgould=40verisign....@dmarc.ietf.org>, regext@ietf.org <regext@ietf.org> Subject: [regext] Re: Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions With the latest updates posted for draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-extensions, we need to look at the below alignment feedback that I provided back in July between the three drafts. I believe that merging draft-ietf-regext-rdap-x-media-type into draft-ietf-regext-rdap-versioning should be considered, since draft-ietf-regext-rdap-versioning supports draft-ietf-regext-rdap-x-media-type as an option for the client to provide the extension signaling and as a requirement for the server. Merging will ensure that there is alignment. Thanks, -- JG [cid:image001.png@01DAF30A.0F1E56C0] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "Gould, James" <jgould=40verisign....@dmarc.ietf.org> Date: Monday, July 22, 2024 at 10:59 AM To: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Review of draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions Hi, I did a detailed review of the three drafts draft-ietf-regext-rdap-versioning, draft-ietf-regext-rdap-x-media-type, and draft-ietf-regext-rdap-extensions for alignment. The following are my findings: 1. draft-ietf-regext-rdap-versioning includes support for draft-ietf-regext-rdap-x-media-type and the “versioning” query parameter for the client to provide a hint of the extension versions to include in the RDAP query and RDAP response. The server MUST support both methods and the client MUST include a single method in the RDAP query to ensure that there are no conflicts. This ensures that clients can specify the extension versions via a query parameter and via an HTTP header per draft-ietf-regext-rdap-x-media-type. 2. draft-ietf-regext-rdap-x-media-type could be merged into draft-ietf-regext-rdap-versioning, since it now represents one method of an Extension Versioning Request. a. An alternative is for draft-ietf-regext-rdap-x-media-type to support a more generic form of query parameters for use in any RDAP extension. b. The extension can stay separate if there is some advantage. 3. draft-ietf-regext-rdap-versioning defines a Extension Version Identifier in section 3.1 https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning#name-extension-version-identifie<https://secure-web.cisco.com/1Tdg4m5JitpxW6itEfcDynMUFCuaVtWRHjT4Li7mRPC8UmAlVU_JxLuj7Y53vZJjVIR3n60cKb17D6wR_sDwnP79PdfmqbAlbxRqfox-oWj7B6Aeo1ojJt7OCM02c6qrjL6v55axy0p6djQEJeRe2Wgio4lKVrHAXTRScpTRFYy26KtX5wGXwv5J7EZjfZ0ef_BBc8Z4bBkdoXrJ4qzpK6q_wICynV8dTxUFZKqLjeWjR_qkIWQQSoptYD2sP5EvFNw47vdC4Q2jGX_zkRBvhKPoCPBL40QUuUObkQ5E80A0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-versioning%23name-extension-version-identifie> as: a. ABNF extension-version-identifier = identifier versioning identifier = ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifer versioning = ["-" 1*VCHAR] b. draft-ietf-regext-rdap-x-media-type needs to also support the extension-version-identifier to use it with draft-ietf-regext-rdap-versioning, which currently uses the language: “This media type has a parameter of "extensions" which is a whitespace-separated list of RDAP extensions as defined in the IANA RDAP Extensions registry.” 1. How about making this more generic to support additional types of extension versioning schemes, such as the language: a. “This media type has a parameter of "extensions" which is a whitespace-separated list of RDAP extensions, such as defined in the IANA RDAP Extensions registry.” Use of the IANA RDAP Extensions registry will support Opaque Versioning in draft-ietf-regext-rdap-versioning, where use of “such as” will allow for additional RDAP extensions schemes. “the values in the media type's extension parameter SHOULD match the values in the rdapConformance array in the return JSON.” 1. The Extension Version Identifier does include the extension identifier, so the question is whether inclusion of the versioning suffix will meet the “match the values in the rdapConformance array”. 2. How about making this more specific to directly reference the version identifiers, which would work better with draft-ietf-regext-rdap-versioning: a. “the extension identifier values in the media type's extension parameter SHOULD match the values in the rdapConformance array in the return JSON.” 3. “though clients SHOULD list the extension identifier in the extensions parameter when using other protocol elements of those extensions. Servers SHOULD NOT require the usage of extension identifiers in the extensions paramater when other extension protocol elements are used. a. To support draft-ietf-regext-rdap-versioning, this could be modified as: “though clients SHOULD list the extension identifier in the extensions parameter when using other protocol elements of those extensions. Servers SHOULD NOT require the usage of extensions identifiers in the extensions parameter when other extension protocol elements are used” Referencing extension instead of extension identifier would be more generic to support the Extension Version Identifier. Nit – replace “paramater” with “parameter” 4. draft-ietf-regext-rdap-x-media-type Security Considerations parameter below may be best to address in draft-ietf-regext-rdap-versioning and even more generically in draft-ietf-regext-rdap-extensions a. “This specification does contrast with solutions using query parameters in that those solutions require servers to blindly copy query parameters into redirect URLs in situations where such copying could cause harm, such as copying an API key intended for one server into the redirect URL of another server.” 5. draft-ietf-regext-rdap-x-media-type B.2 “Query Parameters Considered Harmful” could be moved to draft-ietf-regext-rdap-extensions, since query parameters are used in many places in RDAP, so providing clear guidance when a query parameter should or should not be used would be useful in draft-ietf-regext-rdap-extensions. I don’t believe query parameters are “harmful” but has a disadvantage in the use cases presented. The query parameter has the advantage of being a simple approach for clients to provide their hint when directly interfacing with the server. In re-reviewing draft-ietf-regext-rdap-extensions it does look like section 12 “Redirects” includes some guidance related to query parameters, where I believe it would be beneficial to have a separate query parameter section in draft-ietf-regext-rdap-extensions. 6. draft-ietf-regext-rdap-x-media-type B.2.4 “Architectural Violations” and B.3 “RDAP Extension Versioning” could be removed, since I don’t see how the use of a query parameter in RDAP would be considered an architectural violation and RDAP Extension Versioning will be worked on in parallel in draft-ietf-regext-rdap-versioning. 7. draft-ietf-regext-rdap-versioning (This should have been draft-ietf-regext-rdap-extensions) a. In section 8 “Extension Versioning”, I just want to confirm that draft-ietf-regext-rdap-versioning address the normative language and if not what needs to be added: “If a future RFC defines a versioning scheme (such as using the mechanims defined in section Section 2<https://secure-web.cisco.com/15kcKfUiYym7gBk1mVusqYAdquOxwIgm_53XywlVoON2ihVovuCML-2ZhyMGPjGkdt2Z63y-GbfeeaEVyeKg-3js7fyImP-1no66yzSAaxsrj2jf_yl1ynAbwPI6LYd7efhCR7CcvdIsp1e8cqh40mItcXpVudaDh1XE5TT8LvMckqbtVFIHv7IOnd1Ayr-BaV3ywMz7IxTZalGZQeqt7muOT83ufqFkxhfbY8Y-pdJeI39vUGU-uuY8uTrTirdWhJvj25rFgNkuNj1Ki3Om0BduxblIFMZxcwO5IlrVTb24/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions%23extension_identifier>), an RDAP extension definition MUST explicitly denote this compliance.” b. Section 8.1 “Backwards-Compatible Changes” This section may not be needed with draft-ietf-regext-rdap-versioning, since the set of supported extension versions are explicitly specified, where in the case of Opaque Versioning the server could support many versions of the extension. c. Section 8.2 “Backwards-Incompatible Changes” IT would be helpful to include the reference to draft-ietf-regext-rdap-versioning as an option to consider in signaling support for more than one version of an extension. d. Section 9 “Extension Identifiers in a Response” You can update the reference of [I-D.gould-regext-rdap-versioning] to be [I-D.draft-ietf-regext-rdap-versioning]. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1QfmZ69AqpY4_0f2H_wOSkMPb4YSFxX_XF4DUcbip8tazdYNrRhHWvn1Ld4w1YalJihKwDu1GJ4_dxuwWX4Q_tcGrlllEFRM2CTf6ylO1oPHzVXTYf_vRNN6TGVhZM5BJSxSrAMzOvmyyZhCGQZiB6hcvKJBMJ2Mw6qx1CIw6hIqgkVzkQefDtXIARPs9epJ5x5ycEtNbmfHHkXyeX5e_u78qTmeQF0u5Q9pGMElUJtzhmyTXpIQEeNhTqYZLHQ2dilf26snWcKLzVV0DjL3Znw4Skrt3B0gMlnQgVjKvLN8/http%3A%2F%2Fverisigninc.com%2F>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
