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

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.


Received on Saturday, 12 March 2022 18:11:05 UTC