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] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/9/26, 4:48 PM, "Andy Newton" <[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>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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
