[regext] Re: RDAP versioning draft feedback

["[e-mail]" <[e-mail]>]

Hi Jim,

Comments inline after [PK]

On 15.11.24 21:03, Gould, James wrote:
>
> Pawel,
>
> [...]
>
> Thanks for the feedback on the “type” property.  The goal of the 
> versioning extension was initially based on semantic versioning, but 
> the result was to be able to support all RDAP extensions universally 
> independent of the versioning type chosen.
>
[PK] RDAP extensions are not an universal software someone creates to 
co-exist also in some other context. The specifications are tailored 
solely to exist within RDAP ecosystems, so I see no harm (other than 
some engineer having a different opinion or liking) of defining one 
concise versioning schema the whole ecosystem can rely on.

Too much choice is also harmful. We will end up in a system, where some 
clients won't be kept up to date with all versioning schemas published 
in IANA registry rendering weaker interoperability.

> All the existing RDAP extensions use opaque versioning,
>
[PK] The term "opaque versioning" is only defined by versioning draft 
putting current status into certain framing. It would be equally true to 
say that all existing RDAP extensions use no versioning.
>
> except for the versioning extension itself and jscontact extension. 
> The semantic versioning may be used more in the future, but I believe 
> a mix will remain.  Since there are two types of versioning in the 
> RDAP extensions, I believe it’s best to formally define them in the 
> versioning extension and since they’re being registered as entries in 
> the RDAP JSON Values Registry, we should provide support for new types 
> of versioning if there is the need.  We may never have that need, but 
> I believe it helps to have the ability without the need to define yet 
> another versioning related extension in RDAP.
>
[PK] For me this is not a mix or two types, but an introduction of a new 
feature "version" which renders 2 states: no version, or with version as 
per specification. I think it would be fully acceptable also to define 
migration path from no version to a with version variant. Taking a fixed 
notion that "no version" is always 1.0 would fix a lot of corner cases, 
like allowing servers to announce 1.0 even without extension 
specification needed to change. No need for "type" property, no need for 
RDAP JSON Values Registry. And if the only type would be Semantic 
Versioning, you can build upon all properties of it when developing the 
protocol further.

One of the properties of Semantic Versioning is an ability to put all 
versions in order based on version number. The other property is that 
versions can tell something about compatibility.

Opaque versioning does not have these properties. Other future 
versioning types may also have no such properties and maybe introduce 
new properties.

This means that you cannot universally rely on any of those properties 
when designing the protocol. This will end up in fragmentation in the 
implementation across the whole ecosystems or (a more likely scenario) 
the clients would just ignore any future types or the semantics of 
versioning at all.

Kind Regards,

Pawel

> Thanks,
>
> -- 
>
> JG
>
>
> cid87442*image001.png@01D960C5.C631DA40
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *"[e-mail]" <[e-mail]>
> *Date: *Friday, November 15, 2024 at 12:15 PM
> *To: *James Gould <[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] Re: RDAP versioning draft feedback
>
> Hi James,
>
> Let's say I not in agreement to say that full Semantic Versioning" 
> could not be applied (see https://semantic-versioning.org/ 
> <https://secure-web.cisco.com/1Qf0tbxvsJxU970WaA3SdHrn0K8dEmkJfg6RmxuBtWmIzmiKcxg5b7_Rpk-zv1TGHAllkJd1wmL0ySJzzpdLJ94AZrlOu84nV2aatZN78QmeLeXgb5iYwMkDUZRI7AtWa1nTJyuXA9SzssAcx6vhuICT90gkO8SrqePEbrO0FyhB3gqgtLiL6MXixB6dn2MrlUSgZ450GlvSnaNJlhmU6rR5-wp-Wvk_MJ6-_z9UHgwC6uBNCQPgvUikAkRJIz4PqBpNTIfmiRXJeaMkdDWFAk1QLbCG3BopM86GYtSX8lY0/https%3A%2F%2Fsemantic-versioning.org%2F> 
> for different applications and use-cases) but I also agree that major 
> + minor is likely what is just enough and relatively easy to implement.
>
> 25 versions of urn:ietf:params:xml:ns:fee is quite a number. All 
> between 0.1 and 1.0 however. The period when a draft is being 
> developed is a specific "experimentation" period, which may or may not 
> justify adding a semantics to the versioning. Anyway, as mentioned I 
> can get convinced why Semantic Versioning can be useful. But why 
> extension point and other, also future, types of semantics add value 
> to the protocol and balance out the negative impact of added 
> complexity for the clients to support it? In your experience with 
> urn:ietf:params:xml:ns:fee it looks like Semantic Versioning worked 
> just fine. You know there are plenty of versioning schemas [1] so 
> picking one and staying there by not offering any extension point 
> sounds to me as a good idea. Otherwise you also need to deal with the 
> situation when some extension comes to an idea of changing their 
> versioning schema. This is not very unlikely as most currently 
> existing extensions would like to move from opaque to something else, 
> maybe without breaking change?
>
> You mention quite a bit of what has been added. I would really like to 
> see also things being removed and/or simplified in the work on a 
> draft. Adding more alternatives in the processing does not make a 
> better standard, rather the opposite.
>
> My proposal would be to drop the "type" property as whole, take 
> Semantic Versioning as the only one and for not versioning aware 
> extensions just not pretend they have versions, because there is 
> always only one, or assign them an arbitrary version null, 0.0 or 1.0.
>
> [1] 
> https://nesbitt.io/2024/06/24/from-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.html 
> <https://secure-web.cisco.com/1dXcD6t69tAYVp3rZWDheZ8hbiJ64QEAW5uG5F-hd5tzRIMU6f2XilQ1jmkOkauf1u52qhI-wpy5-BeXuTkiEp108QpRM_9OKBg5CXwlFO5Cy0-v5WA68ZmZf9TUjCSuzUVegEPMY1GkgQoayMuQyFNX_Et4luNLuGNh50og185LTYrkT_ad0tR_nljr3dBCuKCvdXHp7rdKXwLkJMKgDZqkKWxP9ackvGqHiGXugmiREzvDO-y7T06hVwhXNsaFBSzfKcdOZqyk9b8Tc2-YEH98FrXyNDay8Rh7-uwcKUJo/https%3A%2F%2Fnesbitt.io%2F2024%2F06%2F24%2Ffrom-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.html>
>
> Kind Regards,
>
> Pawel
>
> On 15.11.24 14:07, Gould, James wrote:
>
>     Pawel,
>
>     >> And if semantic would be the choice, why defining an own flavour
>     instead of referring to the external definition? Is a normative
>     reference a problem that there is no official document to refer to?
>
>     >> [1]
>     https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers
>     <https://secure-web.cisco.com/1TAMcxYZeszNmLMTTIqxgeQyUP8gNqS_E-pmMlH5mBF-BE4pjFHIhvZu_LsqdejWxFjLmQjpqB9q1dW02s5Wra4k67deMJ2DQW7lBjsC82Tqn1W0N4ytA5jUsMh-xOZBuzqMFDuZ30XwVeNXwTpzGpPyBlt2naNfMNDsi9qtZGAwisMlI1UIo4OiHUr1LuXSBvs9g_i2o3Nq85MEDeXNycN4vCpSIT7Mt4MBtgZoLaGcCX7PBdlBUehmcE3dS2TcZBjwxUW6J_ZJWGRG6L0VSb0bGflN0LHkDQaqTu2tVpjY/https%3A%2F%2Fpackaging.python.org%2Fen%2Flatest%2Fspecifications%2Fversion-specifiers%2F%23version-specifiers>
>
>     We do have an informative reference to Semantic Versioning 2.0
>     (https://github.com/semver/semver/blob/8b2e8eec394948632957639dfa99fc7ec6286911/semver.md
>     <https://secure-web.cisco.com/18ch1FuavhxZKCP19mRvbGx0FmEe1D5aFL5T3et8nhfdDnuHA-uDOlIJGxkzzU_IhNEMTUA7fqNYXiB_p3oic8WoHumxFV2iTQT1G1CoBUZB34uN0KPZB87jRDGwWvmfxyqiUVoAR_J3oNNlvFdOeGASVgAXv7nRejXYuOOEthxtyZ0Zn49ZLc-YnkmTRwenYl2LYh4o4wTKCFHyXgJOvER_yK5yXR4J0ZxpAoBKmuAv8ZgV733OvINO8bD554YuAZb3DOOHZgXH2xkGjKmQyfeUdACG79ZE7Af_wIw7gFFQ/https%3A%2F%2Fgithub.com%2Fsemver%2Fsemver%2Fblob%2F8b2e8eec394948632957639dfa99fc7ec6286911%2Fsemver.md>),
>     but versioning of an interface is different from versioning of
>     software.   The semantic versioning definition in
>     draft-ietf-regext-rdap-versioning matches the experience that
>     we’ve had with versioning in REGEXT for EPP extensions, using the
>     version of the XML URI. Please review the progression of the
>     Registry Fee Extension (draft-brown-epp-fees ->
>     draft-ietf-regext-epp-fees -> rfc8748) XML URI as a concrete
>     example of the value of semantic versioning as defined in
>     draft-ietf-regext-rdap-versioning.  I know the value firsthand by
>     implementing each version of the Registry Fee Extension and being
>     capable of deploying in Production multiple versions in parallel
>     with the version reflected in the EPP Greeting and negotiated by
>     the client in the EPP Login.  It was the Registry Fee Extension
>     that truly opened my eyes to the value of the versioning.  As a
>     co-author of the DNSSEC EPP Extension in rfc5910, having used
>     semantic versioning would have reduced my concern related to
>     making non-backward compatible changes in the draft, since we were
>     implementing it at the same time.
>
>     Extension versioning will be an important element of the RPP work
>     as well, where we need to consider it from the start.
>
>     Thanks,
>
>     -- 
>
>     JG
>
>
>
>
>     *James Gould
>     *Fellow Engineer
>     [e-mail]
>     <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     Verisign.com
>     <http://secure-web.cisco.com/1su6c-MD35ZcMgTlUEQBv5ixU3Vay5BqUMdkd1pnxLHtVI5o5tRDRiS7DkSXw3TFG7AimiG1LQEx05-lVG-sv307eVGA-BWmfVQdzxk1wHEbDYEu77I2X4J_-Sf4H-tYB5PqhnffN9AU9Kyvp6WnuEvzmVRI6VbhKSrhfoY91RJfMCNP0zxw8JcYcYKPjftU0yVw0Ep4s9tiyZGwK5m1ONS998ymwDATPToRSorzdDUW7pPR6B6CnixKC1IuEXOk8I7IhSx97oivXmr6lgr9YszmFdawle8122-XBi79ro4k/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *"[e-mail]" <mailto:[e-mail]>
>     <[e-mail]> <mailto:[e-mail]>
>     *Date: *Friday, November 15, 2024 at 6:48 AM
>     *To: *Mario Loffredo <[e-mail]>
>     <mailto:[e-mail]>, James Gould
>     <[e-mail]> <mailto:[e-mail]>,
>     "[e-mail]" <mailto:[e-mail]> <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>     *Subject: *[EXTERNAL] Re: [regext] Re: RDAP versioning draft feedback
>
>     Hi Mario,
>
>     Talking about opaque I had in mind an approach, where an extension
>     could use different extension identifier (but of course same
>     path/attribute/parameter prefix) if the new version would be a
>     breaking change and keep the same extension identifier but signal
>     different version though the extension if non-breaking change is
>     introduced.
>
>     In this scenario clients would be only interrupted by a breaking
>     change, which they would be anyway if in semantic scenario the
>     version would change from 1.1 to 2.0. So the impact is not bigger
>     in this respect.
>
>     Changing extension identifier on a breaking change would be right
>     anyway for a client not supporting "versioning" extension, so
>     knowing only though extension identifier in rdapConformance that
>     some breaking change happened.
>
>     If the "non-breaking" rules assure, that any client on the same
>     major version as the server, ahead of behind of the server, can
>     process a response correctly then there is no interoperability
>     issue there even if the version announced by the server is unknown
>     to the client.
>
>     On the request side, the client may be ahead of the server in
>     "non-breaking" increment and try to send a request to an added
>     function or parameter. In this scenario the client would know
>     which version the server announces and would know if server is
>     able to process this function or parameter. The only situation
>     where semantic version would offer value would be if the server
>     would announce a version not known to the client. The client
>     knowing the versions it supports, for example 1.0, 1.1 and 1.3,
>     would know which function to use by knowing that and unknown
>     version 1.2 is between. So it would know to use 1.1. For opaque it
>     would be unknown to the client so the only fallback solution would
>     be to use only the very first version 1.0 in this example.
>
>     For major version change even this logic does not work. If the
>     client would know versions 1.x and 3.x it does not mean it can
>     work with 2.x major version as the scope of breaking change
>     between major versions is undefined.
>
>     So all in all a lot of ifs and whens to arrive to the scenario
>     where ordering of the version increments adds value. The number of
>     versions that we expect is then decisive to see how often these
>     ifs and whens take place in reality.
>
>     Anyway - if there is a lot of support to keep semantic versioning,
>     I am not fully against it - if we are aware how little added value
>     it really is.
>
>     What I am more reluctant to see is to support different types of
>     versioning, and offer an extension point to offer even more types
>     of versioning. It's like saying: we cannot agree on one way, so
>     let's offer all of them. This is really making life of a client
>     difficult and diminishing the added value of semantic versioning.
>     If the client would see any new versioning type it would only have
>     a choice it fallback treating it as opaque.
>
>     My final take on this would be to say: let's stick to only one
>     versioning type - opaque or semantic - does not matter. One will
>     be just enough. Other project can live with it very good. See
>     Python [1] as example. They deal with other version schemas by
>     just saying: you may use whatever you like internally, but for
>     interoperability just convert it to the schema as defined here.
>
>     And if semantic would be the choice, why defining an own flavour
>     instead of referring to the external definition? Is a normative
>     reference a problem that there is no official document to refer to?
>
>     [1]
>     https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers
>     <https://secure-web.cisco.com/1TAMcxYZeszNmLMTTIqxgeQyUP8gNqS_E-pmMlH5mBF-BE4pjFHIhvZu_LsqdejWxFjLmQjpqB9q1dW02s5Wra4k67deMJ2DQW7lBjsC82Tqn1W0N4ytA5jUsMh-xOZBuzqMFDuZ30XwVeNXwTpzGpPyBlt2naNfMNDsi9qtZGAwisMlI1UIo4OiHUr1LuXSBvs9g_i2o3Nq85MEDeXNycN4vCpSIT7Mt4MBtgZoLaGcCX7PBdlBUehmcE3dS2TcZBjwxUW6J_ZJWGRG6L0VSb0bGflN0LHkDQaqTu2tVpjY/https%3A%2F%2Fpackaging.python.org%2Fen%2Flatest%2Fspecifications%2Fversion-specifiers%2F%23version-specifiers>
>
>     Kind Regards,
>
>     Pawel
>
>     On 15.11.24 10:11, Mario Loffredo wrote:
>
>         Hi Pawel,
>
>         plase find my comments inline prefixed with [ML].
>
>         Il 14/11/2024 16:00, [e-mail] ha scritto:
>
>             Hi Mario,
>
>             I would really like to see how many versions we envision
>             to be facing in the lifecycle of an extension.
>
>         [ML] Honestly don't know how many versions an extension could
>         have, they could be many or just one.
>
>         If we also consider the versions before publishing the spec
>         (which are versions themselves) , the number of versions is
>         not so little.
>
>         In addition, we should consider that RDAP is still in its
>         growth phase  and most of the extensions published so far have
>         little or no implementations.
>
>         I expect that some of them will be revised as the number of
>         live implementations will be increasing.
>
>         Anyway this not the point in my opinion. The point is to make
>         both clients and servers to face the lowest impact in their
>         own implementation when managing the transition between two
>         versions.
>
>             We are talking here not of version of an application
>             software, but of a specification. So not every server
>             change would lead to deprecation process. The
>             specifications do not rotate that often to justify
>             semantic versioning. Especially the draft defines own
>             semantic versioning instead of taking just the one from
>             https://semver.org/
>             <https://secure-web.cisco.com/1m_XvHhIMAHsqio0iVdfOVqY2WCo1gexIKPvp8acrzfusb-Cpnk1svtdEvSKe35t6D0PJ5cKCLPEHG5xFiUQXJjv5_nZ30CQGsWMtZAq6wltWz_qO8Tyw1vtptpA8Q-8dOhY_pefreho4SwuT5wmT3fmvFv3aKWT10OEdIircivQf5GepkOt58O1NlbkjbzN5iADy8NBdLfo6gtp38zRK7cC2fYMyYgvLPvElP7Tfb3vFfRCnlNnXaAA_uwZ5UnlxyGEoybNKVaUk6Ql1aKHnwXlXQIoDx0-9dR3wnCroWv0/https%3A%2F%2Fsemver.org%2F>
>             which means custom development to be compliant.
>
>         [ML] As I wrote above, what concerns me the most about opaque
>         versioning is that any change to the extension has always the
>         maximum impact to both client and server implementations.
>
>             If there is no-braking change then the version is just
>             informational for the client.
>
>         [ML] I'm not convinced about that. When opaque versioning is
>         used, every change results in managing a transition process
>         regardless of whether the change breaks the API or not and the
>         impact on both client and server implementations is always the
>         maximum, i.e. any update to a spec extending RDAP with both
>         query and response features affects all of them regardless of
>         the actual scope of the update.
>
>         Let's take for example the reverse search extension. if opaque
>         versioning was the only one into force and I had to simply add
>         an optional member to the reverse_search_properties JSON
>         member of the help reponse, I should manage the duplication of
>         both reverse_search_properties and
>         reverse_search_properties_mapping response members as well as
>         the duplication of all the paths including the segment
>         "/reverse_search/".
>
>         Not so efficient, if we think that, in this case, servers
>         could signal clients about the existence of a new version in
>         their implementation and easily manage the transition between
>         the two versions by leveraging the JSON feature that allows
>         clients to ignore the optional unknown JSON members. On the
>         other side, clients could simply add the handling of the
>         optional JSON member in their implementation at their convenience.
>
>             If there is a breaking change then the client must be
>             aware of the version it supports and this can be covered
>             likely with the same effect by taking new extension
>             identifier. Also here range compatibility, that semantic
>             versioning brings, is likely more than needed for the use
>             case.
>
>         [ML] I personally see that opaque versioning is more suitable
>         to manage breaking changes as it inherently allows to isolate
>         the extension features in the implementation while semantic
>         versioning is preferable to manage non-breaking changes as it
>         allows to preserve those extension features which are not
>         directly affected by the change.
>
>         I recap here in the following a list of possible breaking and
>         non-breaking changes. Based on it, I'm inclined to think that
>         the former would be much less likely than the latter.
>
>         *Breaking changes include:*
>
>          1. *removing an entire operation*
>          2. *removing or renaming a parameter*
>          3. *removing or renaming a response field*
>          4. *adding a new required parameter*
>          5. *making a previously optional parameter required*
>          6. *changing the type of a parameter or response field*
>          7. *removing enum values*
>          8. *adding a new validation rule to an existing parameter*
>          9. *changing authentication or authorization requirements*
>
>         *Additive (non-breaking) changes include:*
>
>          1. *adding an operation*
>          2. *adding an optional parameter*
>          3. *adding an optional request header*
>          4. *adding a response field*
>          5. *adding a response header*
>          6. *adding enum values*
>
>         Another possible solution to partially limit the impact of a
>         version change when opaque versioning is used could be to
>         define as many opaque extension identifiers as the features
>         defined by the extension so that a change in one feature
>         wouldn't affect the others. This has been used with different
>         purposes in the rir-search draft.
>
>         Best,
>
>         Mario
>
>             Kind Regards,
>
>             Pawel
>
>             On 12.11.24 12:18, Mario Loffredo wrote:
>
>                 Hi Pawel,
>
>                 Il 12/11/2024 08:27, [e-mail] ha scritto:
>
>                     Hi Jim,
>
>                     Looking forward to more motivation information
>                     from the authors then and Andy.
>
>                     Adding yet another versioning type seems to me
>                     going into direction of even more complexity. My
>                     argument was rather to just stay with opaque and
>                     restrain from defining anything beyond that.
>
>                 Based on the fact that the use of opaque versioning
>                 results in managing a deprecation process at every
>                 server change, I believe that semantic versioning goes
>                 into direction of less complexity.
>
>                 AFAIK changes on REST APIs are most likelty additive
>                 as the must is to avoid breaks as much as possible,
>                 likewise I expect the same trend in RDAP.
>
>                 Hence, IMO semantic versioning would be preferable.
>
>                 Best,
>
>                 Mario
>
>                     I would like also to feedback on this particular
>                     issue of normative MUSTs in "start" and "end"
>                     attributes.
>
>                     > [JG] I’m not clear why removing an expired version from the
>                     list of returned with a normative MUST poses an
>                     issue.  A client would know based
>                     > on the normative MUST that any “end” extension
>                     version identifiers would not have already
>                     expired.  Clients will know in-band when an
>                     > extension version identifier is going to be
>                     supported or going to be removed.  This does come
>                     into play when a server is implementing an
>                     > Internet Draft that goes through many versions. 
>                     An example is changing the versioning extension
>                     from version “0.2” to “0.3” in draft-ietf->
>                     > regext-rdap-versioning-02.
>
>                     From the draft:
>
>                     "start:" - [...] Once the date and time has
>                     passed, the "start" member MUST be removed.
>
>                     "end" - [...] Once the date and time has passed,
>                     the extension version object MUST be removed and
>                     the extension object MUST be removed if the last
>                     extension version object is removed.
>
>                     There seems to be a lot of focus put on time as
>                     the prime dimension when the versions are phased
>                     in or out. I would argue it is the only way of
>                     doing it or even if this is the common operational
>                     practice these days.
>
>                     In case of "end" it shall communicate, that after
>                     this date the extension version may not be
>                     available anymore. It should remain purely
>                     informative and tell the client: "if you are using
>                     this extension, you likely have a problem beyond
>                     this date. Take care to move to a newer version or
>                     other functionally equivalent extension". No more
>                     than that. Operationally the operator may for
>                     example want deploy a new version of RDAP server
>                     without support for this particular extension
>                     version after this date, not to break this
>                     promise, so it should be just OK to have a version
>                     supported beyond the date announced as "end".
>
>                     Similar for "start", if this ought to be an
>                     information when operator would start supporting
>                     the version and be an indicator that the version
>                     is not yet there, but will be... eventually. The
>                     operator should be able and allowed to deploy it
>                     even before this date or also after. Other aspect
>                     is if the operator will even have enough
>                     information to provide "start" date if the RDAP
>                     server software would be coming from a third party
>                     and the software provider wouldn't be able to tell
>                     when the operator would deploy the new version, so
>                     it would have to be a kind of configuration option
>                     that the operator would have to maintain.
>
>                     So if the new version of the extension is
>                     deployed, the "start" date would just disappear.
>                     So I would rather state the "start" MUST NOT be
>                     announced for an already supported extension
>                     version. Or would that also not always be true?
>                     For example if the operator would like to have an
>                     extension version supported, but as "preview" or
>                     "beta"? Would "start" then indicate an official
>                     support? Just don't get me wrong - I'm not trying
>                     to add even more features, rather to state that
>                     "start" is either operationally difficult,
>                     misleading or semantically not precise enough to
>                     be useful. So let's rather drop it.
>
>                     Just a proposal: maybe the whole lifecycle could
>                     be done much easier just providing a simple status
>                     field to the extension version: "deprecated",
>                     "productive" (default if not provided), "beta". 
>                     For "deprecated" maybe "supportedUntil" could be
>                     useful.
>
>                     And one more thing.
>
>                     The draft is about extension versioning. How about
>                     RDAP version itself? If the argument would be that
>                     clients need all of those functionality of
>                     versioning for interoperability, wouldn't it be to
>                     the same way applicable to the protocol itself? It
>                     would be useful for the clients if there would be
>                     one mechanism same for protocol and extensions,
>                     not two.
>
>                     Kind Regards,
>
>                     Pawel
>
>                     On 11.11.24 18:52, Gould, James wrote:
>
>                         Pawel,
>
>                         Pawel, thank you for your feedback.  The
>                         co-editors of the versioning and x-media
>                         drafts met at IETF-121 and agreed to the
>                         following:
>
>                          1. Add reason language to the semantic
>                             versioning section.  Andy Newton is going
>                             to provide the use case information that
>                             is associated with his experience with
>                             investigating RDAP issues.
>                          2. Look to add more meta-data in the /help
>                             response.  Andy Newton to provide sample
>                             JSON for the additional meta-data.
>                          3. Update x-media to reference the Extension
>                             Version Identifier ABNF in versioning,
>                             which will ensure compatibility.
>                          4. Add support for temporal versioning, based
>                             on RFC 3339
>                             <https://secure-web.cisco.com/1JrgkzCmfZR2ujZ67HgDtJbp1S0Wmx5s_GKwkLsOf9zBsFbSUsI2FNMHiA6nc20xeK2IVa3MZ38LOZ64fXrYUL6_jAS_1NcSmrZiro-UIkARjIfsT19phNMbhyLUuXEXf1F5hFiPSl4FEHZ5aM-BPjEeO_WWOWGiFB5vdnzry_0_hgz-odB3Mcsw875E-AWJL8iZAbeP3P7VofiKRRMQac9L2N6cfwj-OTjj-iR0sqC1bjyyoIcS5VFf5HXWOZvMLJcrtTSyoFh0QW50LzYhsA6uxYpV8USaedgA0OQsgFc4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3339>.
>
>
>                              1. It would be good to get your feedback
>                                 with adding a third versioning type,
>                                 since you asked the question about the
>                                 need to define and register the
>                                 versioning types.
>                              2. To answer your question, we know that
>                                 there are two types of versioning
>                                 (opaque and semantic) discussed thus
>                                 far, but there may be other types
>                                 considered in the future.  Adding the
>                                 temporal version type would provide
>                                 another example.
>
>                          5. “rdapx” to be added in the RDAP Extensions
>                             Registry for x-media.
>                          6. x-media to look to use “rdap-x+json” in
>                             the accept header and to use the existing
>                             “rdap+json” in the content-type header. 
>                             Andy Newton will check with SMEs on this.
>                          7. Agreed to keep the x-media and versioning
>                             drafts separate with normative reference
>                             between them.
>
>                         I provide additional responses to your
>                         feedback embedded below, prefixed with “[JG]”.
>
>                         -- 
>
>                         JG
>
>
>                         cid87442*image001.png@01D960C5.C631DA40
>
>                         *James Gould
>                         *Fellow Engineer
>                         [e-mail]
>                         <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>                         703-948-3271
>                         12061 Bluemont Way
>                         Reston, VA 20190
>
>                         Verisign.com
>                         <http://secure-web.cisco.com/1IYoHTWD33a6zVfkmbIo32wgrRQXBp6NX9kZqbCUJ_YUoMkDfDcDjBGyzqxQgH7VmjPQVRrET_8iS8HcFHpQR4OyIYSMW22coEJFjeXvXx0ct6ZmbxV37-Dldqq7jql2ZqZCC4TbblgOHSTUMnftrlMKGw5Gf0h2AZUfwMUWBlDci8hfEWTAFk_dls5fuqt-e9M8Q2SyKcizzBtTar0KMjTyPo3nKJLnubU1shL0vzpry0HSxynnc6tFkZ1DR_2FswQXxFPE_TwW2TWrd8K_S89XmZUxfFCiYiaOuDOCpyMY/http%3A%2F%2Fverisigninc.com%2F>
>
>                         *From: *"[e-mail]"
>                         <mailto:[e-mail]> <[e-mail]>
>                         <mailto:[e-mail]>
>                         *Date: *Monday, November 11, 2024 at 12:02 PM
>                         *To: *James Gould <[e-mail]>
>                         <mailto:[e-mail]>,
>                         "[e-mail]" <mailto:[e-mail]>
>                         <[e-mail]> <mailto:[e-mail]>,
>                         "[e-mail]" <mailto:[e-mail]>
>                         <[e-mail]> <mailto:[e-mail]>
>                         *Subject: *[EXTERNAL] Re: [regext] Re: RDAP
>                         versioning draft feedback
>
>                         Hi Jim,
>
>                         To recap on what we discussed in Dublin and to
>                         also have input from the working group.
>
>                         Jasdip stated a very valid question. Reading
>                         through the draft in more detail I also have a
>                         feeling that we are trying to use a
>                         sledgehammer to crack a nut.
>
>                         The problem to solve was that RDAP was lacking
>                         of clear way of signalling that there is a
>                         different version of the same extension, so
>                         the client would know that foo1 and foo99 are
>                         indeed version of the same extension and not
>                         different unrelated extensions.
>
>                         What the draft proposes is very feature reach,
>                         but does not tell a lot about why clients and
>                         servers should spend time implementing all of
>                         its features. Do we expect an RDAP extensions
>                         to have tens or hundreds of versions, so that
>                         the clients would need to apply a logic of
>                         semantic versioning to work on ranges of
>                         versions and distinguishing major and minor
>                         versions? If we talk about extensions from
>                         IETF control this is not likely to happen,
>                         just because of how IETF process works. Why do
>                         we need extensibility to even support more
>                         versioning semantics (Versioning Type)?
>
>                         [JG] We will be adding the reason language for
>                         the semantic versioning, but providing the
>                         meta-data in the /help response would help for
>                         software clients and client users trying to
>                         troubleshoot issues. The versioning type
>                         definition and registration makes sense for
>                         what we know today.  Other forms of versioning
>                         could be created in the future with the
>                         temporal type in, based on RFC 3339
>                         <https://secure-web.cisco.com/1JrgkzCmfZR2ujZ67HgDtJbp1S0Wmx5s_GKwkLsOf9zBsFbSUsI2FNMHiA6nc20xeK2IVa3MZ38LOZ64fXrYUL6_jAS_1NcSmrZiro-UIkARjIfsT19phNMbhyLUuXEXf1F5hFiPSl4FEHZ5aM-BPjEeO_WWOWGiFB5vdnzry_0_hgz-odB3Mcsw875E-AWJL8iZAbeP3P7VofiKRRMQac9L2N6cfwj-OTjj-iR0sqC1bjyyoIcS5VFf5HXWOZvMLJcrtTSyoFh0QW50LzYhsA6uxYpV8USaedgA0OQsgFc4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3339>,
>                         may being added to the draft as well.  Please
>                         let us know whether you support adding the
>                         temporal type.  I know from implementing EPP
>                         extensions that are not RFCs, having
>                         versioning provides isolation and the ability
>                         for the co-editors to encourage implementation
>                         without risking breaking clients.
>
>                         What we expect clients to do with all the
>                         related lifecycle information
>                         (start/end/default)? I can make some
>                         usefulness for the "end" attribute (like
>                         warning about using deprecated interface), but
>                         mandating the server (normative MUST) to
>                         remove the support exactly at this time seems
>                         like a void requirement, as operationally
>                         quite hard to fulfil unless the server would
>                         implement special logic for management of
>                         versions of extensions. A bit of overhead for
>                         very little gain if you ask me. "start" is
>                         something with even less usefulness as we are
>                         talking about future version. Here there are a
>                         lot of assumptions that the server deploys a
>                         future version and only activates it later at
>                         a given point in time. Again a logic not
>                         really needed. The client will learn about new
>                         version when it's there and supported by
>                         client anywhere.
>
>                         [JG] I’m not clear why removing an expired
>                         version from the list of returned with a
>                         normative MUST poses an issue. A client would
>                         know based on the normative MUST that any
>                         “end” extension version identifiers would not
>                         have already expired.  Clients will know
>                         in-band when an extension version identifier
>                         is going to be supported or going to be
>                         removed.  This does come into play when a
>                         server is implementing an Internet Draft that
>                         goes through many versions.  An example is
>                         changing the versioning extension from version
>                         “0.2” to “0.3” in
>                         draft-ietf-regext-rdap-versioning-02.
>
>                         I would double what Jasdip stated below, that
>                         opaque versioning - with just adding semantics
>                         to one symbol "-" splitting extension
>                         identifier into name and version would do the
>                         same good job and be a way simpler.
>
>                         [JG] Adding the use of the ‘-‘ delimiter with
>                         a version is exactly what
>                         draft-ietf-regext-rdap-versioning is doing,
>                         but maintaining compliance with the base RDAP
>                         RFCs by not touching the extension identifiers
>                         in the rdapConformance.
>
>                         If someone would like to release a new version
>                         of their extension every month (as sais likely
>                         outside of IETF), another semantic for
>                         versioning would be good for it and within the
>                         opaque version part. But then it might be a
>                         part of their particular specification and
>                         would only concern clients dealing with this
>                         particular extension.
>
>                         K.I.S.S.
>
>                         [JG] The external version identifier pretty
>                         much matches the concept of the XML URI in EPP
>                         and the extension identifier prefix matches
>                         the concept of the XML prefix, which means
>                         that an updated draft can add features
>                         reflected in the version extension identifier
>                         without having to touch the extension
>                         identifier prefix.  The whole idea is not to
>                         require to communicate versions out-of-band
>                         (e.g., EPP 03/07 or 05/07 for those that have
>                         been around for a while) when the extension
>                         identifier does not change between extension
>                         versions with material changes.
>
>                         Kind Regards,
>
>                         Pawel
>
>                         On 03.11.24 22:50, Gould, James wrote:
>
>                             Rationale for versioning:
>
>                             Section 1 says, “The RDAP Conformance
>                             values are identifiers with no standard
>                             mechanism to support structured,
>                             machine-parseable version signaling by the
>                             server.” It’d be good to elaborate with
>                             usage scenarios where such structured
>                             versioning is a value-add for clients
>                             beyond what the opaque (no inner meaning)
>                             extension identifiers from STD 95 afford.
>                             Let’s say an extension is “foo1”, then
>                             “foo99”, and later “foo2” in terms of
>                             “versions”. The server announces its
>                             support for these non-structured
>                             extensions, say, on its web site or
>                             through the “rdapConformance” member in a
>                             /help response, and the clients can then
>                             negotiate a particular non-structured
>                             version of this extension using the
>                             standard HTTP content negotiation
>                             methodology (e.g., using the RDAP-X media
>                             type). In the spirit of what-not-to-do, it
>                             is fair for a client to ask: Why should I
>                             go through the overhead of processing the
>                             “versioning_help” member? What value-add
>                             does it get me? Is it in some way a better
>                             discovery and/or negotiation method for
>                             RDAP extensions? Would be good to beef up
>                             the rationale for structured versioning.
>
>                             JG – We need to ensure that RDAP-X
>                             supports the extension version identifier
>                             as well, so there should be no variance
>                             between the versioning extension and the
>                             RDAP-X extension.  We can add more
>                             rationale in Section 2 “Semantic
>                             Versioning”, where a server could support
>                             multiple versions of an extensions that
>                             are signaled as related.  For the
>                             versioning extension itself, there have
>                             been multiple versions of it that are not
>                             structurally different and not backward
>                             compatible, with the latest version being
>                             “versioning-0.3”.  Other RDAP extensions
>                             could leverage semantic versioning during
>                             development to encourage implementation
>                             with version isolation and with clear
>                             relationship between the extension version
>                             identifiers.  Do you believe that we
>                             should look to add the concept of
>                             relationships between opaque version
>                             identifiers?
>
>                         Kind Regards,
>
>                         Pawel
>
>
>
>
>                     _______________________________________________
>
>                     regext mailing list [e-mail]
>
>                     To unsubscribe send an email [e-mail]
>
>                 -- 
>
>                 Dott. Mario Loffredo
>
>                 Senior Technologist
>
>                 Technological Unit “Digital Innovation”
>
>                 Institute of Informatics and Telematics (IIT)
>
>                 National Research Council (CNR)
>
>                 Address: Via G. Moruzzi 1, I-56124 PISA, Italy
>
>                 Phone: [phone]
>
>                 Web:http://www.iit.cnr.it/mario.loffredo <http://secure-web.cisco.com/1curENROzeNyONatI_LjVV2i4Tv5EItE_Fi7hHY2inbbyW-p4a7wf_RXldP8Z0YOKnnDUO30fBi_FLBp1IsXn-Tov-cutSSzCCVto2dtyVDelrVmD21lKOaXUFqWASFmNFFnInUFlcAXjao4qdvEDpyBfaL5y-ImMR4vb0wcSMbXnCxzvTOnYQGAj2ulWELlzIOyxm6DUJBu0LX0JCDMqkQ8m21V7rB7hkcWvwGv5x8et8d8v3I-ou78umkRAQ6RrFpwAcHkVD7HPE8qogRF2DQvQPiH56boHfXB6WOyB6Yg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
>         -- 
>
>         Dott. Mario Loffredo
>
>         Senior Technologist
>
>         Technological Unit “Digital Innovation”
>
>         Institute of Informatics and Telematics (IIT)
>
>         National Research Council (CNR)
>
>         Address: Via G. Moruzzi 1, I-56124 PISA, Italy
>
>         Phone: [phone]
>
>         Web:http://www.iit.cnr.it/mario.loffredo <http://secure-web.cisco.com/1curENROzeNyONatI_LjVV2i4Tv5EItE_Fi7hHY2inbbyW-p4a7wf_RXldP8Z0YOKnnDUO30fBi_FLBp1IsXn-Tov-cutSSzCCVto2dtyVDelrVmD21lKOaXUFqWASFmNFFnInUFlcAXjao4qdvEDpyBfaL5y-ImMR4vb0wcSMbXnCxzvTOnYQGAj2ulWELlzIOyxm6DUJBu0LX0JCDMqkQ8m21V7rB7hkcWvwGv5x8et8d8v3I-ou78umkRAQ6RrFpwAcHkVD7HPE8qogRF2DQvQPiH56boHfXB6WOyB6Yg/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>