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

[James M Snell <[e-mail]>]

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 (陈智昌)
<[e-mail]> 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 <[e-mail]> 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)
>>
>