- From: Willy Tarreau <w@1wt.eu>
- Date: Sat, 12 Mar 2022 19:10:43 +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>
On Sat, Mar 12, 2022 at 05:23:46PM +0000, Lucas Pardue wrote: > > 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). > > > > I don't agree with this position. We have come a long way in refining our > concepts and terminology of semantic HTTP and wire specific messaging. But note that what we usually call "wire" really has nothing to do with the wire but rather with the immediate next layer when going down the stack. Similarly H3 is not renamed when QUIC is transported over IPv6 (or possibly even datagram UNIX sockets) and those are different "on-wire" representations as well. If the next version of QUIC is incompatible with V1 (say different packet format) but provides similar streams, there's no reason why H3 would have to be mapped differently and it will certainly remain H3. But then if more substantial changes happen, for example let's say that like in H2, QUICvBOB starts to expose the stream number as a preambule of the stream frames, and that nothing else changes, it's perfectly possible that we'll just see an updated RFC saying "H3 frames are prefixed with a 32-bit stream ID when mapped on QUICvBOB and for the rest, please refer to RFCxxxx". And after all there's HTTP/0.9 on top of QUIC which wasn't renamed 2.9 or stuff like that. I think it's important to plan for the possibility to have to rename the protocol if it's not possible to map it (or if it doesn't make sense for efficiency reasons), but I don't think we'd need to make this mandatory at all. Cheers, Willy
Received on Saturday, 12 March 2022 18:11:05 UTC