Re: H3 ALPN?

David Schinazi <> Wed, 28 April 2021 14:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20EE43A0C88 for <>; Wed, 28 Apr 2021 07:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V7Z_ovd7SRKv for <>; Wed, 28 Apr 2021 07:22:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9172C3A0825 for <>; Wed, 28 Apr 2021 07:22:06 -0700 (PDT)
Received: by with SMTP id s22so23715180pgk.6; Wed, 28 Apr 2021 07:22:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bjVuFBsRjqrAO4MaJxJC451aOENJmavAZ+DYLQQ1pZw=; b=PmYju/jepSR0J/6Qv6BFMyfh+KKornvBRupA3EciRoZQk6xOBpaXDlZ7pjnKAotgkZ nUUF6ozYNpn543q9ISmmTVaPh0BuA4KB+8/F/ypDUtwtBF2M9Z+TeHC4QIbYU3bTqYch KIHWG0T4WaNye/DrOHtrjQM5efqpv7ArDKkg/0c/4aSNjwbbgFn5PMcBjhkXzs9A+pUz 4oN8VR+iUis+OOEMSSav2fcFYVBTnqKZWzrek4PlLvr+QOdv89fLAYJbe4lKJj+hQDcT x5xzA51vF3STBX+3enUWncotVXEbXN4Gtr2mhLlZskp5ib36f/coVAmOAZRdYWaXa4mi 618g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bjVuFBsRjqrAO4MaJxJC451aOENJmavAZ+DYLQQ1pZw=; b=XQaAMykfCdk9wxJKxUcy8UbZ7t74NcJdBUjtDychP4D0GoeA5wzk8j0DCwtEuoyzJW wifrtCMSnltGrjpcK4NbZNUX7TrBiRX0aDu9Si+tmfBNS25bjnxxdCEHycCLAXJJ6slA 2p0W08LVgVsMg4/+gOUmQhYKMSBBiaMWHoQGo3uwJ6ok+0bxiIJ+ihRRwcryxADkRQLi t+mW8BRGTF1bvoq+1qI6J53msk4Mi2j7fCGIxC6IjQP/2Hc0ViBOrigDklLVwuC4hc+C T7xXrqpNi+b6NKMOrMPteEpcCW0krPzpP59R14Nds0GKdbHBvbHyKgK3LeRrCb4KtXD2 uFvw==
X-Gm-Message-State: AOAM532quCVii8K+LXJDJm8eb6HEB0AXH+bOrKQkwDl1A/5tjFuoDZoF DvcIqMhtHMJwr86jWXlZqNfOVEQRtht3tURVwU0=
X-Google-Smtp-Source: ABdhPJyUNF29CQ7iyR67LVNYMYG9Wug43kjoIThG4XSfTn4dq4XMmcUOL2A29nps+DQfiur9/Dq9XufgxJtrUcMjLxo=
X-Received: by 2002:a65:61a1:: with SMTP id i1mr27044633pgv.411.1619619724798; Wed, 28 Apr 2021 07:22:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Wed, 28 Apr 2021 07:21:52 -0700
Message-ID: <>
Subject: Re: H3 ALPN?
To: Martin Duke <>
Content-Type: multipart/alternative; boundary="0000000000005e2d6805c1091a89"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Apr 2021 14:22:12 -0000

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?


On Tue, Apr 27, 2021 at 4:04 PM Martin Duke <> 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 <>
> wrote:
>> Damn it, wrong http
>> On Tue, Apr 27, 2021 at 3:40 PM Martin Duke <>
>> 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