Regular version releases are the most obvious way to grease the version. However, before we get around to v3 I'd like to ship Version Aliasing instead: https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/
It's a more comprehensive solution that carries security and privacy benefits as well. On Tue, Jan 25, 2022 at 9:12 AM Bill Gage <Bill.Gage= [email protected]> wrote: > How about using the same strategy as planned OS releases - e.g. there will > be a new rolling release of the QUIC spec at least once a year on March 21 > that, as a minimum, greases the codepoints and salts. Officially, the new > release could be identified with a label such as something like > "v01-2022r01" with the actual on-wire version number generated as a hash of > that label. > > If necessary, each new release (and associated on-wire version number) > could also come with a pre-determined sunset date after which it is not > expected to be supported by deployed implementations. Having a calendar for > QUIC updates may also help with planning for all interested parties. > > The label "v01" refers to the RFC of the base protocol, i.e. RFC 9000. If > there is a real change to the base protocol, it can be given the label > "v02" in a new RFC. > > Cheers ... > > /bill > > > Hi Martins, > > > > Wearing no hats. > > > > > > On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, <[email protected]> > wrote: > >> > >> Hello everybody, > >> > >> The following concern just popped up in my mind: > >> > >> Some people (in particular the press,...) may take version numbers very > >> seriously. Reading "QUIC version 2", my guess is that there might be > >> articles saying things such as "Quic already is at version 2" or "Quic > >> version 1 is outdated, use version 2", and so on. > >> > >> Everybody on this list (including me) of course understands that such > >> stuff is completely wrong, and it's easy for people who want to figure > >> out that it's wrong. Nevertheless, there are quite a few instances where > >> version numbers have taken a life of their own. > >> > >> The purpose of this mail is that everybody consider the risk of the > >> above "misunderstandings". If we are fine with that risk, then let's go > >> with "version 2". If we have some doubts, it would be easy to change the > >> version number to something else, such as 1.1, or 0.99, or A.bc, or > >> whatever. > >> > > > > Whatever moniker we chose, I think there will be some part of the > > population that will be surprised and read something more into it than > what > > the specification is attempting to do or solve. Personally I think QUIC > 1.1 > > would be a very bad name though. > > > > I've lost count of the times I've seen a comment like "I've only just > heard > > about HTTP/2, and now there is an HTTP/3?". > > > > This spec will help exercise our version negotiation mechanism and help > > prevent stagnation and ossification. In some sense we are trying to build > > an evergreen transport, to borrow a w3c term [1]. Perhaps people should > > become accustomed to a new version of QUIC being released on a regular > > cycle, so that implementer and operators build out the processes needed > to > > stay compatible and up-to-date. > > > > Cheers > > Lucas > >
