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", Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
