Hello James, Yes, I mean Approach A as the current approach.
As was noted earlier, there is no version semantics for extension identifiers; they are opaque. One might as well call "ext0", "ext1", etc for an extension "abc", "def", etc. Agreed we haven't yet had a single case of extension evolution :) but IMHO it is important to consider various change scenarios exhaustively and how they might introduce collisions and breakages for clients. I had earlier shared a side-by-side breakage analysis [1] of the current approach (approach A) and one of the proposed approaches (approach B). That informs when collisions and breakages are possible. We could add other change scenarios there to make it exhaustive. That way we would make a more informed decision if we were to ever ditch the current approach. Thanks, Jasdip [1] https://docs.google.com/document/d/1iadJc1D2-z_9pSy0PNcl4mhEQglh7dIHhbmRgrCW6mc/edit?usp=sharing On 5/27/22, 10:41 AM, "Gould, James" <jgo...@verisign.com> wrote: Jansdip, I'm not clear what you mean by the current approach, unless you mean Approach A. The RFCs are consistently unclear when it comes to versioning. There are no new versions of extensions that has triggered the use case we're discussing. Approach A doesn't really handle versioning unless the prefixes start embedding version numbers, which I consider unneeded and brittle. The registrations have a mix of version numbers and non-version numbers, but I'm not aware of new versions needed until new versions of the RDAP Profile identifiers are needed. In the case of the RDAP Profile identifiers, there is no brittle side effects with the RDAP elements since they are purely signaling identifiers. -- 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 5/27/22, 10:31 AM, "Jasdip Singh" <jasd...@arin.net> wrote: Hi. I'd contend that unlike the proposed approach(es), current approach: - guarantees no collisions under every change scenario (not just optional new field) - guarantees sufficient transition time for clients when moving to the next version of an extension (without requiring any additional signaling beyond RDAP conformance) and thereby, guarantees near-zero breakage (breakage only possible if a client ignores the transition time) - has a simple registration model for each opaque extension identifier Jasdip On 5/27/22, 10:25 AM, "regext on behalf of Gould, James" <regext-boun...@ietf.org on behalf of jgould=40verisign....@dmarc.ietf.org> wrote: Mario, [ML] My only objection to Approach C is that every new version would result in registering a new extension identifier. I would opt for a less verbose solution, if any. I'm not aware of the plan for new versions of the existing extensions, so I don't view it as a scalability issue. While an extension is an Internet Draft, the pointed versions will not be registered until the draft becomes an RFC. This is similar to what happens with the EPP extensions, where pre-RFC implementers can use the pointed version contained in the draft for signaling that will eventually become a full registered version (e.g., "0_N" becoming "1" or "1_N" becoming "2") in the registry. When there are multiple versions of an extension, I believe it is important to capture those versions in the RDAP Extension Registry with a link to the associated specification. Mixing versioning with the prefixes I believe is unnecessary and brittle, so I don't support Approach A. Approach B provides the flexibility to define the full RDAP Conformance version in the specification, so it supports versioning without the brittle side effects, but I view Approach C as being better since the versioning is more explicit in the registry. If there is the risk of an overload of versions in the registry, then I would agree with the concern of Approach C, but I don't believe that risk exists. -- 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://secure-web.cisco.com/1l0afMm0DSkNmD4odBlYJ6gwW2XdoV_IRhP3O8-eNdjD3ILiqei8amp7uwkJtuwqyO2x1q-OD9PlHwyEN5A_xiAMPafVBDQGmBJ-OhojRk-tkX4nqOtBld0UOz84Khjgwv_sUfOVMfbZXtLig2khCZFumUFPvBHtZgQoNncwmi0ZRT-Y-Oi-oz05aAOQtqGP3FLSEuq1Th8BFOfHONhLSDYV4aN8B_IdIPPS4ap5qa-DYBZgxTMgF6gu0aE2zzCdD/http%3A%2F%2Fverisigninc.com%2F> On 5/27/22, 10:10 AM, "Mario Loffredo" <mario.loffr...@iit.cnr.it> wrote: Hi james, my comment inline. Il 27/05/2022 14:43, Gould, James ha scritto: > Mario, > > Thank you for providing an example of the complexity of versioning that is associated with tightly coupling the RDAP compliance value with the set of prefixes. Unfortunately, RDAP doesn't include the same sort of version negotiation that exists in EPP with the use of XML namespace URIs in the greeting and login services. I view the RDAP Conformance being closer to the EPP greeting services. I'll continue down the EPP line of discussion, where EPP leverages the XML namespace URIs for versioning that is tied to XML schemas and leverages XML namespace prefixes for grouping of the XML elements. EPP explicitly requires the use of a namespace-aware XML parser, which enables the use of any XML namespace prefix. There is no direct tie in the RFCs to the specific XML namespace prefix to use that is linked with the versioned XML namespace URIs. [ML] Agreed. I only meant to make WG see things from a different angle beyond the considerations based on what RFCs currently permit presenting what could be the operational consequences of opting for Approach A. > > > REST and JSON is schema-less, so are we attempting to bring in XML concepts into REST and JSON with the tight coupling of extension RDAP conformance values and the extension elements? [ML] Clearly stated that we shouldn't. But what is most important, > Approach C that is currently implemented in draft-ietf-regext-rdap-redacted includes the registration of a full versioned identifier for the RDAP Conformance, with "redacted_level_0_3" and the registration of the prefix "redacted" to ensure uniqueness with other extensions. The "redacted" prefix looks a lot like "redacted_level_0_3", but that is not required. The tie between the tie is based on the use of the same "Published specification" value in the RDAP Extension Registry. I haven't heard of a concrete case to help the client out by having the RDAP Conformance value match the prefix with the optional support for versioning in both. An extension should be additive, and the client would first key off the set of versioned RDAP conformance values, to determine what is supported based on what is defined in the specification. We have no equivalent of an XML schema, and I don't believe we should attempt to model that in RDAP. [ML] Me too. > I view attempting to model XML schemas with predefined XML prefixes as brittle and unneeded. [ML] Fully agreed. I'd also say "unpractical" as it would reduce the benefits from using REST and JSON. > Enable true versioning in the RDAP conformance and enable prefixes to be independently registered in the RDAP Extension Registry without any predefined linkage. [ML] My only objection to Approach C is that every new version would result in registering a new extension identifier. I would opt for a less verbose solution, if any. Summarizing, I'm OK with either approach B or C. Best, Mario > > > Thanks, > -- Dr. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://secure-web.cisco.com/16t5sBrz_iAuxdO4FzKpp7t63WvEdOI56N9ldgS_C5bon4NCc-fivU9_kFZf8_evpDmkcPCcQiuBoJ7ofMrxCHVesyRtQIvx85qEcFV0qX_2PuNNpIb30pT3SRzrneNKg75w7-OAskVaeHoaFH9yk1uOXj-IB65xr1AE0B_z08bGMucXu9VhZ-ghBF2wZjUuw9-C2po2YN2kn9i4nBpQQqX0Kc1A-h2sVt4NJuokO7CbStWfhVUom1hVeNIZuUWn3/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1Pmez7_guFJeyyYJQJlAPcRVsyslvtBFV-Uom6HjmGd9RYTdrc1Ti1lNwZi6rMsua2ROrmU_CyJJr_M-veIzicAlIWqqS2EGwGrAOPM-H_uXJOiu3smPuUr7PeA_9Z11iyXxuwTd2dee25i_1hwe3FZtcWN8bixTNGJJbF2bJw2l1QFuoRKjUa7B8mQk2DR8r6mk9FjQoLLSHQTwISf7K7R3GXXXVNVBtaALEfXQ3u5hOdwCy2Fhz6TLt14O4rvd8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
