Re: I-D Action: draft-ietf-quic-v2-01.txt

[Lucas Pardue <[e-mail]>]

Hi Martins,

Wearing no hats.


On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, <[e-mail]> 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


[1] - https://www.w3.org/2001/tag/doc/evergreen-web/



>