Re: ALPN and QUIC versions

[Martin Duke <[e-mail]>]

Hi Spencer,


> 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.
>>
>
> I agree with your reasoning here, but in addition, doesn't that require
> either (1) implementations to support old QUIC versions basically forever,
> or (2) deployed applications to be updated to specify a new ALPN in order
> to retire old QUIC versions?
>

I believe that is correct (hence my parenthetical about deprecating old
versions)


> When we were chartering TAPS, one of the major reasons was to stop
> requiring application updates to take advantage of new transport protocols.
> I know this isn't quite the same thing, but I'm not understanding why
> requiring applications to be updated to specify a new ALPN for a backwards
> compatible version of QUIC (so, little or no benefit for the application)
> would be a GOOD thing.
>

I agree!