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

Martin Duke <> Wed, 13 November 2019 00:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92F651200B5 for <>; Tue, 12 Nov 2019 16:43:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yz7BOrU2Dh4Y for <>; Tue, 12 Nov 2019 16:43:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDB851200E3 for <>; Tue, 12 Nov 2019 16:43:02 -0800 (PST)
Received: by with SMTP id z10so282404wrs.12 for <>; Tue, 12 Nov 2019 16:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LHZ9u7b1jUeDpPvZ0NZ0zlAMcORZB8H+Q1OMiwWs9p4=; b=GWEm7UDTrR3lxIh9pd8Aalh8Bm2OzIZIjLvqAVBxrEQ/Tav2gNDWdkTJ5LCQQTd3Ip j3sRnXOBf+58emayhrDAvj51v04f0rc1vybJook0ZkfBQm3T2LSdFB31pUKScphXM0ai ETnZa800fERcSRBy1zHbFKhfr13EAzBcNX6b3Xl3bbDqHNBeT/ae2xJxOD6LYO8pduXM Pb+12F/IsuQoh15M+tohlyf4rfw7IIMDCWK/I2vrXC2HefCW9bYalTc6iawZ7BYvS+Sl 9C4Kq7yTwTQ53gbnnWn2zgN+78XmScnMRI951OzkuJev7TMGlAp0fgEkW+LVwnzmgIeh vl3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LHZ9u7b1jUeDpPvZ0NZ0zlAMcORZB8H+Q1OMiwWs9p4=; b=VoKt1Mi5bRTN8murhoZ8hr97FEXYBEnTBKqXvCW83x5a5k7qLuGKSINejuTyzDu+Vl /MfQSVYKP3QGs+tCwhlpx1WZGrcR6LmoMU4Zx+AvPRDBKV4xiYhRdTWO2wWGA+h25whk eGW0z1/ivlBHrJ9HuPj/n3uHNKmCsXNC1Km3OVqFZhdNyV7M7nHcOEEb30nzHjffPBHJ lvkUsyBE/fy3XEAfpiBXnTN/32Rix5EhWLU1QRIPz8r5BK5PWcXuzq5iQZvmslgkJ6j8 7agDaaiCUIKYGBPW1A7hGTzy7sKOTmr1FiqOPHrNUmw8Hyg4PbQKHNKS2oNAOdr16nBf 3EUA==
X-Gm-Message-State: APjAAAXZGAyQUECGfJ2D4W5WEULTrAvFQQA+9mElzaN4ndi1nEh5oo8c EW1wajGyAA3JEh1FJ969ywP0wBxIh4sHzvDcbjs=
X-Google-Smtp-Source: APXvYqxcr1r4eC7/GMEB6eqtUhpZBklxfQ0aZDOy7AabKSCvM7444nFDjcAxRHx8NCF8KW26jml09ABaK4okljLcBEQ=
X-Received: by 2002:a5d:55c7:: with SMTP id i7mr149084wrw.64.1573605781229; Tue, 12 Nov 2019 16:43:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Tue, 12 Nov 2019 16:42:49 -0800
Message-ID: <>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process
To: Mike Bishop <>
Cc: Mark Nottingham <>, Roy Fielding <>, Lars Eggert <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000009b559505972fa5e9"
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: Wed, 13 Nov 2019 00:43:09 -0000

Put another way, I think Gorry's planned review of draft-24 is probably

On Tue, Nov 12, 2019 at 4:42 PM Martin Duke <> wrote:

> IMO the recovery draft is in the midst of a major revision dealing with
> the aftereffects of discarding the crypto timeout. Ian still has a bunch of
> stuff in flight for this. When all of those PRs land I would like to have a
> short period to review the working draft and see if it looks good.
> On Mon, Nov 11, 2019 at 7:40 AM Mike Bishop <> wrote:
>> I'll also note that it's relatively easy from a spec perspective to allow
>> trailers to arrive before the end of the body, or to allow multiple sets of
>> trailers to arrive.  I suspect most clients won't process trailers until
>> they have the body anyway, but the real question is what clients do with
>> multiple trailer sets.  I'm not certain whether that's in our scope or not,
>> but that's a separate conversation.  Feel free to open an issue for that
>> specific discussion.
>> -----Original Message-----
>> From: QUIC <> On Behalf Of Mark Nottingham
>> Sent: Sunday, November 10, 2019 8:01 PM
>> To: Roy Fielding <>
>> Cc: Lars Eggert <>rg>; IETF QUIC WG <>
>> Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the
>> Late-Stage Process
>> 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.
>> Noted.
>> > 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.
>> Cheers,
>> --
>> Mark Nottingham