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

[Kazuho Oku <[e-mail]>]

2019年11月21日(木) 9:54 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.
>

Roy, thank you for the review and the suggestion. I think you are correct,
I have opened
https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/119 to address
the issue.


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

-- 
Kazuho Oku