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

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