> On Apr 28, 2021, at 7:27 AM, Martin Duke <[email protected]> wrote: > > I misremembered the previous discussion; it was on the list, not on Slack, so > it's archived. It starts here: > > https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/ > <https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/> > > I believe the conclusion was that we would use 0x00000001/h3 as soon as QUIC > RFCs shipped, before H3 RFCs shipped.
That certainly seems to be the most reasonable path, to me. Best, Tommy > > On Wed, Apr 28, 2021 at 7:22 AM David Schinazi <[email protected] > <mailto:[email protected]>> wrote: > 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] > <mailto:[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] > <mailto:[email protected]>> wrote: > Damn it, wrong http > > On Tue, Apr 27, 2021 at 3:40 PM Martin Duke <[email protected] > <mailto:[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
