Jasdip, Thank you for your review and feedback. I provide responses to your feedback embedded below, prefixed with “JG:”.
-- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Jasdip Singh <jasd...@arin.net> Date: Friday, November 1, 2024 at 6:28 PM To: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] RDAP versioning draft feedback 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 James, Daniel, Mario, I read the latest draft and to help tighten this spec, have few higher-level comments. VCHAR use: In section 3.1, the ABNF for “versioning” in “extension-version-identifier” is “["-" 1*VCHAR]”. Since the extension version identifiers could be passed in the “extensions” parameter of the RDAP-X media type in the HTTP accept and/or content-type headers, it would be safer to constrict them to what’s allowed in those headers. E.g., for the accept header, a parameter value (per section 5.6.6 of RFC 9110) is “parameter-value = ( token / quoted-string )” where “token” is any VCHAR minus the delimiters (section 5.6.2 of RFC 9110). The reason AFAIU is to help prevent injection attacks. From security angle, good to address this. JG – Yes, the versioning rule could be updated to match the tchar rule in section 5.6.2 of RFC 9110. The only exception may be to remove the use of ‘-‘, since that separator is used between the extension-identifier and the versioning rules. How about the following: extension-version-identifier = identifier versioning identifier = ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifier versioning = ["-" 1*versioning-char] versioning-char = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA In reviewing the ABNF, I noticed the versioning rule for the Semantic Extension Version Identifier, in Section 4.2.1, needed the ‘;’ removed. It should be: versioning = "-" major "." minor Rationale for versioning: Section 1 says, “The RDAP Conformance values are identifiers with no standard mechanism to support structured, machine-parseable version signaling by the server.” It’d be good to elaborate with usage scenarios where such structured versioning is a value-add for clients beyond what the opaque (no inner meaning) extension identifiers from STD 95 afford. Let’s say an extension is “foo1”, then “foo99”, and later “foo2” in terms of “versions”. The server announces its support for these non-structured extensions, say, on its web site or through the “rdapConformance” member in a /help response, and the clients can then negotiate a particular non-structured version of this extension using the standard HTTP content negotiation methodology (e.g., using the RDAP-X media type). In the spirit of what-not-to-do, it is fair for a client to ask: Why should I go through the overhead of processing the “versioning_help” member? What value-add does it get me? Is it in some way a better discovery and/or negotiation method for RDAP extensions? Would be good to beef up the rationale for structured versioning. JG – We need to ensure that RDAP-X supports the extension version identifier as well, so there should be no variance between the versioning extension and the RDAP-X extension. We can add more rationale in Section 2 “Semantic Versioning”, where a server could support multiple versions of an extensions that are signaled as related. For the versioning extension itself, there have been multiple versions of it that are not structurally different and not backward compatible, with the latest version being “versioning-0.3”. Other RDAP extensions could leverage semantic versioning during development to encourage implementation with version isolation and with clear relationship between the extension version identifiers. Do you believe that we should look to add the concept of relationships between opaque version identifiers? RDAP-X way: To help client implementors, beside the “versioning” query parameter examples, would be good to include one or more RDAP-X examples. JG – You mean that you want to see examples like what is included in draft-ietf-regext-rdap-x-media-type, such as: application/rdap-x+json;extensions="rdap_level_0 fred" and application/rdap-x+json;extensions="semantic_ext1-0.1 opaque_ext2" /help path segment: Section 3.1.6 of RFC 9082 says, “The help path segment can be used to request helpful information (command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, etc.) from an RDAP server.” Using a new “versioning” query parameter for /help, is this spec updating RFC 9082? Not sure but thought of asking. JG – No, I don’t see the need to update RFC 9082. We will discuss the scope of the draft-ietf-regext-rdap-extensions that I believe needs to formally define all forms of RDAP extension types that are known with further extensibility in the future. The base RDAP RFCs did not do a good job at defining the methods of extensibility like what was done for EPP. We can address this in draft-ietf-regext-rdap-extensions. Language like “can be used” is not normative and does not include new types of helpful information or query parameters defined by an RDAP extension. Further, beside the “versioning” extension version identifier itself, are any other extension version identifiers allowed in the “versioning” query parameter for /help? If not, good to clarify that. JG – The “versioning” query parameter is already defined as containing a list of extension version identifiers, so there should be no problem with providing other extension version identifiers in the “versioning” query parameter for the /help. Caution with using “versioning” query parameter in non-help path segments: It would be good to beef up the security and privacy considerations for the risks with using “versioning” query parameters in non-help path segments vis-à-vis RDAP redirects and referrals, as the Extensions draft cautions. JG – I don’t see the use of a query parameter as a security and privacy consideration. Do you have an example of such security and privacy considerations included in other RDAP extensions with query parameters? Thanks, Jasdip
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
