Hi ALPN enthusiasts, Since we've made some good progress on QUICv2, I think it's time to reopen this thread - so I've opened a GitHub issue for it: https://github.com/quicwg/quic-v2/issues/30 In a nutshell, if we don't do anything there won't be a way to deploy QUICv2 without QUICv1 support, and I think we should make that decision consciously. Please send thoughts on the issue.
Thanks, David On Fri, Jun 4, 2021 at 11:49 AM Ian Swett <ianswett= [email protected]> wrote: > 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 >> >
