Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)

["Martin Thomson" <[e-mail]>]

Kazuho,

Thanks for putting this together.  I only looked briefly, but this appears to faithfully capture what we discussed.

Why did you choose to express this with a dictionary `u=4, i=?1`** rather than a numeric item `4;i=?1`?

Can we look to simplifying this a little more?  I understand that reprioritization was identified as being important by the design team, but I don't recall seeing ever any evidence to support that view.  Can we split that piece out and maybe pursue it separately?

I would prefer to frame the way in which priorities are "merged" (Section 6) differently.  I would instead say that the priority information is input to prioritization decisions that endpoints/intermediaries/etc.. make.  So I would instead say that these entities simply make their own decision about the way to incorporate these signals into their decision.  That's probably a systemic thing that affects more than Section 6; I see that the draft uses "obey" in Section 7.1.1, for example.

There seems - at least to me - to be an assumption on the part of some people involved in this that Priority will be interpreted as an imperative.  That is, that a client might be able to tell a server to act in a particular way and expect to have that instruction complied with.  Same for servers and proxies.  That might be an appealing, but I can't see any way in which we can rely on that.  To the example in the draft, as a CDN, I would expect that the server's view carries more weight than the client's, but I wouldn't necessarily say that this something as absolute as is currently implied.

** The draft is unclear as to whether it is `u=4,i=?1` or `u=4;i=?1`, which you might want to double-check.

On Wed, Nov 20, 2019, at 20:04, Kazuho Oku wrote:
> Dear working groups members,
> 
> After the HTTPbis meeting on Monday, the priorities design team as well 
> as others have had discussions, and have converged on a particular 
> design (header-based, as well as allowing intermediaries to send frames 
> to express per-hop priorities).
> 
> We have submitted a new revision of the I-D that reflects the emerging 
> consensus, that clarifies more about the corner cases and how they 
> should be handled.
> 
> It can be found at: 
> https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04
> HTML version is: 
> https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html
> 
> We have asked chairs to give us some time in tomorrow's HTTPbis meeting 
> that we can use to provide an update on the status.
> 
> We are looking forward to hearing your comments either face-to-face, or 
> on the mailing list.
> 
> Thank you in advance.
> 
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: 2019年11月20日(水) 19:53
> Subject: New Version Notification for draft-kazuho-httpbis-priority-04.txt
> To: Kazuho Oku <[e-mail]>, Lucas Pardue <[e-mail]>
> 
> 
> 
>  A new version of I-D, draft-kazuho-httpbis-priority-04.txt
>  has been successfully submitted by Kazuho Oku and posted to the
>  IETF repository.
> 
>  Name: draft-kazuho-httpbis-priority
>  Revision: 04
>  Title: Extensible Prioritization Scheme for HTTP
>  Document date: 2019-11-20
>  Group: Individual Submission
>  Pages: 20
>  URL: https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-04.txt
>  Status: https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
>  Htmlized: https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04
>  Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority
>  Diff: https://www.ietf.org/rfcdiff?url2=draft-kazuho-httpbis-priority-04
> 
>  Abstract:
>  This document describes a scheme for prioritizing HTTP responses.
>  This scheme expresses the priority of each HTTP response using
>  absolute values, rather than as a relative relationship between a
>  group of HTTP responses.
> 
>  This document defines the Priority header field for communicating the
>  initial priority in an HTTP version-independent manner, as well as
>  HTTP/2 and HTTP/3 frames for reprioritizing the responses. These
>  share a common format structure that is designed to provide future
>  extensibility.
> 
> 
> 
> 
>  Please note that it may take a couple of minutes from the time of submission
>  until the htmlized version and diff are available at tools.ietf.org.
> 
>  The IETF Secretariat
> 
> 
> 
> -- 
> Kazuho Oku