Re: HTTP Delays

"Roy T. Fielding" <fielding@gbiv.com> Thu, 14 January 2021 23:31 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 2BB6A3A0981 for <quic@ietfa.amsl.com>; Thu, 14 Jan 2021 15:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, 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 FKiNPF3SxV2B for <quic@ietfa.amsl.com>; Thu, 14 Jan 2021 15:31:27 -0800 (PST)
Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (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 8E9E03A0977 for <quic@ietf.org>; Thu, 14 Jan 2021 15:31:23 -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 3C42D7E3117; Thu, 14 Jan 2021 23:31:22 +0000 (UTC)
Received: from pdx1-sub0-mail-a26.g.dreamhost.com (100-98-118-101.trex.outbound.svc.cluster.local [100.98.118.101]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D77707E2F95; Thu, 14 Jan 2021 23:31:21 +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 ECDHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/6.0.1); Thu, 14 Jan 2021 23:31:22 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Fearful-Celery: 3d9944490d396809_1610667082130_2766435403
X-MC-Loop-Signature: 1610667082130:3788716068
X-MC-Ingress-Time: 1610667082130
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 986827EFEB; Thu, 14 Jan 2021 15:31:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=gbiv.com; bh=IhG0Ke4TYvBT4HuMs/eHVc6IqBg=; b= YNEYqRnyRproDk66EAr4IbD+oxTk3n3oDYLsBGX+nXBdHRJegkW4YH5iAIXpZ2hs 5OL1GLkwGYVsh8jH/lGWpyPP4OUHPx31ilyHWVXhVvF+7qhIF18Au3iTSsBvWHN6 sErZFxl2zDlI0vY5MRw4llR9GTxmms+LUSVDTzqdInI=
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 6F21F7EFD9; Thu, 14 Jan 2021 15:31:18 -0800 (PST)
X-DH-BACKEND: pdx1-sub0-mail-a26
From: "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <9EE727A4-600D-4079-B285-F0B0909C27FB@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F1D1B79-EA8B-4605-BC2C-94BC73C5EA9E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: HTTP Delays
Date: Thu, 14 Jan 2021 15:31:17 -0800
In-Reply-To: <7b3fe48634ddd2c93172656c44cf64ec0e3cdd3f.camel@ericsson.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, "quic@ietf.org" <quic@ietf.org>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
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> <4459A34C-ED70-4354-9653-BA5165EC887A@gbiv.com> <CA+9kkMAqj2B8VprF_j=jLJ2CKbWvR6oO+ciHaTCSF1Sd3f_KtQ@mail.gmail.com> <f64ca7ca-0f54-3a8d-b5aa-428835bef6bb@gmx.de> <7b3fe48634ddd2c93172656c44cf64ec0e3cdd3f.camel@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZPyv1xPHu9-4EbAzll3tigKTrDc>
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: Thu, 14 Jan 2021 23:31:29 -0000

> On Jan 14, 2021, at 5:53 AM, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote:
> 
> That is why I didn't understand Roy's comment:
> 
>> 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. 
> 
> What you can do is do a last alignment in AUTH48 with the status of HTTP
> semantics and cache at this point. If we want the rfc numbers of the HTTP specs,
> then you have to wait until they are ready and also in AUTH48. So, if the HTTP
> semantics and cache aren't ready when we come to AUTH48 you still have the risk
> of missalignment if going down the downref path. 

I meant that the HTTP/3 draft would remain in the queue (done but not
published except on the WG site) until its normative references can also
be published as RFCs. That does not prevent implementations from
deploying the protocols as specified. I guess that matches choice (4).

> I would like to point out that just this week a PR was merged to the HTTP/3 spec
> to align with the latest changes done in the HTTP semantics. So the risk for
> missalignment is not zero here. Sure the HTTP specs are mature, but you can
> still end up in a situation where it becomes hard to interpret HTTP/3 correctly
> when section numbering and terms don't align. 

Right, but we did that editorial change deliberately because all five
HTTP specs can align on terminology, knowing full well that this is
a change we can do right now (and probably not after). We might
want to make additional changes around how [HTTP11] is referenced
by HTTP/3, but this would also be to align the specs while we still can.

I am pretty sure that none of us will want to make such editorial
changes once alignment is no longer possible.  Julian even has
a script to check that we haven't broken xrefs from HTTP3.

Cheers,

....Roy