Consensus on Deploying QUIC v1 with HTTP/3

Dear QUIC WG,

(HTTP WG is bcc'd)

As you may be aware, the QUIC v1 specifications entered AUTH48 state
recently and they are making good progress (thanks editors!). The HTTP/3
and QPACK documents have a dependency on the "HTTP core" documents being
worked on in the HTTP WG, so we expect them to take a little longer.

The drafts submitted to the RFC editor define QUIC version "0x00000001" [1]
and HTTP/3 ALPN identifier "h3". They include the clear instruction "DO NOT
DEPLOY THIS VERSION OF {QUIC, HTTP/3} UNTIL IT IS IN AN RFC".

HTTP/3 is explicitly tied to a version - the "h3" identifier is expected to
be used with QUIC "0x00000001". As several folks have observed on the list
[3][4] or in Slack, once the QUIC RFCs are published, 0x00000001 can be
used in deployment. But the longer lead time for HTTP/3 RFC creates some
grey area on what ALPN to use. Waiting for the HTTP/3 RFC delays deployment
of QUIC version 1 at the earliest convenience, which is unfortunate given
that the design has IETF consensus.

The Chairs have tracked various discussions and we believe there is
significant deployer interest in deploying "h3" as soon as the QUIC RFCs
are published and before the HTTP/3 RFC is published. Furthermore, on
balance of the information at hand, we observe a minimal perceived risk
with deploying "h3" before the HTTP/3 RFC.

This email commences a formal consensus call for permitting the deployment
of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *once the QUIC RFCs
are published*. The call will end on May 13. Please reply to this thread on
the QUIC WG list with any additional comments, thoughts or objections
before then.

Cheers,
Lars, Lucas & Matt
QUIC WG Chairs


[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34
[2] https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34
[3] https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/
[4] https://mailarchive.ietf.org/arch/msg/quic/M_uWXd2yvucnZwFs66g15ZbpJaM/