Code change:
The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can be sent at any time for an existing stream.  This enables <del> reprioritisation of existing streams. </del> <ins> reprioritization of existing streams. </ins> The payload of a PRIORITY frame contains the following fields: <del> A single reserved bit.  This field is optional and is only present if the PRIORITY_GROUP flag is set. A 31-bit identifier for a priority group, see StreamPriority. This field is optional and is only present if the PRIORITY_GROUP flag is set. An 8-bit weight for the identified priority group, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the PRIORITY_GROUP flag is set. </del> A single bit flag indicates that the stream dependency is <del> exclusive, see StreamPriority.  This field is optional and is only present if the PRIORITY_DEPENDENCY flag is set. </del> <ins> exclusive, see StreamPriority. </ins> A 31-bit stream identifier for the stream that this stream depends <del> on, see StreamPriority.  This field is optional and is only present if the PRIORITY_DEPENDENCY flag is set. The PRIORITY frame defines the following flags: </del> <ins> on, see StreamPriority. </ins> <del> A PRIORITY frame MUST have exactly one of the PRIORITY_GROUP and PRIORITY_DEPENDENCY flags set.  Receipt of a PRIORITY frame with either none or both these flags set MUST be treated as a StreamErrorHandler of type </del> <ins> An 8-bit weight for the identified stream dependency, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256. </ins> <del> . </del> <ins> The PRIORITY frame does not define any flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the

Related discussion:
text: NAME I would add an explicit hint to implementers that having more than 8 bits of internal precision is a good thing. NAME I think we should leave open the possibility to insert a new stream between the connexion and all its children, even if it's probably a large re-prioritization.
I think large re-prioritization is not a problem. If proxy gets such requests and it aggregates several frontend connections to single backend connection, inserting under stream 0x0 with exclusive flag set seems to be impossible in backend.
If it aggregates to a different backend connection it is not impossible to proxy. Consider streams A and B depend on stream 0x0 and are proxied to some backend connection as streams X and Y. If we get a new streams, C, that exclusively depends on 0x0, we can proxy it as stream Z by dropping the exclusive dependency and then re-prioritizing streams X and Y to depend on stream Z.
Yes, it works like that. But if we just don't allow 0x0 with exclusive dependency, we can do all priority stuff via proxy without doing any extra handling except for stream ID mappings.
Yep, true -- I don't have much of a preference -- if clients feel like it is not an important use case than I am perfectly happy to disallow it.
Is it possible to move this discussion to the mailing list? If you need comments from a client, I'm happy to take a look later. On Tue Apr 15 2014 at 9:39:56 AM, Jeff Pinner EMAIL wrote: