Pawel, My focus is on both since we have had experience in EPP of deploying draft versions in Production while the standards process continues. Having implementation experience of drafts is important and should be encouraged, where we should have a versioning mechanism in RDAP that supports extension versions at any stage of the maturity process (e.g., proprietary, informational, standards track draft, standards track RFC, updated standards track RFC). My first RFC was the DNSSEC RFC 5910, which updated DNSSEC RFC 4310, where I learned firsthand the benefit of having versioning of the draft during the standards process, since we were implementing it well ahead of the RFC being published. I’ve brought up the Registry Fee Extension in RFC 8748 that took 6 ½ years, which had a total of 29 draft versions and a URI that went to “urn:ietf:params:xml:ns:fee-0.25” prior to getting bumped to “urn:ietf:params:xml:ns:fee-1.0” in draft-ietf-regext-epp-fees-10. We implemented a total of 3 versions of the Registry Fee Extension in Production and were capable of doing so without impacting the client by leveraging the point versioning of the URI. RDAP is more flexible than EPP when it comes to the concept of breaking changes, since as I pointed out in RPP the provisioning protocol must have strong validation to ensure that the server commits exactly what was intended by the client. RDAP still has the need for a strong versioning approach that supports extensions at any stage of the maturity process, but it’s still unclear to me what’s considered a breaking RDAP change since unknown properties must be ignored.
Providing for strong versioning by the server does not require the client to implement it, but as Mario pointed out in a separate message, the question is whether the client sees value in implementing it. The point versioning provides for fine-grained information at the level of any interface change that should be important for clients interfacing with a diverse set of servers. The versioning extension can be added incrementally since there is no requirement to touch the extension identifiers for backward compatibility. The extension draft-loffredo-regext-rdap-verified-contacts provides an example of the use of point versioning (renamed from semantic versioning), where there is a normative reference to draft-ietf-regext-rdap-versioning and the definition of the Opaque Versioning that matches the Extension Identifier and the Point Versioning in the Extension Version Identifier section 7. One key difference between draft-ietf-regext-rdap-versioning and the versioning concepts included in draft-ietf-regext-rdap-extensions, is the server implements one version of an extension by default with information available in the /help for the client to determine what other versions of an extension is supported by the server and the capability for the client to specify the version they want either via the query parameter or the x-media parameter. The draft-ietf-regext-rdap-extensions versioning concepts provides different options that are targeted to only opaque versioning with successor extension options (Supporting both extensions in parallel in section 5.4.1, Non-overlapping Successors in section 5.4.3, Overlapping Successors in section 5.4.4). I believe it’s best for the server to implement a default version of an extension and enable the client to discover and select the desired version of an extension. 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://verisigninc.com/> From: Pawel Kowalik <[email protected]> Date: Wednesday, June 10, 2026 at 1:20 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers Hi Jim, I am asking myself, if we are trying to solve the same problem? Your arguments seems to focus a lot on the specification development phase, with a clear intent of changing version with every draft/spec change. My focus is primarily in production environments of RDAP deployments where I don't think we should encourage by design that people experiment with implementations of every possible draft and deploy to production environment. If they do, this is in fact of a benefit, if every change that the client shall be aware of would be guarded with a change of extension identifier, or with parallel deployment as specified as possibility in 5.4.1. of draft-ietf-regext-rdap-extensions. 5.4.1. of draft-ietf-regext-rdap-extensions highlights also another possibility of an extension itself defining its own signalling "within the extension documentation.". This may be that an extension would make a MUST dependency to draft-ietf-regext-rdap-versioning, telling the clients and the servers same time "if you implement this extension you MUST implement and understand versioning". This will allow extension authors to keep extension identifier stable and implementation interoperable. The decision will be then with extension author. Kind Regards, Pawel On 10.06.26 01:46, Gould, James wrote: Andy, The reference that you make for breaking changes in draft-ietf-regext-rdap-extensions provides a few examples but is focused on how to deal with breaking changes instead of defining what is considered a breaking change. What I meant by material is a change to the interface itself. The versioning shouldn't be all about breaking, but the version of the extension interface itself. A client should be capable of understanding the interface supported by the extension, which is the basis for changing the Point Versioning value. The Extension Version Identifier for the Versioning Extension itself is now at "versioning-0.6", meaning there have been 7 interface changes, since it started at "versioning-0.0", all with a single Extension Identifier of "versioning". For interoperability, a client should have the capability of knowing the extension interfaces available and specifying which one they would like to use. When using Opaque Versioning and the Extension Identifier, this would result in something like "versioning0" to "versioning6" and requiring a change to the extension prefix across all query and response elements. I find this to be non-optimal, but it can certainly be done. I don't believe draft-ietf-regext-rdap-extensions covers the interface versioning supported by an extension, since it's focused only on breaking changes. What is meant by a version change is one area of incompatibility between draft-ietf-regext-rdap-extensions and draft-ietf-regext-rdap-versioning. Point versioning is not something new for this working group, since we've been using point versioning of the XML URIs in the EPP extensions for a while now for the same purpose. Thanks, -- JG James Gould Fellow Engineer [email protected]<mailto:[email protected]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/1bzn3LL1AevnVZ0Yqrg408PPzXeCved88YHQ50XEiLVTMVwPiIbtEm65ZrlLQJlzfr5RNkxqa1_QaBTm3kiTWz-iAKCzx9IpaF-ofmDYIkdu9MkBj4VUpUkIOgifXpwr99xsUoODq0em1dQgGYTVzcGOJYVYbjodBrZjCOmV92GVmX1J5kxKf5xq_RYo1jQRUwd8TrMlgZMmVTZLPMSRXX28rAPitXoWTefFLbrJruK5ubbh86oAFXJJz_lUoitPMVK-FAgVvRjaxm6OSwtQIlYUISV4bCdk99CcAUfHcWnI/http%3A%2F%2Fverisigninc.com%2F> On 6/9/26, 4:48 PM, "Andy Newton" <[email protected]<mailto:[email protected]> <mailto:[email protected]><mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 6/9/26 3:07 PM, Gould, James wrote: Andy, I believe we first need to define changes in RDAP are material and may trigger a change to the Extension Identifier or bumping the point versioning value. Some options to consider below: 1. Is adding any new query features (e.g., path segment, query parameter, media type parameter) material? 2. Is removing query features (e.g., path segment, query parameter, media type parameter) material? 3. Is renaming query features (e.g., path segment, query parameter, media type parameter), which equates to a remove and an add material? 4. Is adding any new JSON members material? 5. Is removing any JSON members material? 6. Is renaming JSON members material? I don't know what you mean by "material". However, if you are talking about breaking vs non-breaking changes (or compatibility between versions), this working group did discuss that topic in much detail. The current outcome is here: https://secure-web.cisco.com/1mv9m_1RdQVpBVNrLhlA9HC2TYCkDeT6tSKcgOrKcM13YRjQAjs9ozfbOKyL4ubgn5mPjDfmvVGBOtgqlLQYXb6ILLMMq9Q9fcA-3zFJ1PnXjZsiQD8Ks6MbDDJm-q13EK0YDBJaqQltC_GeMZU3rnUkxRY7SP9t8Q-rc4gcazKxCuoBVzrfXgeQyFEZ8nIXof_65_AXjVukHpllMZ2JEU1428sGxzycJu8eUzfn8H6fUI_zzOFCQXOSf-V14PRir24EYJMMbWxRUbtV9qNAHOD9fKaOyvyOvclK-RoyE07M/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-12%23name-extension-versioning <https://secure-web.cisco.com/1mv9m_1RdQVpBVNrLhlA9HC2TYCkDeT6tSKcgOrKcM13YRjQAjs9ozfbOKyL4ubgn5mPjDfmvVGBOtgqlLQYXb6ILLMMq9Q9fcA-3zFJ1PnXjZsiQD8Ks6MbDDJm-q13EK0YDBJaqQltC_GeMZU3rnUkxRY7SP9t8Q-rc4gcazKxCuoBVzrfXgeQyFEZ8nIXof_65_AXjVukHpllMZ2JEU1428sGxzycJu8eUzfn8H6fUI_zzOFCQXOSf-V14PRir24EYJMMbWxRUbtV9qNAHOD9fKaOyvyOvclK-RoyE07M/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-12%23name-extension-versioning><https://secure-web.cisco.com/1mv9m_1RdQVpBVNrLhlA9HC2TYCkDeT6tSKcgOrKcM13YRjQAjs9ozfbOKyL4ubgn5mPjDfmvVGBOtgqlLQYXb6ILLMMq9Q9fcA-3zFJ1PnXjZsiQD8Ks6MbDDJm-q13EK0YDBJaqQltC_GeMZU3rnUkxRY7SP9t8Q-rc4gcazKxCuoBVzrfXgeQyFEZ8nIXof_65_AXjVukHpllMZ2JEU1428sGxzycJu8eUzfn8H6fUI_zzOFCQXOSf-V14PRir24EYJMMbWxRUbtV9qNAHOD9fKaOyvyOvclK-RoyE07M/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-12%23name-extension-versioning> We have historically kept the Extension Identifier ("exampleExt0" or "exampleExt1") static through the draft development process, independent of the interface changes. Except not always. There are two documents currently in-progress right now that have changed their identifiers, one did it twice. The only RDAP extensions that registered new Extension Identifiers has been the Profile Extension Identifiers (icann_rdap_response_profile_0 and icann_rdap_technical_implementation_guide_0 to icann_rdap_response_profile_1 and icann_rdap_technical_implementation_guide_1, respectively). Isn't this an argument against a complicated versioning scheme? If the only extensions to ever be versioned are profiles which did not actually change any part of the protocol, then it would seem the existing opaque versioning is good enough, and complicated schemes are not necessary. We really don't know what would break a client, where should they expect all the data members to be present, will they expect all the query features to work? Yes we do. See above. -andy, no hats
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
