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

["Roy T. Fielding" <[e-mail]>]

I agree with Martin’s comments. We really should emphasize that these are suggestions for improving the user experience that may need to be adjusted based on external knowledge by recipients.

Also, there is a spot in the document where Vary is mentioned as being appropriate. I don’t agree that Vary is ever appropriate for this feature because that changes the semantics of the priority in ways that are terribly unpredictable, nor is content negotiation on the basis of received Priority a good idea. I would simply require that Priority not be included in preemptive content negotiation and be done.

Even with these minor issues, I think this draft is a great improvement and is ready for adoption by the WG.

....Roy


> On Nov 21, 2019, at 8:17 AM, Martin Thomson <[e-mail]> wrote:
> 
> 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
>