Re: HTTP Delays

Martin Duke <> Wed, 13 January 2021 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2667F3A0EF2 for <>; Wed, 13 Jan 2021 11:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 bqb9lGcawKTa for <>; Wed, 13 Jan 2021 11:00:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55A6C3A0EBC for <>; Wed, 13 Jan 2021 11:00:06 -0800 (PST)
Received: by with SMTP id q2so4627049iow.13 for <>; Wed, 13 Jan 2021 11:00:06 -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=xB5T2vdNCfTIBQ/ZkzArAQZUI4Yxdr2XX6sAFY4VXEw=; b=JoiyRr9fsehVU5idmPrYFZnPoTLzh3AQ5bic0Ko0Ix83S6pcjozYCeewNzaMONNVBK MHb5HbXuMQAdAVEmMFZ+wj5Lr5fV4hEO7+SYQo/aEVL2zYZOpVe6vfGU0Jbh6w1/5A6v htjEozcLPt0P0Wwda+x3YlOs8wnkK9WrVLnNY7CLjQwiDJIUr7qbeaM++4oE9hiW22Fv Z4IHrQIQp56jZnTy+XybGSD117zGMLDDbswgU3iBbZ9aiLTX4jQH4t4w1eP2nKi3LH4F pEZLNr7o6W5hblnUWjvZHz+hokTV/DjKHSpDT0M8dKF3toOA921Ue9PpUs1ElqmSPkjV qjZQ==
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=xB5T2vdNCfTIBQ/ZkzArAQZUI4Yxdr2XX6sAFY4VXEw=; b=ZsH9oMDWCxg95fBvXgUct+kxB5rHYOUC5utomBzOcdGhnKoY8bFtfpbtBtNnC3Gr+g 3iHHQq4as+wJuXEUUwwHv9OljxXslaiW2Tn/jHYyvIt27mSzGf6cJ0NeSdHKhMFUpY7n q/+RLMRC6Fg+tB66bVAVWvhXOK2M/qwjDqEdiO9h5ZTvH5zBKpuS0YHrIOi1qYJK34G2 afQjloc6hjRfsIa6qyp+KgOPitC/ywS4xt2F1TyzPD6H/Kxz+2Q/D7B8gQlr1JbshjYk eokTvq+2jtiLMzuJmiUY6Hvv2SrQdDv8uGFdXdjteEiYn89/2cRZ9RQNu7joroQISZ/F aNXw==
X-Gm-Message-State: AOAM530WqTX8S0+cTzg68RC6xweQigpAFX/QxAbdZIt68Nz/uyyp7E/F 3DHg/6UUSI8jZbLMOmUNlwVb4d62arw7+MxEoM1sY3a0bR8=
X-Google-Smtp-Source: ABdhPJz/nrFhOnFqn5mOTe0/U/nd44IieABmkrksbzlgG5ztLUloDynBQPluE0R/So/MykYpTLkAMF9tYh7nlhC2fls=
X-Received: by 2002:a6b:c94c:: with SMTP id z73mr2765136iof.95.1610564405619; Wed, 13 Jan 2021 11:00:05 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Wed, 13 Jan 2021 11:00:07 -0800
Message-ID: <>
Subject: Re: HTTP Delays
To: Ted Hardie <>
Cc: "Roy T. Fielding" <>, Magnus Westerlund <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000048f3a405b8ccbfb7"
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 Jan 2021 19:00:08 -0000

If the HTTP experts all agree that there will be no changes to the httpbis
documents that affect HTTP/3 implementations at all, then I would be fine
with option 3 (publish all drafts ASAP with downrefs as necessary).

Although I wonder if SECDIR review might alter a security recommendation in
some tangible way....

My only concern is that the 'h3' ALPN not be ambiguous due to a late change.

On Wed, Jan 13, 2021 at 10:55 AM Ted Hardie <> wrote:

> I largely agree with Roy here, with one caveat, in-line below
> On Wed, Jan 13, 2021 at 10:29 AM Roy T. Fielding <>
> wrote:
>> > On Jan 13, 2021, at 7:29 AM, Martin Duke <>
>> wrote:
>> >
>> > To summarize, I think there are three options:
>> > 1) Don't publish any RFCs until httpbis-semantics and httpbis-cache are
>> in the RFC Ed queue
>> > 2) Publish QUIC ASAP without HTTP/3, and suggest that deployed
>> endpoints run QUICv1 with ALPN h3-29/32/34 or whatever
>> > 3) Publish QUIC and HTTP/3 ASAP with a downref, allow ALPN h3 to
>> deploy, and hope nothing important changes in the httpbis docs.
>> >
>> > The second sounds cleanest to me, but I can certainly be persuaded of
>> the others.
>> This doesn't make any sense to me. HTTP is a mature protocol and
>> it simply doesn't matter to the protocol implementations whether
>> the xrefs line up to the correct section in an RFC. The wire definitions
>> don't change. There is no risk that the protocol will change because
>> of HTTP specification changes.
>> HTTP/3 doesn't have any normative dependencies on the attributes
>> of Semantics other than to QPACK, which itself is not based on any
>> normative rules of HTTP other than field values being strings. All
>> of the late edits have been for editorial cleanliness.
>> Likewise, even if HTTP Semantics were fixed in stone RFC tablets,
>> the protocol is extensible on the wire and HTTP/3 has to carry that
>> extensibility whether or not it is defined by an RFC.
>> In short, there's no need to be pedantic. As soon as the QUIC RFCs
>> enter the RFC ed queue, we can fix their content as such including
>> the final protocol versions and ALPNs. If the HTTP Semantics spec
>> needs additional changes, we can choose those changes deliberately
>> without impacting any content or references within HTTP/3. We don't
>> xref by page number. The IETF can preassign the new RFC numbers
>> for HTTP Semantics, Cache, and HTTP/1.1 at any time and use those
>> numbers for publication of QUIC and HTTP/3,
> While they could theoretically pre-assign it, the RFC Editor won't publish
> the document without the documents actually being available for retrieval.
> That's a big reason you get clusters.  This is why we do downrefs to the
> drafts; since there is an onward pointer from the referenced draft to the
> final RFC in the tools, that's considered okay as anyone who seriously
> wants the reference can readily find it.  [Note: my opinion on that is
> separate from my recitation of what I think the facts are.]
> or the entire set can
>> sit in the queue for a few weeks (finished and implementable) while
>> the RFC editor works on HTTP Semantics and Cache.
> I think they are implementable with the current drafts and that care in
> changes during any final edits will ensure that they will remain so.  This
> is why I support the downref theory.
> But this is my personal opinion, and it should definitely be considered in
> light of my personal scarring with the current procedures.
> Ted
>> Either that, or build a time machine and fix 2020.
>> ....Roy