W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

Re: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sun, 13 Mar 2022 00:48:43 +1300
Message-ID: <b5be0f8b-b39e-67b4-0328-a03874ef2276@treenet.co.nz>
To: ietf-http-wg@w3.org
On 10/03/22 17:08, Lucas Pardue wrote:
> 
> The model I have, and others might disagreeĀ  (and which might not be 
> expressed well in the draft and as such we'd need to address), is that 
> these version hints are for compatible versions of QUIC related to the 
> Alt-Svc entry that has a single ALPN. For example, QUIC v1 and v2 are 
> compatible and as far as the H3 mapping is concerned, identical. The 
> example given in the spec is
> 
> Alt-Svc: h3=":443"; quicv="709a50c4,1"
> 
> If we publish QUICvBOB and it is incompatible, then H3 on QUICvBOB IMO 
> needs new application mapping and a new ALPN. For example "h3bob". 
> Trying to overload ALPN IDs for all version of QUIC whatever might come 
> is dangerous. On the other side of the coin, defining new ALPNs for 
> *every* variant of a QUIC version is a great way to DoS the IETF and 
> IANA processes.
> 
> In this scenario, if we defined QUICvBOBthesecond, as compatible with 
> QUICvBOB but incompatible with QUIC v1 and v2, then I might expect an 
> Alt-svc like
> 
> Alt-Svc: h3bob=":443"; quicv="b0b2,b0b1", h3=":443"; quicv="709a50c4,1"
> 


AIUI, HTTP assigns a new version to each unique transport mapping. So 
QUICvBOBthesecond by virtue of needing a new mapping gets a new HTTP 
version number and ALPN assigned anyway.


I for one support the draft-duke-httpbis-quic-version-alt-svc proposal.

Though I punt/abstain from having an opinion on whether it should be 
added to rfc7838bis.


Amos Jeffries
Received on Saturday, 12 March 2022 11:52:37 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 12 March 2022 11:52:39 UTC