[regext] Re: RDAP versioning - on client-server interactions and 2-RTT flow

["Andrew Newton (andy)" <[e-mail]>]

below...

On Fri, Nov 22, 2024 at 5:00 AM Mario Loffredo
<mario.loffredo=[e-mail]> 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.
>
> 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.

I note that you use the words "additive changes" but the draft says
"new interface changes" (section 4.2). There probably needs to be some
language about what interface changes constitute a major bump vs a
minor bump.

Earlier in this thread there was a discussion about versioning
schemes. I don't know where it landed, but there are many more types
of versioning schemes than semver. A lot of software is going to dates
like "2024-05". From a CI/CD perspective, a sequence number or
increasing number scheme is more suitable. I'll also note that at
present there appears to be only one extension ever to have multiple
versions: the ICANN gTLD profile. However, it uses opaque versioning
in the identifier, its documents use major.minor but not necessarily
semver as elements required in early versions are optional in the
latest, and the versions are referred to by their year of ratification
(2019 vs 2024). Food for thought.

-andy