- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 12 Mar 2022 17:39:52 +0100
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Ben Schwartz <bemasc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Duke <martin.h.duke@gmail.com>
Hi Lucas, On Thu, Mar 10, 2022 at 04:08:48AM +0000, 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. I disagree with this. The upper-level protocol indeed defines a mapping, but that mapping is not exclusive. We didn't rename HTTP/1.1 to 1.2 when its mapping over TLS was clarified for example. Instead a new RFC would be emitted to explain how to map H3 to QUICvBOB. This is far more desirable because it allows preservation of all the protocol details from end to end when only the mapping changes. Imagine for example a QUICv1 to QUICvBOB gateway. It would only have to deal with the change of mapping but does not need to redefine a new protocol. Encoding, flow control, compression etc wouldn't need to change. I the worst case an updated protocol spec would be emitted, listing the various known mappings, and would take that opportunity to fix errata and that would be all. Given that QUICvBOB wouldn't know "h3" ALPN by default, it would make sense to reuse the same ALPN precisely to indicate that it's exactly the same protocol but mapped differently (the mapping being dependent on the protocol stack). > 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. Indeed ;-) Willy
Received on Saturday, 12 March 2022 16:40:09 UTC