Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

Mark Nottingham <> Mon, 11 November 2019 01:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CC1E12001A for <>; Sun, 10 Nov 2019 17:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Status: No, score=-2.69 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=F2i75tl/; dkim=pass (2048-bit key) header.b=niDuEtDm
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ux0Iao-8Cbgs for <>; Sun, 10 Nov 2019 17:01:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DE5C1200E5 for <>; Sun, 10 Nov 2019 17:01:03 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id C09D7481; Sun, 10 Nov 2019 20:01:02 -0500 (EST)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Sun, 10 Nov 2019 20:01:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=f Bhmb0zeBNR5VAOnhnLk0dfOcjuvaj3nxG/1ulw1e04=; b=F2i75tl/f3jukGszF 3qbjkGClrFlnG+fLQ6gTbfjuwWoh2TyqKZM55vZ2N+TSo7NEwV58iyPpHCpH+BDl Gt8oU/BAKva9l1H7+Qj47t+PJGY7jCqNYvWjMCE6xuwCTyJ0bp2ERVNIxH5dIEp3 y+fwDwTP7jCLJQ3eoHXffwP+KdeR5o2oJkh37T8Np6YWGNEJm7k8UgyzVzahgb9N 81NUF2tfvP5KRuXq+1NPAaaFye1GJEjEtCNDwJSHEeR8RobsR2aNEKxT3Y0XxFkU f+7i4l2yg0wwzAiCEfxXIGDRAxVU9x+LALqM2aBg1VbAlhvUFLfxRPNRneFLjFGB B9L5Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=fBhmb0zeBNR5VAOnhnLk0dfOcjuvaj3nxG/1ulw1e 04=; b=niDuEtDmlDqpi5Ug3qEyutP9WfhRNUSfnnjucIsaEeIPhRfa9zWkr9Efu GqkYRU19wmXVd+4/NDlDNIHZKQzixeWna5RvVhD//aeeNJkNNefILP1JkF8RXMS7 5EE5koCaNohVD8ly0AFyGPjQzBuHng+FqcDzXTK740OdDUfYLsYi39a/lX1UMWsZ 2a97OYzfC+Ifb3GuxAJNrNA+yIk8DxsC4sD9g5OflQIQvSbEhOrT3yYFM+DxQQl6 wL+UmMWcyu6Bnh/BJGdsw7LJxSRFgc6sZvq2ekeSZszl7Dwylll1BEHrzca8N4Dm cu7XxFBjTsXor0zlA0W6VdjKqXBYA==
X-ME-Sender: <xms:tbLIXcE0u_5waat1kmRJvXI9F-0JQr2x8v0LllGmKQHIBG34fnSFbQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddviedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh ephhhtthhpfegrnhguqhhprggtkhgurhgrfhhtshhtohhthhgrthhprhhotggvshhsrghs figvlhhlrdgrshdpudhhrgguihhtrghlsggvihhtlhhimhhithgvughtohgthhhunhhkvg guvgigthgvnhhsihhonhhsrdhithdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedr udehkedrvdehudenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnh gvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:tbLIXZYJiArW4ZZYrDgasOHNOdWNeVqH2Ik5MEjhVJNIdFWdvhZ7eA> <xmx:tbLIXQ1R472aqApexXf_Bll6956OjBnRkPFEOY7dGpkxKExoD3uF-w> <xmx:tbLIXdbG-b7q63-LiYLyBhUVXi107_4qVkPYm2hXYBewirtLxPry8g> <xmx:zrLIXQE2d2VxKgCih46tD4KGqIv_WTzTjY-rotM0r6KSkScbfBqQgA>
Received: from (unknown []) by (Postfix) with ESMTPA id 028043060064; Sun, 10 Nov 2019 20:00:35 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
From: Mark Nottingham <>
In-Reply-To: <>
Date: Mon, 11 Nov 2019 12:00:30 +1100
Cc: IETF QUIC WG <>, Lars Eggert <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Roy Fielding <>
X-Mailer: Apple Mail (2.3601.0.10)
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: Mon, 11 Nov 2019 01:01:09 -0000

Hi Roy,

Responding to the parts relevant to this CfC.

> On 7 Nov 2019, at 5:39 am, Roy T. Fielding <>; wrote:
>> On Nov 5, 2019, at 5:01 PM, Mark Nottingham <>; wrote:
>> Previously, we've moved to the 'late-stage process' documented at [1] for the Transport and TLS drafts. The chairs and editors now feel that it's time to move the Recovery, HTTP/3, and QPACK drafts to that process as well.
>> As before, this is because we're getting to a stage we feel the documents would benefit from slower and slightly more formal process, so that the rate of change is not so high, changes that do occur are well-vetted, and the documents get closer to reflecting consensus in the working group.
> I don't think that process has worked well for QUIC.


> There are specific issues that are contentious enough to timebox
> and conclude, in a formal (and faster) fashion than was done before.
> That makes sense when needed for a specific issue. I don't know
> of any such issues for those three drafts. IOW, I don't know of any
> issues for which it makes sense for the Chairs to pre-empt the
> specification authors in deciding what can or cannot result in
> changes to the drafts just because of the timing of when the
> issue was raised.

You misunderstand the process; the Chairs aren't pre-empting anything, the group is attempting to agree to a path to completing this work.

> The late-stage process seems to focus all of our energy into
> in/out-of-scope arguments rather than actual text in the specifications.

I don't see any evidence for that claim; what makes you believe that?

> The last interim spent easily twice as much time discussing process
> and process planning than it did HTTP/3. Prior interims were worse.

We spent a day talking about transport and TLS, part of a morning talking about planning the future of our work (if you want to call that "process and process planning") and the bulk of the (longer) afternoon session talking about H3. This isn't surprising, since our goal for the meeting was to get the Transport and TLS documents close to finished.

> I don't even recall the last time contents of the HTTP/3 spec being
> discussed on list, outside of very specific issues related to transport.
> I would like to see HTTP/3 written with HTTP in mind, not as a set
> of diffs against h2.

That is by charter; we're largely limited to mapping H2 onto QUIC. 

> This is not a small undertaking, but it isn't a massive one either.
> Basically, import the bits of h2 that are necessary to explain HTTP/3's
> operation and intent, and then start referencing the http-core drafts
> instead of 723x. Yes, I know that is risky, but it is the right thing to do.
> And it needs to be done before http-core is finished, since that effort
> exists largely to place the right content (in the right places) for
> HTTP/3 to reference.

AIUI that is still our intent, and shouldn't be impeded by the late-stage process, since that work should be editorial.

> I have no idea what the status is with QPACK, but we should
> learn a lesson from the last time and make sure the fixed
> compression dictionary (if any) is based on traffic at more than
> one proxy or origin server. Or at least have each of the major
> deployments generate their local "best" encoding and do some
> cross-testing of the N choices (plus one or two based on a
> hand-crafted expert merge).
> I would like for HTTP/3 to have a mechanism for communicating
> metadata (like trailers) in mid-stream, both for requests (e.g., priority)
> and responses (e.g., chained sigs). That has been a design goal for HTTP
> since 1995 or so. HTTP/1.1 had it, albeit limited to chunked extensions.
> It has been proposed multiple times and keeps getting postponed
> because of "concern about scope". This is not a semantics issue
> (they are just optional trailers that arrive early) -- it is a multiplex
> framing issue (a new frame type and expectation to process).

Where are the multiple proposals you refer to? We've been working on h3 now for more than three years. If you submit them now, they'll be design issues.

I'd say that the Late-Stage process (or at least the proposal of adopting it) is working exactly as intended here -- making people realise that if they still have issues / changes that they want discussed, they need to bring them to our attention now, not as we go to WGLC.


Mark Nottingham