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 _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
