Identifying our deliverables

Mark Nottingham <> Sun, 28 October 2018 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38367130E05 for <>; Sat, 27 Oct 2018 17:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Womn+NUE; dkim=pass (2048-bit key) header.b=CtrUB8c/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yn0qI51qJJZX for <>; Sat, 27 Oct 2018 17:31:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBEC2130E02 for <>; Sat, 27 Oct 2018 17:31:01 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 5397D21D03 for <>; Sat, 27 Oct 2018 20:30:59 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Sat, 27 Oct 2018 20:30:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm1; bh=F5ZsHIOU4bmy4skM4L4c/gIb0qwgM0WBz PYF9RDOtu4=; b=Womn+NUE6OonsEbhxshMEUE1bZI+NSdrsJ6J52yMBvmDwrvUD ReCVOsqBLZnjxU1Rj00v3ko3gX8ODJHhj+SAMsExTRh+CjMpfxVSMVdLKwE4pgc1 bEuaFUQWJn6qYYwswgDFg27BGvxS5Y3SzUMBSQaw94NIQ9+uqZar8lNQMdAldDRW o1gQcd39Ijv+c4WzjQOhzHAvGrTuFmuAqTc0vRbhnqpzwAPal66GXk99dhU+cg3x yxlm2bSSkDrZifK8Fs6Z/AO9xwq3Ne+6b282GnkTd9OFVfYkEUFf25rr5gT9/prk oKcdpIovrHyfOxpCQngSc+9cwYukZBXV91+XQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=F5ZsHI OU4bmy4skM4L4c/gIb0qwgM0WBzPYF9RDOtu4=; b=CtrUB8c/OjIPoBB11ca5vR HHv2MwwQHdPf1QrViObMhZddNhzymTAFokjGtw6OtqJLVtlYtANoQ4jHP3Ye8Nuf Nvai+PehXNv8URyDJgq02rsAqctTcdGNW/FeyJkOlEAwXsvKOnhTRTUdOq5HUe2t o6Rx7/Gidx013HUk2bxeK3ws+TpNTtuJoa8pmUu0qnkS1t7B4rxUJjC5npom9ST/ 0iunlXofjOmVa7sOkTdQArB445FotgYrYx2yAJuNXAsZVTukLlfmXguEISNTop5Y PIKG6P3dtiSMb9mrXS5eU5zFNPCrMrrm3sZQvj8OY4oMrBCgwyz0pt9CqM/2OXdw ==
X-ME-Sender: <xms:QgPVW1FhsKYpcGfnc84WxBHjEwBqxf4Exvgei8Cu4oLyVmWMDbF6Vw>
X-ME-Proxy: <xmx:QgPVWwVpvY_kFr7AoK98IfaznDWw8MkKa_SM80ZAKQmrLIcg-hlQNA> <xmx:QgPVW-o_hh8d5MPN9spiM5wojL2rLJPsYEAR73GrBvY8BcUTdFrfTw> <xmx:QgPVW5W-9-5ta7jEJ-6McZWHL2Ae6FhRNSL397UON1rGQ_wfA5Cvhw> <xmx:QgPVW3Hm_7U_jKfX1ovKhyFm-dHqj4V0DBAP9pWVlhfRkJ94uWC2ig> <xmx:QgPVW4CX8HJP7YtiYdHnHKLwukkQ2Dt49mRlDqXcYFoocCJpoWBD9Q> <xmx:QwPVW8meY2wA225CUrkFUwZU6n8SF2j9MN_1A1FMVChfgdFwfnRAQQ>
Received: from (unknown []) by (Postfix) with ESMTPA id 10485E4A41 for <>; Sat, 27 Oct 2018 20:30:57 -0400 (EDT)
From: Mark Nottingham <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Identifying our deliverables
Message-Id: <>
Date: Sun, 28 Oct 2018 11:30:55 +1100
X-Mailer: Apple Mail (2.3445.100.39)
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: Sun, 28 Oct 2018 00:31:05 -0000

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.


Mark Nottingham