Re: ALPN and QUIC versions

[Lucas Pardue <[e-mail]>]

Hi Martin

Speaking as an individual. There's a lot to consider here, I don't have a
complete response.

For a start, I think there are ways to rephrase the applicability draft
text to get over some thorniness - seems I'm on the hook to do that,
reviews will will welcome.

To respond to one of your suggestions


On Wed, 19 May 2021, 16:27 Martin Duke, <[e-mail]> wrote:

>
> 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.
>

I might grade incompatible breaking versions on at least two criteria.
First, is the wire image the same? Second, are the protocol feature changes
that break the contract with upper layers, which would cover removing
features, changing features in ways that break dependent behaviour, adding
features that break dependent behaviour.

Such a grading exercise would appear to be a useful function of the QUIC WG
in the long run. What I mean by this is that (hypothetically) we should
encourage versions to state if their compatibility with other versions is
breaking or non-breaking. The QUIC version IANA table could, for example,
codify some of this.
The group has the expertise to assess such claims and the desire to avoid
version relationship explosion in breadth or depth (I.e. we would heavily
normalize).

QUIC extensions could state the known (at the time of writing) version(s)
that they extend. To keep it simple, they'd just need to state the earliest
registered version on each breaking version. We assume that non-breaking
versions published by the IETF all work. A single QUIC extension document
can define how it extends several breaking QUIC versions. We have a similar
situation right now when defining logically equivalent behavioral
extensions that need to work over H1, H2 and H3.

Application protocols could also state known (at the time of writing)
version(s) that they run over. Same as above.

When future breaking QUIC versions are published, extension and application
protocols can respond. Update documents could be effectively no-op, require
major/minor surgery, or state explicitly that a version is not supported if
they help the strong need to.
To make this activity easier, both extensions and application protocols
(and their extensions!) would benefit from stating the QUIC protocol
features that they depend on. Reviewing those statements is likely a
service the QUIC WG should provide to other groups.

I think this possibly leads to a hybrid option 4, where the ALPN registry
has a column that lists only breaking QUIC versions. And we don't mandate
any rules on the number of versions that a token can relate to.

Cheers
Lucas