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
