Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt

"Roy T. Fielding" <> Fri, 12 July 2019 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74FC4120912 for <>; Fri, 12 Jul 2019 11:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 4GSjk-KRCJqm for <>; Fri, 12 Jul 2019 11:55:57 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A486912049C for <>; Fri, 12 Jul 2019 11:55:57 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hm0gd-0000Gz-3t for; Fri, 12 Jul 2019 18:54:27 +0000
Resent-Date: Fri, 12 Jul 2019 18:54:27 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hm0gb-0000GD-AL for; Fri, 12 Jul 2019 18:54:25 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hm0gZ-0002VB-Hp for; Fri, 12 Jul 2019 18:54:25 +0000
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id AF38C22C3A; Fri, 12 Jul 2019 18:54:00 +0000 (UTC)
Received: from (100-96-30-63.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id E8E0D22C76; Fri, 12 Jul 2019 18:53:59 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ([TEMPUNAVAIL]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.17.3); Fri, 12 Jul 2019 18:54:00 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Towering-Tangy: 7ea7b71654331bc9_1562957640486_2277978575
X-MC-Loop-Signature: 1562957640486:3127520565
X-MC-Ingress-Time: 1562957640486
Received: from (localhost []) by (Postfix) with ESMTP id 48825800E0; Fri, 12 Jul 2019 11:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references;; bh=I5pH2XK1WnaHSDVc7EKto73M9t8=; b= I8oz7g3fBNi9u0CeKXCihnEKBYbJmdKpqiBuiEecxV03zVJdudwVEGpQ2+N//PFZ TbuSaDWm91x6J6lutya++ZcGx9fFHrgHKYp8CpgC8R+I68If8gPqgwdWBfc+v1Uv p/PsZlO0R+wAoC6SXLXoFmoxZqdsYU9CXtaC1fNWiEI=
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 DC43A800EA; Fri, 12 Jul 2019 11:53:53 -0700 (PDT)
X-DH-BACKEND: pdx1-sub0-mail-a84
From: "Roy T. Fielding" <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_450CF052-095B-482E-924A-4EA8287A84C8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 12 Jul 2019 11:53:53 -0700
In-Reply-To: <>
Cc: HTTP Working Group <>
To: Kazuho Oku <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrhedtgdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegoufhushhpvggtthffohhmrghinhculdegledmnecujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpedftfhohicuvfdrucfhihgvlhguihhnghdfuceofhhivghlughinhhgsehgsghivhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrihhopdhgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecukfhppeeikedrvddvkedrkedurddvheenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdekngdpihhnvghtpeeikedrvddvkedrkedurddvhedprhgvthhurhhnqdhprghthhepfdftohihucfvrdcuhfhivghlughinhhgfdcuoehfihgvlhguihhnghesghgsihhvrdgtohhmqedpmhgrihhlfhhrohhmpehfihgvlhguihhnghesghgsihhvrdgtohhmpdhnrhgtphhtthhopehivghtfhdqhhhtthhpqdifghesfiefrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.025, 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hm0gZ-0002VB-Hp be1b80057db6afd76ada1962fbf3f2ee
Subject: Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/36797
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Jul 12, 2019, at 7:01 AM, Kazuho Oku <> wrote:
> Hello all,
> Thank you very much for all the discussion here and elsewhere.
> Based on the feedback, Robin, Lucas and I have expanded the number of urgency levels from 3 to 8, including a "background" level. From what we have heard, this would be sufficient; 5 levels is what some browsers use now (and we now provide 5 + background to them).
> I hope that this gives them enough space to start with (we can subdivide existing levels later), at the same time associating enough meanings to each of the urgency levels so that the servers can tweak the prioritization scheme.
> We can't submit -01 now, but the up-to-date draft can be found at:
> <>
> The repository and the issue list can be tracked from <>.
> Please let us know what you think. Thank you in advance.  

Hi Kazuho,

This is starting to sound a lot like Waka's request priority (hi, lo, HiLo) and request context
[slide 9 of <> ]. I agree that defining
this as an e2e header field is a good way forward. HiLo is progressive with high priority for the
first block and then regular priority for the rest.

Note that there are other (security and privacy) reasons for explicitly communicating the context
of a request, since it can be used to detect some forms of fraud, phish, or transclusion.
However, that would need to be in a non-script-settable field.

We should also consider non-browsing priorities, such as indicating intentionally long-lived
responses that might have a low priority but do require some form of unbuffered regularity
(e.g., pongs). I don't think progressive is an independent parameter unless we intend
to communicate some sort of block size; otherwise, it is just saying that HoL blocking
isn't desired, which is not necessary to communicate beyond not setting "background".

In general, I like the approach, but I think the structured header syntax is the wrong choice.
Why send 26 bytes to communicate one (or maybe two) bytes of information?