Google's implementation uses a 1:1 mapping between an h3 ALPN and a QUIC version. Because of this, when we ship QUIC 0x00000001, it'll be with ALPN=h3.
Our code supports v1/h3 already, but v1/h3 is disabled by default. We'd like to align with everyone to pick a date when we start enabling v1/h3 in production though. >From the conversations I've had, I think everyone agrees that when draft-ietf-quic-http ships as RFC, everyone will be allowed to ship v1/h3. I think everyone also agrees that we shouldn't do that before draft-ietf-quic-transport ships as RFC. The open question is: do we wait for draft-ietf-quic-http or do we move forward when draft-ietf-quic-transport ships? David On Tue, Apr 27, 2021 at 4:04 PM Martin Duke <[email protected]> wrote: > QUIC, sorry the confusion. The original message in this thread included > HTTPbis, and you should reply to that one to keep everyone in the loop. > > On Tue, Apr 27, 2021 at 3:59 PM Martin Duke <[email protected]> > wrote: > >> Damn it, wrong http >> >> On Tue, Apr 27, 2021 at 3:40 PM Martin Duke <[email protected]> >> wrote: >> >>> In the quicdev slack channel today, we realized that we had a disconnect >>> on what ALPN to use in the interval between the QUIC RFCs publishing and >>> the HTTP/3 RFCs being ready (due to a MISREF with http-semantics, etc). >>> >>> It's lost in the slack archives now, but I *think* we had concluded that >>> once the QUIC RFCs ship the endpoints should use 0x00000001/h3, not h3-29 >>> or h3-32, because the chance of something in http-semantics breaking >>> interoperability was nil. I personally don't really care how we converge, >>> as long as we converge. >>> >>> To summarize the choices, in the ~months between the RFCs, are endpoints >>> doing a QUIC version + ALPN of >>> 1) 0x00000001/h3 or >>> 2) 0x00000001/h3-xx >>> >>> Can we come to an agreement on this point? >>> >>> Martin >>> >>
