- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 13 Mar 2022 00:48:43 +1300
- 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