ALPN and QUIC versions

[Martin Duke <[e-mail]>]

There appears to be an under-examined sentiment in this WG that the 'h3'
ALPN specifically indicates QUIC version 1. The only spec explicitly
stating it, that I can find, is the applicability draft, and I've
filed an issue
against it <https://github.com/quicwg/ops-drafts/issues/360> [1]. I might
be in the rough here, but I'd like to push back on this design during WGLC
in case others share my concerns.

[TL;DR one ALPN per QUIC version will not scale with many versions and we
should do something else]

quic-http says "HTTP/3 relies on QUIC version 1 as the underlying
transport. The use of other QUIC transport versions with HTTP/3 MAY be
defined by future specifications.," which to me is not quite the same thing
as saying we need a new ALPN.

For the QUICv2 draft there has been some discussion
<https://github.com/martinduke/draft-duke-quic-v2/issues/5> of what the
correct way <https://github.com/martinduke/draft-duke-quic-v2/pull/6> to
specify support for HTTP/3 is. [2,3]

I'm fine with the quic-http wording, but I dislike the text in the
applicability draft. There are a few ways we could actually design the
interaction of applications and versions:

1) As stated in the applicability draft, the ALPN includes the QUIC
version. Then every new version document has to review the set of
QUIC-specific ALPN codes and register new ALPNs. As these version numbers
are 32 bit integers and may not simply increment up from 1, ALPN codes will
often look like h3-0x4384abc0, doq-0x4384abc0 [4], etc. Similarly, each new
application of QUIC has to review the set of QUIC versions and register new
ALPNs for each version. This has the advantage of reducing the need for
version negotiation, but it's not scalable if there are a lot of versions
and applications. The ALPN registry will essentially have a matrix of
applications and QUIC versions with the combination that signifies each.

I imagine most QUIC implementation APIs would present an interface for an
application to declare its ALPNs. I'm not sure how that implementation
easily deploys new versions (or deprecates old ones) if all the apps then
have to change, unless it's mutating the ALPN from an application-provided
root. That seems error-prone.

2) A draft with a new QUIC version MUST formally update any QUIC
application RFC for which it wants to use the same ALPN. Application RFCs
would say which versions can transport them at the time of writing without
a formal update. So to find the available QUIC versions for a given
application RFC, one could see the versions listed in that RFC (which
obviously predate the application) and then note in the header which RFCs
update it (all the compatible versions released since). Mike Bishop suggested
this course of action
<https://github.com/martinduke/draft-duke-quic-v2/pull/6> in [3]. This
property is somewhat convenient, but again, I don't think it scales
incredibly well: if there are many versions, the front page of HTTP/3 could
be filled with RFCs that update it, merely because they say "you can use h3
with this"

3) Add a column to the IANA ALPN Registry
<https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>
[5] that specifically lists the compatible QUIC versions. For most current
entries (which are not QUIC-compatible), this would be empty. New
application or version RFCs could simply update the registry, which will
scale somewhat better than (1) and still be easily discoverable. I am happy
to write a short draft to change the registry if that's how we want to
proceed.

4) There is no formal trail of linkages. New version RFCs should say what
apps they support (possibly as generic as "all v1 applications work with
the new version") and applications should say if (a) the list of usable
versions is other than the full known set and (b) what properties it needs
from a QUIC version to operate. This is the path I took in a v2 PR
<https://github.com/martinduke/draft-duke-quic-v2/pull/6> [3], which has no
official standing whatsoever. This makes the forensics to obtain the full
list of usable versions quite a bit harder, but won't explode the ALPN
registry or the front page of HTTP/3.

There are probably other solutions I haven't thought of. I have
purposefully ignored the whole question of provisional and experimental
versions to keep this at a manageable length.

As you might tell, I would prefer (3) or (4). I would like to confirm I am
in the rough before we ship the applicability draft that [informatively]
mandates (1).

Martin

[1] https://github.com/quicwg/ops-drafts/issues/360
[2] https://github.com/martinduke/draft-duke-quic-v2/issues/5
[3] https://github.com/martinduke/draft-duke-quic-v2/pull/6
[4] I'm happy to bikeshed on decimals vs. hex, if we choose this option.
[5]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids