Re: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt

Hi Ben




On Wed, 9 Mar 2022, 19:44 Ben Schwartz, <bemasc@google.com> wrote:

> I would like to see this draft define a matching SVCB parameter as well.
>

A matching SVCB parameter sounds like a sensible design choice. From a
process perspective is HTTP WG a suitable venue to pursue that?


> This draft seems to be predicated on several assumptions about QUIC
> versioning:
> * The QUIC handshake will always be downgrade-resistant.
> * There will soon be QUIC versions whose Initial cannot be parsed as
> QUICv1.
> * After a QUIC version is defined, it will never gain support for an ALPN
> that predates it.  (Otherwise, the client and server might disagree on
> whether QUICvN supports the given ALPN.)  In principle, this requires that
> definitions of new QUIC versions and new ALPNs do not occur concurrently.
>
> Does the QUIC WG have consensus on these points?
>

Your two first points seem accurate, although I'll defer to the VN experts
in the room to state definitively.

On the third point I'm not sure I follow what you are saying. Imagine a
QUIC version ("bob") was defined that was incompatible with QUIC v1. Let's
say it removed client-initiated bidirectional streams. The "bob" version
can't support the predated "h3" ALPN because the HTTP/3 mapping onto QUIC
would be broken. Somebody could define a new mapping that used a pair of
uni streams for request and response, that mapping would need a different
ALPn value than "h3". In such a scenario don't think there is a hard
requirement on concurrent definitions. But what's needed I people
understanding what features of the QUIC transport version they use, and
what incompatible means.

Cheers
Lucas