Re: Nit: Server-sent priority

how about something like:
A client must not respond request a change in priority for a stream purely
on the basis of receiving a server priority announcement on that stream,
except when the client has never attempted to set a priority for that stream

-=R


On Tue, Jun 18, 2013 at 3:42 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> We discussed the possibility that a server could send PRIORITY (either
> in its own frame or attached to HEADERS).  The idea was that the
> server could advise a client about the priority that it is applying,
> which might be different to the priority that a client requested.
>
> This adds a challenge for clients: does the client now provide updated
> priorities that are relative to the priorities that it sent
> previously, or relative to the priority that the server has indicated?
>
> e.g., client sends three requests, priority 7, 10 and 15.  Server
> responds and indicates priorities of 3, 5 and 7.  If the client wants
> to issue a new request that is higher priority than the lowest
> priority existing request, does it indicate a priority of between 10
> and 15?  Or does it indicate a priority of 6?
>
> This editor wants to know.  I think that the easiest approach would be
> to stipulate that the priorities spaces are independent and that
> client priorities are only relative to client priorities.
> Unfortunately, that means that I need to include the example above as
> well.
>
> I don't want to prohibit servers from sending priority, because I
> believe that it could be useful for a client to understand how
> priority is being applied.
>
>