Re: HTTP Delays

"Roy T. Fielding" <> Wed, 13 January 2021 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7349F3A1278 for <>; Wed, 13 Jan 2021 10:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HC7q1vdtghAZ for <>; Wed, 13 Jan 2021 10:29:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 748CC3A1277 for <>; Wed, 13 Jan 2021 10:29:10 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id A6064230DB; Wed, 13 Jan 2021 18:29:06 +0000 (UTC)
Received: from (100-96-12-179.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 3156D2306E; Wed, 13 Jan 2021 18:29:06 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.11); Wed, 13 Jan 2021 18:29:06 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Trouble-Shoe: 43141f0127e2e5a1_1610562546458_2237309483
X-MC-Loop-Signature: 1610562546458:3437910720
X-MC-Ingress-Time: 1610562546457
Received: from (localhost []) by (Postfix) with ESMTP id E6C987EFEC; Wed, 13 Jan 2021 10:29:05 -0800 (PST)
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=BX3SKpcFEsJyBBad790NrRqxrtI=; b=nOEE2Plp0E66hn8q+2LdfIqUwr/y OqEfs73g24Hx2y7XoFszRjAVgaRaa2tDhZkHLKoaIkxcEBc5zcDGII7V12nP43Ys VmQcNS8N3DzjcYllwcuCC3LvqPeih0UythB/90fuLdeZq9qXp9LUHTrMaZSGxhl8 +szDzJtMLMgMyPM=
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 6B4FF7E6B4; Wed, 13 Jan 2021 10:29:04 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: HTTP Delays
X-DH-BACKEND: pdx1-sub0-mail-a26
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Wed, 13 Jan 2021 10:29:03 -0800
Cc: Magnus Westerlund <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Martin Duke <>
X-Mailer: Apple Mail (2.3445.104.17)
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 18:29:13 -0000

> 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, 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.

Either that, or build a time machine and fix 2020.