Andy, Thanks for weighing in on this. I provide my replies embedded below.
-- JG 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/> On 7/1/22, 9:17 AM, "Andrew Newton" <a...@hxr.us> wrote: James, Comments in-line... On Mon, Jun 27, 2022 at 12:36 PM Gould, James <jgould=40verisign....@dmarc.ietf.org> wrote: > > > The question is how we handle versioning, which is an aspect not covered in the existing RFCs. The only version reference is in the RDAP Conformance definition in section 4.1 of RFC 9083 with "rdap_level_0" and "lunarNIC_level_0". If the use of "lunarNIC_level_0" was a mistake, then versioning is completely absent for extensions. In my opinion, this is not accurate. The identifier is the version. If I understand your position correctly, you believe that the identifier should contain a separate, embedded, syntactically-parsable version identifier. And that is not an unreasonable position. However, what are the benefits of having it? And what are the complications of having it? If this sub-identifer were also an opaque identifier, then I don't see much benefit. If it were to have semantics, then what are those semantics? JG - If versioning is an explicit goal, then yes, the version number should be syntactically-parsable. The RDAP conformance is meant to provide a hint of the specifications used in the construction of the response. The extension specification defines the RDAP elements used in the RDAP request (URL path segments and query parameters) and response (JSON response members and objectClassName values for new RDAP objects). Versioning is an important aspect of the signaling of the RDAP conformance that is missing from the RFCs, and because of that we're having this discussion around the three approaches (Approach A with tight coupling of the RDAP Conformance with the extension elements, Approach B with coupling of the prefix with the extension elements, and Approach C with no coupling with the prefix and the extension elements). > > Approach A is a showstopper to me since it cascades versioning to all elements with no perceived value and with the cost of interoperability issues when the version number does change. What do you mean by "all elements" here? Can you provide an example? JG - The proposal of Approach A is to have the RDAP conformance value be used as the prefix of all the RDAP extension elements defined in the extension specification. These can include URL path segments in the requests, the JSON response members in the responses, and the objectClassName values in the responses for new RDAP objects. draft-ietf-regext-rdap-openid provides an example of Approach A with the RDAP Conformance value of "roidc1", which embeds the version number into the prefix that is used for the query parameter "roidc1_id", and the response members "roidc1_session", "roidc1_deviceInfo", and "roidc1_openidConfiguration". If the specification is updated, which can be backward compatible by adding a new optional feature, the version number would be changed from "roidc1" to "roidc2", which then results in changing all the extension elements ("roidc2_id" query parameter and "roidc2_ session", "roidc2_deviceInfo", and "roidc2_openidConfiguration"). Cascading the versioning RDAP conformance into all the extension elements can lead to interoperability issues and discourage changing the version number at all. Approach B is reflected in draft-ietf-regext-rdap-redacted-04, where "redacted" is registered in the RDAP Extension Registry and is used for the RDAP Conformance value "redacted_level_0.2" (should be "redacted_level_0_2") and used for the JSON response member "redacted". Approach C is reflected in draft-ietf-regext-rdap-redacted-08, where the "redacted_level_0_3" version identifier and the "redacted" prefix are registered in the RDAP Extension Registry with the use of the "redacted_level_0_3" version identifier for RDAP Conformance and the use of the "redacted" prefix for the JSON response member. In the case of Approach B and C, the values registered in the RDAP Extension Registry guarantee uniqueness, and the RDAP Conformance value has the sole responsibility of signaling the version of the extension without cascading down to the extension elements. I prefer the flexibility of Approach C, but Approach B will work. One side effect of Approach C is that we still need to support the registration of fully versioned identifiers to capture policy signaling, such as the case of the RDAP Profile identifiers "icann_rdap_response_profile_0" and "icann_rdap_technical_implementation_guide_0". -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
