Hi Mario, On 23.11.24 13:57, Mario Loffredo wrote:
Hi Andy, see my responses below. Il 22/11/2024 21:08, Andrew Newton (andy) ha scritto:below... On Fri, Nov 22, 2024 at 5:00 AM Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> wrote:Can you please elaborate on which use case corresponds to support a default version that is six versions back to the next version and no version in between ? Honestly, can't imagine any practical case like the one you described. One coming in my mind is that all the versions between 0.4 to 0.9 could be related to additive changes and the server is able to support all of them.
[PK] We are versioning specification, so the server and the client may pick whichever version increment it likes and does not need to follow the order. So in this example the server implemented 0.4. Then the spec evolved 0.5 through to 0.9 and only then the server decided to implement 0.9, ramping it up as non-default.
The same happens independently for the clients. So at a point in time a client would implement 0.8.
[PK] This is all true, assuming there is always 100% match between the client and the server on the version. Note that here, because we version a specification not an implementation, we may face an unusual situation that the client may be ahead of the server. In this case if client depends on 0.8 functionality, it would not be fine with 0.4 response (missing fields added between 0.4 and 0.8). So, if the server eventually would ramp up 0.9 (not default yet) the client would not get 0.9 response which would be working for him, unless it makes 2-RTT flow and discovers 0.9 version, which it does not know (yet), but which may serve a compatible response for it.Instead, it seems more likely to me the scenario where the client requests for an extension version not yet supported by the server but supported elsewhere (e.g the client requests for version 0.9, but the higher version supported is 0.8).How does this work? If my client requests 0.9 where the JSON "foo":"bar" is mandatory but gets back 0.8 where "foo" was never defined, wouldn't that cause an error? Is the assumption that a client will be programmed to handle both? If so, I don't see that happening. I also think it is unlikely that RDAP server operators will support multiple versions of an extension in production.[ML] In making that example, I was influenced by the definition of major and minor versions given by Semantic Vertsioning (semver.org)/Given a version number MAJOR.MINOR.PATCH, increment the:/ 1. /MAJOR version when you make incompatible API changes/ 2. /MINOR version when you add functionality in a backward compatible manner/ 3. /PATCH version when you make backward compatible bug fixes/Based on it, the increase of the minor version is related to an additive (i.e. non breaking) change while the increase of a major versions is related to a breaking change (just like adding a mandatory property) with a consequent server implementation of a transition process .Since additive changes don't require the server to manage a transition process, multiple versions each one related to an additive change can be supported at the same time even on the live platform.The chain of backward compatible changes gets broken when a breaking change occurs.In that case, the transtion process should be managed on both test and live environments.
The bottom line is, that the clients would either need the implement 2-RTT flow to get an optimum answer, or always support somehow the lowest version that may come from the server missing functionality that may have come from a better version.
This could be solved if the client would be able to make range version requests. For me it would be one of the reasons to bother with semantic versioning at all if machines could figure out on their own the best fit.
If it is not a goal and semantics behind versioning is just for humans, then I would return to my previous position that we shouldn't bother defining any semantics at all and let each extension define their own stuff how they like. It is a waste in my eyes to define and maintain strict rules for versioning with a new IANA registry and all processes around it.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
