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. > > 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 _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
