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!
