Hi, Related to the use of snake case for the extension identifier (e.g., "maturity_ext1"), we'll change that to camel case (e.g., "maturityExt1") in -04. I provide additional feedback embedded below, prefixed with "JG-".
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 3/9/26, 5:46 PM, "[email protected] <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> wrote: Hi, On 09.03.26 22:01, Andy Newton wrote: > > On 09-03-2026 3:47 PM, Gould, James wrote: >> JG3- draft-ietf-regext-rdap-versioning-04 ABNF was updated in Section >> 3.1 to address the feedback from you, Andy Newton, Jasdip Singh, >> Pawel Kowalik, and Maarten Wullink. The >> draft-ietf-regext-rdap-x-media-type-05 language "This parameter is a >> whitespace-separated list of RDAP extension identifiers (as would be >> found in the "rdapConformance" array)." Should be updated to "This >> parameter is a whitespace-separated list of RDAP extension >> identifiers (as would be found in the "rdapConformance" array) or >> Extension Versioning Identifiers, as defined by >> [I-D.ietf-regext-rdap-versioning] ." This enables the use of both >> opaque and maturity versioning in draft-ietf-regext-rdap-versioning >> using the “exts_list” parameter in >> draft-ietf-regext-rdap-x-media-type. The existing language only >> supports opaque versioning. > > My understanding of Pawel's proposal that we discussed at the hall-way > meeting at IETF 124 was that maturity versioning was to have the major > number in the extension identifier and there would be no need for > expressing the minor because minor revisions are supposed to be > backwards compatible. However, looking at versioning-04 there appears > to be something complicated going on with maturity versioning. > > The id "maturity_ext1-2.0" (an example from versioning-04) has a super > major, then a major, then a minor. Why isn't it just "maturity_ext1"? > (BTW, according to the extensions draft, that should be "maturityExt1"). Indeed, the core of our discussion is not reflected in -04. To recap what was proposed: - as per draft-ietf-regext-rdap-extensions-12 5.4.1/5.4.2 a breaking change means always new extension identifier. - semantically a breaking change = increase in MAJOR version as per draft-ietf-regext-rdap-versioning-04. This means that MAJOR version is actually redundant, because extension identifier changes anyway - this means that draft-ietf-regext-rdap-versioning-04 shall only care of MINOR version, to avoid this unnecessary redundancy This means also that examples like this one below are invalid, because maturity_ext1 would have to change to for example maturity_ext2 after major change. "version": "maturity_ext1-0.1", "version": "maturity_ext1-1.0", "version": "maturity_ext1-1.1", JG-I'll need to review draft-ietf-regext-rdap-extensions in detail, since in section 5.4 it starts with " RDAP extension identifiers and RDAP conformance strings are opaque, and they possess no explicit version despite the fact that some extension identifiers include trailing numbers" and then starts describing a versioning scheme based on opaque versioning in the sub-sections that conflicts with the working being done in draft-ietf-regext-rdap-versioning to address the RDAP versioning. We could look to move some of the section 5.4 sub-section content into the opaque versioning in draft-ietf-regext-rdap-versioning. I believe the intent of draft-ietf-regext-rdap-extensions was to clarify and not to define new functionality not defined in the base RFCs. The maturity versioning in draft-ietf-regext-rdap-versioning was meant to capture the major and minor versioning without having to change the extension identifier. The alternative of the opaque versioning does require changing the extension identifier for any breaking changes. I'll perform a detailed review of draft-ietf-regext-rdap-extensions and provide feedback on the mailing list, with a particular focus on incompatibility with draft-ietf-regext-rdap-versioning. Please refer to https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning#appendix-A.7 with the changes that were made based on our meeting at IETF-124. Kind Regards, Pawel _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
