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

Kazuho Oku <> Mon, 15 July 2019 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEA8B1200F4 for <>; Mon, 15 Jul 2019 05:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.752
X-Spam-Status: No, score=-2.752 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, MAILING_LIST_MULTI=-1, SPF_PASS=-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 O1HlbC1K2gaR for <>; Mon, 15 Jul 2019 05:38:25 -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 34C54120112 for <>; Mon, 15 Jul 2019 05:38:25 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hn0Ck-00058R-Bn for; Mon, 15 Jul 2019 12:35:42 +0000
Resent-Date: Mon, 15 Jul 2019 12:35:42 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hn0Ch-00057c-J6 for; Mon, 15 Jul 2019 12:35:39 +0000
Received: from ([2a00:1450:4864:20::229]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hn0Cc-000353-Vz for; Mon, 15 Jul 2019 12:35:39 +0000
Received: by with SMTP id m23so15964319lje.12 for <>; Mon, 15 Jul 2019 05:35:14 -0700 (PDT)
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:content-transfer-encoding; bh=u75l5glER7xjYk+ZfMY1pNBP9FVoCCsGyELYtl6XVUw=; b=XEhtijDwMtQa/T+/5Jk4Y6QR1Dsi6A8ypx9StuISF8B4LPVio1YAnK5HP8I3D8RbmI EL69KYNnUXsMOpAQjkHQgmxwvnpz6xbbM0Pah7hSR0gs3hTMrE92euBMKjzgtlwbz/GQ 6D+QRR+sy2d8h9WEQJmHXcGx10vhEWuHIMJbDtEX69bV1HKozwrbTDEVyNjZ257VHv5U uFKUgBvlqGo/sINozmSpkxkJQ90XyuMGeGDYDTA1t8O/iLabzjokmIX3u5681FkBPftb jKskna2syJsW5V0EWx6FESiMxJ6yv0f0xcTsqpaUZKPP3LDZiYaysUipNacw23sUEN/P UVKw==
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:content-transfer-encoding; bh=u75l5glER7xjYk+ZfMY1pNBP9FVoCCsGyELYtl6XVUw=; b=roJrEyWc8Ekq0jvgU/1YC5BRohhX8UauF810FscbcaMNeusLll5LPZdPstEtOCuZge FsJNrN4+6XR2Tb8it1z93iYS6UQRM0H7lDhVH/VnXBCZSY0Xok6HQq63ney8wQlAVcXf fTpoTxPgDB+gigWkZr6S5yKsKG1sWI/zi2v/EKTyI5J4WetWeLyDqBmuzUkiwnhbp5l2 m/zsbK4dcHLXMNuQxpxv32L8oLh09dPuAUeORn5iWejLFDXXXwFAcbDDZGYhsLWTvvRF muv7z6D3EaLOC6EvspT16YuXrALLhsQzM6lj2EnLlJaXTeOrT5SZUi95FsHZvb+26Jrl 3WFQ==
X-Gm-Message-State: APjAAAWVtTYlsPeAzNqWSJZKc9LgnLKz9m268Y5Sr/1mcgGJjBz9o8Mt GkzRl5ViKaMdv0iI6EmgJYi48jx2ZmOy4cF8qsiwvg==
X-Google-Smtp-Source: APXvYqy0YRYKxp1H6hPeFSzEFhGePcCUAKQica7j1tjE33Z9UhcqHg6bu84wK7fo/EndUlEdC8mmJX3XUkGGTeDqC2o=
X-Received: by 2002:a2e:9b03:: with SMTP id u3mr13877915lji.15.1563194112177; Mon, 15 Jul 2019 05:35:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Mon, 15 Jul 2019 21:35:02 +0900
Message-ID: <>
To: "Roy T. Fielding" <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::229;;
X-W3C-Hub-Spam-Status: No, score=-2.8
X-W3C-Hub-Spam-Report: AWL=1.333, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hn0Cc-000353-Vz 0ac0da3259602d3350152e77b2e5ffeb
Subject: Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/36805
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Roy, thank you for your comments. My responses inline.

2019年7月13日(土) 3:54 Roy T. Fielding <>om>:
> 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.

Thank you for sharing the slides. It's reassuring to know that you had
thought about something similar, and still think that it's preferable.

HiLo is interesting. Am I correct in assuming that the intended
primary use case is to transmit the size of the images so that the
browsers can determine the layout at an earlier moment?

While I think that such signal is useful to some extent, I am not sure
how useful it is.

Partly because it is not the best way of notifying the client the
metadata at the earliest moment. In case of images, we typically embed
the size of the image either in the CSS or the IMG tag, so that the
client would not need to wait for the first few bytes of the image.

The other reason is that HiLo does not communicate the reason the
client thinks the first few bytes are important. If we are to have
something like HiLo, I think it would be better to have a richer
signal that tells the server why and / or what needs to be sent ASAP.

Considering these aspects and the fact that the H2 prioritization does
not have this type of signal, I think we can start without having HiLo
in the Priority header.

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

I agree that such filtering rule would help us to some extent. Though
it would be fragile regardless of the header field defined as
non-script-settable, considering the fact that clients that do not
implement the Priority header extension could pass through the header
field set by the application.

> 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'd argue that one of the non-background urgencies should be used for
a request that require a timely response (e.g., ping-pong).

Maybe the issue in the current draft is that, as others have pointed
out, the terms "non-background" urgencies are too browser-centric. It
might be a good idea to consider renaming "document" to "default" at

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

I'd argue that the progressive parameter is not related to HoL
blocking. It's rather a way to signal if the user experience would
improve by interleaving the response with others. The intended
use-case is for images that support progressive rendering, as IIUC
generally assumed that interleaving between the responses that carry
images that can be rendered progressively improves user experience.

> 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?

Honestly speaking I wouldn't mind choosing something else than
Structured Headers as long as the alternative is extensible. At the
same time, I do not think 26 bytes is an issue because I'd assume that
it would be compressed into just a few bytes with HPACK / QPACK.

> ....Roy

Kazuho Oku