Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY

Sounds good to me. I agree with documenting the issue.


On Tue, May 21, 2013 at 1:37 PM, James M Snell <jasnell@gmail.com> wrote:

> Honestly, there's no rush on it. All I am doing at this point is
> documenting the proposal so it can be tracked and ultimately addressed
> at some later point in the process.
>
> On Tue, May 21, 2013 at 9:32 AM, William Chan (陈智昌)
> <willchan@chromium.org> wrote:
> > We discussed this previously and Roberto and I were both against the
> removal
> > of the priority field from the HEADERS+PRIORITY frame:
> > http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1065.html,
> even
> > considering stream reprioritization.
> >
> > I support adding a new additional PRIORITY frame for stream
> > reprioritization. That said, I'm in no hurry to write anything into the
> > spec. On the SPDY end we're planning on experimenting with prioritization
> > and when we have something to present with detailed explanations why, we
> > will do so. We presented the general ideas previously in the last interim
> > meeting and haven't finished implementation and experimentation.
> >
> > Unless there's a reason this needs to be in the current http/2 draft
> sooner
> > rather than later, I'd rather punt on this discussion until we have
> > implementation experience that can guide this debate. I believe everyone
> > recognizes that people are interested in reprioritization. If we need to
> put
> > something in the spec, let's just add a new frame and then revisit
> changing
> > HEADERS+PRIORITY later.
> >
> >
> > On Tue, May 21, 2013 at 1:10 PM, James M Snell <jasnell@gmail.com>
> wrote:
> >>
> >> https://github.com/http2/http2-spec/issues/99
> >>
> >> With regards to the discussion over stream re-prioritization, I suggest:
> >>
> >> 1. Drop the HEADERS+PRIORITY frame type.
> >> 2. Create a new separate PRIORITY frame type whose payload is the
> >> Priority value, no frame-specific flags.
> >> 3. The PRIORITY frame becomes the only way to set/change the priority
> >> for a stream.
> >>
> >> If it is necessary to allow an endpoint to establish the priority of
> >> stream prior to actually initiating the stream, we can allow sending a
> >> PRIORITY frame before the initial HEADERS frame. Doing so would
> >> effectively reserve the stream id (in the same general manner
> >> PUSH_PROMISE does).
> >>
> >> The advantages of this approach are:
> >>
> >> 1. It eliminates any possible confusion and complexity about when to
> >> use HEADERS+PRIORITY vs. HEADERS
> >> 2. It provides a single way of setting/change stream priority (as
> >> opposed to using HEADERS+PRIORITY plus a separate CHANGE-PRIORITY
> >> frame)
> >>
> >
>