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. 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. RDAP-X way: To help client implementors, beside the “versioning” query parameter examples, would be good to include one or more RDAP-X examples. /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. 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. 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. Thanks, Jasdip
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
