FWIW, I REALLY want to encourage the working group to consider a formal statement of how long QUIC versions would be "supported", as in "if someone finds a serious problem, we'll work to fix it", as Bill proposed below.
That might not be the right thing to do, and might even be impossible to commit to in an all-volunteer organization, but I think we have to realize that in the absence of a formal statement of support durations, a lot of people are going to assume that any QUIC version would be supported by the working group "forever". Best, Spencer On Thu, Jan 27, 2022 at 4:20 PM Martin Duke <[email protected]> wrote: > 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 >> >>
