Re: HTTP Delays

Ted Hardie <> Wed, 13 January 2021 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F31663A1292 for <>; Wed, 13 Jan 2021 10:55:50 -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 aNnj0jArNGcY for <>; Wed, 13 Jan 2021 10:55:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 573883A1295 for <>; Wed, 13 Jan 2021 10:55:49 -0800 (PST)
Received: by with SMTP id d20so2915947otl.3 for <>; Wed, 13 Jan 2021 10:55:49 -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=Xn61jjb+ROfHfkh/QPHBKgOcANdppIzqK2Czn0YPkhE=; b=ZVGsoSWz23idJPH7Okx9ypnXDXddiWB5BDwYQdBqY8NMt/Rdy+mcZl5ef8vCor2cd0 n6mPwFVDond38n2Wc/PcRrKf2noBxHxZ82qa/PfB6RLOcNTbDJmdLN2bMB8gWrIPqm4t PsanLhkm9I3sFUWsb53vOtmet7yjYZcpvoYmQWSE4/6U5N06p9IxggJ8L2xermdubUiE RjficQyL0jI/fdeuLtxe/m3Ydk9vy+pgCsFbO7E7wCn90NmnvcwqJLy9m+cWXsQdYdVD UKSN51Yr1LdVUGpTuUAxLrrInWzPTACjYwOHV23at3Rvr9hCRZhxIApHtupdbgtseuny 68mA==
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=Xn61jjb+ROfHfkh/QPHBKgOcANdppIzqK2Czn0YPkhE=; b=ARRBIH4dbng+a1RGX/6fch+cJCO241YjMPLUZkFgYrw6SHydQc/AHz1OScWpsqTrqc e6qqS9WyakBuH2o0xpg42ExDXLJ5ZxRO63izFGCQrsIaIv2BdTuNJnrZ5yY1B0MQnN3U rNfiDHAt57FouW7ay2yVX8ChR5YjDolynQBhS1gzY98PxKsBQ6S2UFi1D2ZFq5xNIZsZ KJJdtstjZHzkZFy6yxP8s5b2uIbaTxFCv5MvslzGuUs/+jTBuoFvxYj1zuLd8+gIpc5q KP2iD4ofEvSvjEgvSbqdXG2eF+2g3bNQ0d7LqOkQt5TW19/WiQ24/9DcsS/wRNAkIUqs PN6A==
X-Gm-Message-State: AOAM532SRqPZSC71o0/V3xQo1BdTrIxBpIR9emDRWIpLKUB3nuIi7WGU J5fXHYwlVl95kUDWiS1my9nNXjpVrK0lZIZ69PU=
X-Google-Smtp-Source: ABdhPJz+bhYwHJ0+oRxssZJlY1WehKQx42/MURLKecCouAr+NDmqITShC+ZsCT9UTdPK3x3QsjDKJyVNpfg1roEw2I0=
X-Received: by 2002:a9d:6208:: with SMTP id g8mr2251033otj.165.1610564148678; Wed, 13 Jan 2021 10:55:48 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Wed, 13 Jan 2021 10:55:22 -0800
Message-ID: <>
Subject: Re: HTTP Delays
To: "Roy T. Fielding" <>
Cc: Martin Duke <>, Magnus Westerlund <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000f8554205b8ccaf86"
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:55:51 -0000

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.


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