Pawel, Thank you for your preferences and reasoning. Can others of the working group weigh in on the options?
I don’t remember you raising an RFC 9083 compliance issue with the extension approach proposed by draft-ietf-regext-rdap-versioning, which is an optional extension and any RDAP extension supporting point versioning in draft-ietf-regext-rdap-versioning will include a normative reference to it. Can you please clarify what language in RFC 9083 represents a compliance issue for draft-ietf-regext-rdap-versioning? We did agree at IETF 121 that the extensions draft shall go through first, but that was before the extensions draft expanded the Extension Versioning section to include concrete proposals that is in scope for draft-ietf-regext-rdap-versioning. The extensions draft was meant to clarify the confusion in the base RFCs, which Section 5.4 without the sub-sections does. This really becomes a scoping question for the working group, where draft-ietf-regext-rdap-versioning existed first (draft-gould-regext-rdap-versioning-00 published in November 2022) to add the missing functionality for RDAP versioning, and then followed draft-ietf-regext-rdap-extensions (draft-newton-regext-rdap-extensions-00 published in June 2023), and draft-ietf-regext-rdap-x-media-type (draft-newton-regext-rdap-x-media-type-00 published May 2023). All three drafts were adopted by the working group in February 2024 with agreement to support them (Mario Loffredo is the document shepherd of draft-ietf-regext-rdap-x-media-type and Jasdip Singh is the Document Shepherd of draft-ietf-regext-rdap-versioning). What has progressed since then is the draft-ietf-regext-rdap-versioning adding full support for Opaque Versioning and revising Semantic Versioning to now Point Versioning based on feedback from the working group. There have been issues raised on the mailing list related to incompatibilities between the three drafts that has not been addressed. Below are some messages on the mailing lists for reference: https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/ https://mailarchive.ietf.org/arch/msg/regext/54_oB0LYlSTqG4m_cBwHNtFUlFE/ https://mailarchive.ietf.org/arch/msg/regext/-X7hGlhwX5Brqm6S2z9v4TXeaM8/ https://mailarchive.ietf.org/arch/msg/regext/--u9zYfJ9BQJ_zEgc-zu6r_F9vA/ https://mailarchive.ietf.org/arch/msg/regext/SFUw-i7phW0RM8gOOD4MrOyKl1I/ https://mailarchive.ietf.org/arch/msg/regext/MzU7mrv1MuhUQKHl1DBhCcN9I-U/ -- JG [cid87442*[email protected]] 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/> From: Pawel Kowalik <[email protected]> Date: Friday, June 19, 2026 at 7:34 AM To: "[email protected]" <[email protected]> Subject: [EXTERNAL] [regext] Re: Extension Versioning Location Information and What Changes the Version Options Hi Jim, 1a) this the only way rfc9083 supports and describes 2a) same here, this is the only option for existing clients and servers compatible with rfc9083 without update to STD95 or extensions draft-ietf-regext-rdap-extensions shall make a normative definition of "Breaking" vs. "Non-Breaking" to support extension authors - however in compatible way to STD95, so that none of existing implementation would experience something unexpected. draft-ietf-regext-rdap-versioning shall build upon it to offer more fine-grained signalling for both requests and responses - but compatible with the above. Because draft-ietf-regext-rdap-extensions is the foundation, it shall actually be not dependent on any other extension. We agreed to that in IETF 121 [1] that the extensions draft shall go through first because of that. [1] https://datatracker.ietf.org/doc/minutes-121-regext-202411041300/<https://secure-web.cisco.com/16Ct7kKEUDeLAkqL2u8WNYgoAb2unoKWEhYvoEQLV5m6w-lkPLSI2NmL87iZ50kXXj-HaCZA5qaAtiigVghJdTp8TT-2-P4daCt8navFBwQDk9895M0wqxyJPUcs57X8WY-KsIQf_Sz_Cf6tbrL9kI7TnN7w-AOdMJRzRi0Pkum_gUAt3ue8aMJviGzm_uXtTToGhyh8AZhUON5plQR6rTGpmTelrAxQxhwbURknnlz11mXDZC3HbSvE48UtjBnGCApHrWaIdrd_XxV1bGUsX2-ZuX1rFr7X_grJpoeOJvzU/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-121-regext-202411041300%2F> Kind Regards, Pawel On 16.06.26 16:57, Gould, James wrote: There has been a lot of discussion related to extension versioning on the mailing list. To help define a path forward, I’ve provided a set of options for the Location of Versioning Information (Opaque Versioning, Embedded Versioning, Point Versioning) and What Changes the Version (Breaking Change, Interface Change, Any Change) below for the working group to weigh in. 1. Location of Versioning Information 1. Entire Extension Identifier supported by Opaque Versioning – The only signal of a change in interface is a change to the entire Extension Identifier with no pre-defined embedded versioning scheme. 2. Embedded in Extension Identifier (New versioning type, such as Embedded Versioning) – This type of versioning would formally define a versioning scheme in the format of the Extension Identifier, where the ‘_’ can only be used as a separator for the extension elements, so the scheme needs to leverage a predefined alphanumeric format using snake case for word separators. One option is to embed the major and minor values used in the Point Versioning into the Extension Identifier, such as the following Extension Versioning Identifier. An example would be “exampleExtV01V12”. i. embedded-version-identifier = name “V” major “V” minor ; Complies with "name" ABNF rule from RFC 7480 ii. name = ALPHA *( ALPHA / DIGIT) ; Subset of “name” ABNF rule from RFC 7480 iii. major = 2DIGIT ; Numerically increasing value with a leading “0” when < 10 iv. minor = 2DIGIT ; Numerically increasing value with a leading “0” when < 10 1. Point Versioning (any versioning type that doesn’t include the versioning directly in the Extension Identifier) – The versioning is additive to the Extension Identifier, where the Extension Identifier acts as a namespace. Extensions that support Point Versioning includes a dependency on the implementation of the Versioning Extension for clients to be capable of knowing the extension versions supported by the server and to indicate what extension version it desires to use. The server supports a default version of each Point Versioning Extension implemented with the capability for the client to override the default using a query parameter or a media type parameter. 2. What Changes the Version 1. Breaking Change – The only requirement for changing the version is when the successor extension makes a breaking change to the predecessor extension. Learning new optional features in an implemented successor extension would need to be communicated out-of-band. 2. Interface Change – Any interface change (breaking or non-breaking) changes the version of the successor extension. A non-interface change in the extension specification does not change the version, so therefore the mapping of the extension specification to the version is embedded in the specification, such as the use of the Extension Version Identifier section for Point Versioning. 3. Any Change – Any change to the specification changes the version of the successor extension. The scheme for the versioning can be based on the draft versions, while considering the possible change in the extension names as well as draft version numbers (e.g., proprietary example-ext changes to individual draft draft-author-example-ext-01 changes to working group draft draft-ietf-example-ext-00). Nit changes to a specification will result in a version change. Are there additional options that should be considered? In thinking about the options, my preference continues to be “Point Versioning” for the “Location of Versioning Information” and “Interface Change” for “What Changes the Version”. This keeps the versioning information outside of the Extension Identifier, since there are too many use cases for embedding the versioning inside the Extension Identifier that is not well suited for the “name” ABNF rule from RFC 7480. The versioning needs to support defining the full interface of an extension so that clients don’t break when expecting an older interface or when expecting a newer interface. The mapping of the specification to the interface can be included directly in the specification, such as including an “Extension Version Identifier” section, as done in draft-ietf-regext-rdap-versioning (Section 6), draft-ietf-regext-rdap-jscontact (Section 3.1.2), and draft-loffredo-regext-rdap-verified-contacts (Section 7). There can be proprietary extensions, individual IETF draft extensions, working group IETF drafts, and finally RFCs that don’t provide for a consistent naming scheme that can be used in the Extension Identifier. Thanks, -- JG [cid87442*[email protected]] 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://secure-web.cisco.com/1Led7zVwJBCSNp9QloVsHPnFHXb9SisJTgw6BDUuA85mGKPhm_91EDPft8egLeRzrKyIfn4QuL94Ay0c5Rrr5izFb2z_XVu7RHWrn110H7zBWeTzqFNGlGiiMEQ6jTf1pKRKtTP8Z2WIohRyOJYNtWCfrYDqoel2gkzuc8BUM9AoAXmLDiZj9sTPpDrkVPFsIPM4I331iGa0TwOaTnDpFdtMsUkcMbIpdVHzvLi5w0DnGuUXdYYu7cofl5agS9Ca5WHx7izbjTry1ohXYlWH8Rktxokpbl267oCaUSm-iUUo/http%3A%2F%2Fverisigninc.com%2F> _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
