I do think this is worth discussing(again) now that we're about to ship the first application on top of QUICv1 as well as the applicability drafts. We don't have a ton of time to make adjustments, but maybe enough time.
I think Lucas' thinking is heading in a good direction. My mental model is that new versions could declare if they offer the featureset of another version. So I can mint a bespoke version of QUIC and as long as it supports the v1 featureset, it'll use the same ALPN. Could a version of QUIC specify that it supports the features of multiple versions(ie: a version of QUIC like v1 and one that only supports datagrams)? Having every application or extension specify which features it's dependent upon sounds a bit problematic in practice to me, but maybe it's not so bad. There are lots of workable ways to do this, but minting a new alpn for every transport version does seem a bit excessive unless we're not going to have many transport versions. Ian On Wed, May 19, 2021 at 8:09 PM Lucas Pardue <[email protected]> wrote: > 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, <[email protected]> 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 >
