Re: HTTP Delays
"Roy T. Fielding" <fielding@gbiv.com> Wed, 13 January 2021 18:29 UTC
Return-Path: <fielding@gbiv.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349F3A1278 for <quic@ietfa.amsl.com>; Wed, 13 Jan 2021 10:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC7q1vdtghAZ for <quic@ietfa.amsl.com>; Wed, 13 Jan 2021 10:29:10 -0800 (PST)
Received: from hamster.birch.relay.mailchannels.net (hamster.birch.relay.mailchannels.net [23.83.209.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748CC3A1277 for <quic@ietf.org>; Wed, 13 Jan 2021 10:29:10 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A6064230DB; Wed, 13 Jan 2021 18:29:06 +0000 (UTC)
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (100-96-12-179.trex.outbound.svc.cluster.local [100.96.12.179]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3156D2306E; Wed, 13 Jan 2021 18:29:06 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Wed, 13 Jan 2021 18:29:06 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Trouble-Shoe: 43141f0127e2e5a1_1610562546458_2237309483
X-MC-Loop-Signature: 1610562546458:3437910720
X-MC-Ingress-Time: 1610562546457
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id E6C987EFEC; Wed, 13 Jan 2021 10:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=BX3SKpcFEsJyBBad790NrRqxrtI=; b=nOEE2Plp0E66hn8q+2LdfIqUwr/y OqEfs73g24Hx2y7XoFszRjAVgaRaa2tDhZkHLKoaIkxcEBc5zcDGII7V12nP43Ys VmQcNS8N3DzjcYllwcuCC3LvqPeih0UythB/90fuLdeZq9qXp9LUHTrMaZSGxhl8 +szDzJtMLMgMyPM=
Received: from [192.168.1.10] (ip68-101-102-139.oc.oc.cox.net [68.101.102.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by pdx1-sub0-mail-a26.g.dreamhost.com (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" <fielding@gbiv.com>
In-Reply-To: <CAM4esxQeFaYytwyeB+m_yDrn8SSR8Yy4BHTsvxngTjG3=y0Zag@mail.gmail.com>
Date: Wed, 13 Jan 2021 10:29:03 -0800
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "ted.ietf@gmail.com" <ted.ietf@gmail.com>, "quic@ietf.org" <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4459A34C-ED70-4354-9653-BA5165EC887A@gbiv.com>
References: <CAM4esxSObWwLfzRWazAg+Q+9=BHGzXaSSduONozHF_zGCqC-kg@mail.gmail.com> <CA+9kkMA++3QYnXiVwuKSPZDYycERRrC11b-jHTG6JcyjngDhqA@mail.gmail.com> <CAM4esxQ9w0h2-rZ1ynhEMKAxwq0gfSVJtfGXV8ydGdUTEefMuA@mail.gmail.com> <029bd6e66fb81e2ecf16e35adf30b90c816c9962.camel@ericsson.com> <CAM4esxQeFaYytwyeB+m_yDrn8SSR8Yy4BHTsvxngTjG3=y0Zag@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/CWJ7JA9ZYT2erojdsG7lntVKCNQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2021 18:29:13 -0000
> On Jan 13, 2021, at 7:29 AM, Martin Duke <martin.h.duke@gmail.com> 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. ....Roy
- HTTP Delays Martin Duke
- Re: HTTP Delays Ted Hardie
- Re: HTTP Delays Julian Reschke
- Re: HTTP Delays Martin Duke
- Re: HTTP Delays Martin Duke
- Re: HTTP Delays Julian Reschke
- Re: HTTP Delays Martin Thomson
- Re: HTTP Delays Martin Duke
- Re: HTTP Delays Magnus Westerlund
- Re: HTTP Delays Martin Duke
- Re: HTTP Delays Magnus Westerlund
- RE: HTTP Delays Mike Bishop
- Re: HTTP Delays Roy T. Fielding
- Re: HTTP Delays Ted Hardie
- Re: HTTP Delays Martin Duke
- Re: HTTP Delays Julian Reschke
- Re: HTTP Delays Magnus Westerlund
- Re: HTTP Delays Julian Reschke
- Re: HTTP Delays Martin Duke
- Re: HTTP Delays Ian Swett
- Re: HTTP Delays Roy T. Fielding
- Re: HTTP Delays Julian Reschke