Consensus on Deploying QUIC v1 with HTTP/3
Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 05 May 2021 23:18 UTC
Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0401E3A25C2; Wed, 5 May 2021 16:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL2wl5bywigF; Wed, 5 May 2021 16:18:48 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7893A25C6; Wed, 5 May 2021 16:18:48 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id n2so5412620ejy.7; Wed, 05 May 2021 16:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qemby9T72Bj5XpEvz10rgldBCAhapd+iDCjIUc2wRjs=; b=u9hfSEXCVIdLgRZ4UmxNdylL+RuQxX1jywY5k5g67ocK8b9MF94UdA/ypePTPsawMs JN/7u+dWmway6MQPkIy4UDDdpcVtMBZncSTXAaojbaBk8oJjEyEmE9w9TEw48JA3mpCm L2pyx4+WZDLoprLWP0gw3OatIBI9zOoA9JawJWNa0xRE0IMyNdfTXDpyX+DfHkTzXGE3 qeVTapuDmII3jp5zn4gaSRB3Yq1MwZzVBqhOcFBZje3L9z+zIIAcClu8zW8OONZw11aQ w5k9QU4ogF+jFE1X6QTZdRaMjOcarc9y+dRzkP28hW/NZnvQSy+pbX4QPpVr95+HtW/f S7pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qemby9T72Bj5XpEvz10rgldBCAhapd+iDCjIUc2wRjs=; b=Ufs0aiKiRDBxfoT1EP4dJqkZrgvFd0pDu+xXD/Xp5uDUxmXUhypb+bGI1Hjca6/VgH gFYmvmQqCrj8FJfQXg6vOMs8yppX43FcJ3NHbOBRvTbAo34bcTGOA+krV5WIPLxUwb1U uKFs582S2/v4Mb0Cv5qmaeWeWlBMhydtE8LgbMzsiH2RfI5c1X2ELGq9UbUkt0Qy4iFq LmCjip5DrLfcOvOApGU/tVdrh76T62dMbcrFbTjCZ1jtf/KkhwZ3+5dzfsWNXFDJIh0L muBcwRThSF89jaGROtErIiYw0fWPpy/N3i3ckK7MYx7NYwwHNd5324kAcl0BPJAwcW6W v4Dg==
X-Gm-Message-State: AOAM533kdOCnRlXKqrNBMrxl5SyFuqUIBDkXwRpUClZjCFhuiWnkPu2N 8D8/aP7FmcjQWA0TqJ1MlQcsg1jDcc99XAwLi9Bp2e6I
X-Google-Smtp-Source: ABdhPJxiQdN04ILmjSRy7eVDuu4h0vNSEsswU3hARwDT0kdE4lj9n6m4IYN/oh+Zud6aFHqw/IDow+eLSxodLjUcg4Q=
X-Received: by 2002:a17:907:3f06:: with SMTP id hq6mr1232385ejc.46.1620256724939; Wed, 05 May 2021 16:18:44 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 06 May 2021 00:18:34 +0100
Message-ID: <CALGR9obE-Dbm5Rwmr=h_34vaps1pcv36Jg0MTS_o0mZHEF1FvA@mail.gmail.com>
Subject: Consensus on Deploying QUIC v1 with HTTP/3
To: QUIC WG <quic@ietf.org>
Cc: WG Chairs <quic-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088f6af05c19d6a7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i7CdtRA-iskuTftpEpMXMrB0FSY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2021 23:18:53 -0000
Dear QUIC WG, (HTTP WG is bcc'd) As you may be aware, the QUIC v1 specifications entered AUTH48 state recently and they are making good progress (thanks editors!). The HTTP/3 and QPACK documents have a dependency on the "HTTP core" documents being worked on in the HTTP WG, so we expect them to take a little longer. The drafts submitted to the RFC editor define QUIC version "0x00000001" [1] and HTTP/3 ALPN identifier "h3". They include the clear instruction "DO NOT DEPLOY THIS VERSION OF {QUIC, HTTP/3} UNTIL IT IS IN AN RFC". HTTP/3 is explicitly tied to a version - the "h3" identifier is expected to be used with QUIC "0x00000001". As several folks have observed on the list [3][4] or in Slack, once the QUIC RFCs are published, 0x00000001 can be used in deployment. But the longer lead time for HTTP/3 RFC creates some grey area on what ALPN to use. Waiting for the HTTP/3 RFC delays deployment of QUIC version 1 at the earliest convenience, which is unfortunate given that the design has IETF consensus. The Chairs have tracked various discussions and we believe there is significant deployer interest in deploying "h3" as soon as the QUIC RFCs are published and before the HTTP/3 RFC is published. Furthermore, on balance of the information at hand, we observe a minimal perceived risk with deploying "h3" before the HTTP/3 RFC. This email commences a formal consensus call for permitting the deployment of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *once the QUIC RFCs are published*. The call will end on May 13. Please reply to this thread on the QUIC WG list with any additional comments, thoughts or objections before then. Cheers, Lars, Lucas & Matt QUIC WG Chairs [1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34 [2] https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34 [3] https://mailarchive.ietf.org/arch/msg/quic/AQM3or1TNnInYhWe8UEx5B6nrgw/ [4] https://mailarchive.ietf.org/arch/msg/quic/M_uWXd2yvucnZwFs66g15ZbpJaM/
- Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue
- Re: Consensus on Deploying QUIC v1 with HTTP/3 David Schinazi
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Julian Reschke
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Matt Joras
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Matt Joras
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Spencer Dawkins at IETF
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Julian Reschke
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Ian Swett
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Spencer Dawkins at IETF
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue
- Re: Consensus on Deploying QUIC v1 with HTTP/3 David Schinazi
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue
- Re: Consensus on Deploying QUIC v1 with HTTP/3 David Schinazi
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Spencer Dawkins at IETF
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue
- Re: Consensus on Deploying QUIC v1 with HTTP/3 Lucas Pardue