Re: h2 priority

Hi Roy,

On Sun, Aug 31, 2014 at 7:06 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

>
>
> The reason I did not go into any more detail than that is because the
> priority information is only a suggestion, like in h2.  Defining how
> the recipient is going to reprioritize its stack based on existing
> streams is an implementation detail behind the HTTP interface: wishful
> thinking and untestable (because it is only a suggestion).  Editorially,
> section 5.3 belongs in an appendix, or as a separate spec that has time
> to ruminate on the balance between weighted streams and various
> response characteristics.
>

Editorially and organizationally I think you're right but am happy to defer
to the editor. As a matter of content, I think the fairly complicated
scheme is well justified in terms of identified problems spdy has shown
with using just a few bits of weight (aggregation of lots of clients, dash
like dependencies, etc..)


>
> > 6.2.  HEADERS
> >
> Priority is a suggestion.


imo it is only really a suggestion in the sense that it is untestable.
Priority is a core piece of h2, because h2 introduces mux and a
non-prioritized mux is worse than h1.


>   Sending it only within a separate frame
> type incurs an additional overhead of 64bits, only when it is sent,
> assuming we also allow PRIORITY frames to initiate a stream.
>

roberto suggested basically that not too long ago - tracked as
https://github.com/http2/http2-spec/issues/347 ..