W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: H3 ALPN?

From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 3 May 2021 11:32:36 -0700
Message-ID: <CAPDSy+7yn04JGM5Q6yEgjBYN2-f2WbkDz7yT4j7hro=3QkU8Rg@mail.gmail.com>
To: WG Chairs <quic-chairs@ietf.org>
Cc: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi QUIC chairs,

Could you please provide some guidance here? Ideally in the form of
official consensus?

I'm already seeing folks deploying production h3 servers ahead of the RFC
shipping so we could also just give up and open the flood gates.

David

On Thu, Apr 29, 2021 at 1:50 AM Dragana Damjanovic <
dragana.damjano@gmail.com> wrote:

>
>
> On Wed, Apr 28, 2021 at 4:28 PM Martin Duke <martin.h.duke@gmail.com>
> 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/
>>
>> I believe the conclusion was that we would use 0x00000001/h3 as soon as
>> QUIC RFCs shipped, before H3 RFCs shipped.
>>
>>
> That works for me as well.
> The neqo(our quic/http3 library)  already implements this. This is
> currently not exposed in Firefox.
>
> Dragana
>
>
>> On Wed, Apr 28, 2021 at 7:22 AM David Schinazi <dschinazi.ietf@gmail.com>
>> 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 <martin.h.duke@gmail.com>
>>> 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 <martin.h.duke@gmail.com>
>>>> wrote:
>>>>
>>>>> Damn it, wrong http
>>>>>
>>>>> On Tue, Apr 27, 2021 at 3:40 PM Martin Duke <martin.h.duke@gmail.com>
>>>>> 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
>>>>>>
>>>>>
Received on Monday, 3 May 2021 18:33:01 UTC

This archive was generated by hypermail 2.4.0 : Monday, 3 May 2021 18:33:03 UTC