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
Received on Tuesday, 2 September 2014 15:28:27 UTC