Re: Identifying our deliverables

"Roy T. Fielding" <> Tue, 30 October 2018 19:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDDF2130DCF for <>; Tue, 30 Oct 2018 12:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wlFu-XWpFxmo for <>; Tue, 30 Oct 2018 12:19:01 -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 885EA130DC0 for <>; Tue, 30 Oct 2018 12:19:01 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 983D05E3065; Tue, 30 Oct 2018 19:19:00 +0000 (UTC)
Received: from (unknown []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 4CA9F5E0D22; Tue, 30 Oct 2018 19:19:00 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.16.2); Tue, 30 Oct 2018 19:19:00 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Society-Invention: 1134f49d4f030edf_1540927140452_2864324956
X-MC-Loop-Signature: 1540927140452:1571239916
X-MC-Ingress-Time: 1540927140452
Received: from (localhost []) by (Postfix) with ESMTP id 01EDF7F1F2; Tue, 30 Oct 2018 12:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=wzfI4YIkH2upIcbCepU286UWRsk=; b=raw33y1QeFRdGVhswW0i1kwc9S/F 99PGRiicnhO/tcKbfoJY+cC0hJD/wkXFx8+3G2AFjkx+MjgT7lObSJqka3/mwDx3 E+Q/86CkmzZDCxCXs0owIcGK8sYC2vpCi39YN7S6XcJUupFIYf9dSUPScJyGJ8vV 5VmGamC2wikrGwk=
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id D9D407F962; Tue, 30 Oct 2018 12:18:58 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Identifying our deliverables
X-DH-BACKEND: pdx1-sub0-mail-a14
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Tue, 30 Oct 2018 12:18:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.3445.9.1)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedtgdduvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepfdftohihucfvrdcuhfhivghlughinhhgfdcuoehfihgvlhguihhnghesghgsihhvrdgtohhmqeenucffohhmrghinhephhhtthhpqdhovhgvrhdqqhhuihgtsghinhguihhnghhqphgrtghkvghttgdrihhtpdhhthhtphdvughiugdqqdhsohhpvghophhlvghunhguvghrshhtrghnughithhsshgvphgrrhgrthhiohhnfhhrohhmqhhuihgtrdgrshenucfkphepieekrddvvdekrdeigedrudefkeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdehngdpihhnvghtpeeikedrvddvkedrieegrddufeekpdhrvghtuhhrnhdqphgrthhhpedftfhohicuvfdrucfhihgvlhguihhnghdfuceofhhivghlughinhhgsehgsghivhdrtghomheqpdhmrghilhhfrhhomhepfhhivghlughinhhgsehgsghivhdrtghomhdpnhhrtghpthhtohepqhhuihgtsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt
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 19:19:04 -0000

> On Oct 27, 2018, at 5:30 PM, Mark Nottingham <> wrote:
> You might recall that we've previously talked about renaming our deliverables to clarify their relationship to the input documents (sometimes referred to as "gQUIC vs iQUIC").
> After a fair amount of discussion with various folks, it seems like there's confidence that calling our core deliverable just "QUIC" will work, since Google's variant will fade out of use if we succeed, and there aren't any good alternatives; our best candidate was "QUIC/2", but it was pointed out that this additional level of versioning (since we already have a wire version) will cause yet more confusion.
> However, in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things.
> 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.
> As part of that discussion, I'd suggest that we formalise that its maintenance (as well as that of QPACK) pass off to the HTTP WG once we've published it.
> I've talked about this with a number of folks. The only concerns I've heard so far are:
> a) That QUIC isn't yet proven. That's true, but the name won't be formalised or used on the wire until the RFC is published, so we have a good amount of time to back away. Even then, if it fails in the market, we can always skip to HTTP/4 one day, if we need to. 
> b) That discussing naming is a distraction from our technical work. I agree with the concern overall, but we have a responsibility to communicate clearly with external developers and users, so I'd like to have a *limited* discussion about this. Please, don't bike shed.
> *Chair hat* 
> We plan on reserving a very small period of time to discuss this in Bangkok; barring serious objections (of which "what about this name that I like instead?" is not one), we'll bring it up with the HTTP WG in Bangkok as well.

FWIW, I don't have a problem with calling a product of the HTTP WG some form of h3,
with the implication that we are working on the next version of HTTP and that it will
work on top of QUIC.  I have a bit of a problem with assuming that h3 product will be
the current HTTP-over-QUIC binding, QPACK, etc.  It's a reasonable option to work upon.