Re: Identifying our deliverables

Roberto Peon <> Tue, 30 October 2018 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2523E12D4EA for <>; Tue, 30 Oct 2018 09:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=nSsPfFx0; dkim=pass (1024-bit key) header.b=eeFoKJak
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eqOR3EtzGfnf for <>; Tue, 30 Oct 2018 09:36:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B0EC130D7A for <>; Tue, 30 Oct 2018 09:36:33 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w9UGZhgj016003; Tue, 30 Oct 2018 09:36:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=0DiqcSZs55e8xcnyYYeCuuOo3lyA6f8BFumIVBgMwXA=; b=nSsPfFx0GcZLKmvu4nGIJ2N3agfsCQeUeib9A9E5KQGcdRonUZbbxt+oM+NYgry8Ehu2 LHyTDj1dfi9ybjzGcWWaoABObY8bIygpvyXCZ4fAEc4fmHtueqGmKlQFWYkH5n5w0lYL qlmNp9YXTehjGNz4FAqttucba070mv1v9H4=
Received: from ([]) by with ESMTP id 2nereeghwj-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 09:36:06 -0700
Received: from (2620:10d:c081:35::125) by (2620:10d:c081:35::125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 30 Oct 2018 09:34:06 -0700
Received: from (2620:10d:c081:35::11) by (2620:10d:c081:35::125) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.1.1531.3 via Frontend Transport; Tue, 30 Oct 2018 09:34:06 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 30 Oct 2018 09:34:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0DiqcSZs55e8xcnyYYeCuuOo3lyA6f8BFumIVBgMwXA=; b=eeFoKJakRrGIm+hepWhuByVzD+l87PkjYwOj8fnqLYwBAOi5kAlq0FKroww44D8m7ygf+Rwp2jVsiVWwmMMY4YWyPvEP6Z6sfpgjF28u9djuBCMNk4XOlbc4VWNZtx4S8EWBQfxYJfTBbG+YKngUWqVwU6jI3homTW54vQD1fEg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.26; Tue, 30 Oct 2018 16:34:05 +0000
Received: from ([fe80::11c0:d70e:972b:7d51]) by ([fe80::11c0:d70e:972b:7d51%3]) with mapi id 15.20.1273.027; Tue, 30 Oct 2018 16:34:05 +0000
From: Roberto Peon <>
To: Mikkel Fahnøe Jørgensen <>, Ian Swett <>, Lucas Pardue <>
CC: Mark Nottingham <>, IETF QUIC WG <>, Willy Tarreau <>
Subject: Re: Identifying our deliverables
Thread-Topic: Identifying our deliverables
Date: Tue, 30 Oct 2018 16:34:04 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: [2620:10d:c090:200::6:e9de]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR15MB2278; 20:HMpqBhdo742xJtEVdRs2rO0BPRru/CWlHf/phUBRU0eY/kWbshv3WeAPv4zQ3IbDE1PaiVBH+qzASC1F1wwq0lNBEaq2suFyRPJirxqdHodKu2Stz73zlDk3sdnvdstMGE2nxZbg6wBwON/gTwo0wTxzPj4oEZmUtRiKIHBr82U=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 298fe936-048e-4427-7981-08d63e8581e5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2278;
x-ms-traffictypediagnostic: BYAPR15MB2278:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(85827821059158)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(11241501184)(944501410)(4982022)(52105095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR15MB2278; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2278;
x-forefront-prvs: 08417837C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(396003)(366004)(376002)(189003)(199004)(3480700004)(53546011)(54906003)(58126008)(102836004)(8936002)(2900100001)(82746002)(14454004)(110136005)(6436002)(4326008)(2906002)(76176011)(25786009)(36756003)(33656002)(6506007)(53936002)(54896002)(99286004)(39060400002)(6116002)(6486002)(6306002)(6512007)(68736007)(83716004)(236005)(6246003)(71200400001)(71190400001)(316002)(97736004)(478600001)(81156014)(106356001)(66574009)(186003)(105586002)(8676002)(86362001)(5250100002)(476003)(14444005)(486006)(93886005)(7736002)(5660300001)(256004)(446003)(46003)(7116003)(11346002)(81166006)(229853002)(2616005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2278;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: S5x7sHc/h4OPER+C/2uCkxaRs7gPDPsajmK/0UsL3ONieVxkyge0qiUzC0QaGnPzxfGRrZc+SMMlemN4lkdG9je76v7BV99ZW3AQ24fS2U84vvKW9XilbYMROsAeiwMYrw2PfG0qFnBFRF+oDl5Tfp4UQjnkPuYDgGzio1OmX1MxwNIgp8iKtlUvVHY4gow5AxzxRMx03t9B/w5pUI5UKKZz7xQPEE1t0dOTAENpVJYpKRnlr6E/Jc7hkAqLXK7aWSik7GATIqKhCdWWagu73uw4udM8MvpF89K3pN2IKxZyHQOrOUr8FtF5SNlhPK2vVJCAlOJei03tt4tLvGSDytKQS5eAMjbH6d6EgWGdvFU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B135797277314B9EAA80A36D4F31306Cfbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 298fe936-048e-4427-7981-08d63e8581e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 16:34:04.9126 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2278
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-30_10:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
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: Tue, 30 Oct 2018 16:36:35 -0000

Since there isn’t any particular need to identify QUIC the transport (without mechanisms to explicitly multiplex multiple protocols), I think calling HTTP-on-QUIC H3 is the right move.
QUIC without anything else is as meaningless as TCP without anything else from a what-the-server-will-speak perspective.

From: QUIC <> on behalf of Mikkel Fahnøe Jørgensen <>
Date: Tuesday, October 30, 2018 at 7:29 AM
To: Ian Swett <>, Lucas Pardue <>
Cc: Mark Nottingham <>, IETF QUIC WG <>, Willy Tarreau <>
Subject: Re: Identifying our deliverables

Recent edits in transport also use terms such as “This frame is only used in the QUIC layer” which is slightly confusing when QUIC/HTTP is also a (higher) level QUIC layer while “QUIC layer” refers to the transport layer only, implicitly.


On 30 October 2018 at 15.26.19, Lucas Pardue (<>) wrote:
I echo Ian's thoughts, "HTTP over QUIC" doesn't work well as a term in practice.

I support this change, using an incremental number is logical, and is compatible with the ecosystem that expects an HTTP version number.

On Tue, 30 Oct 2018, 13:56 Ian Swett, <<>> wrote:
From a completely practical perspective, I support this because I can't tell you how many times I've had to explain the difference between the HTTP over QUIC mapping and QUIC the transport.

And moving the HTTP over QUIC and QPACK documents to the HTTP working group seems like the right thing to do.

On Tue, Oct 30, 2018 at 1:21 AM Willy Tarreau <<>> wrote:
On Sun, Oct 28, 2018 at 11:30:55AM +1100, Mark Nottingham wrote:
> To address this, I'd like to suggest that -- after coordination with the HTTP
> WG -- we rename our the HTTP document to "HTTP/3", and using the final ALPN
> token "h3". Doing so clearly identifies it as another binding of HTTP
> semantics to the wire protocol -- just as HTTP/2 did -- so people understand
> its separation from QUIC.

FWIW I always thought that HTTP/3 should be its final naming -- just like SPDY
became HTTP/2 -- for various reasons, one of them being encouraging adoption
by the protocol being presented as the natural upgrade to the previous ones
and not a competitor that's been there for some time and suddenly comes as
an RFC.

H1 with 723x, then H2 with 754x have shown that it's not a problem to cover
multiple areas with a common name and that the protocol itself is in fact a
family of protocols and mechanisms. So QPACK will naturally fall under H3
just like HPACK naturally belongs to H2.

Just my two cents,