Code change:
stream A, this results in a dependency order of A followed by D followed by B and C. <del> Streams are ordered into several dependency trees within their priority group.  Each dependency tree within a priority group SHOULD be allocated the same amount of resources. Inside a dependency tree, a dependent stream SHOULD only be allocated resources if the streams that it depends on are either closed, or it is not possible to make progress on them. </del> <ins> Inside the dependency tree, a dependent stream SHOULD only be allocated resources if the streams that it depends on are either closed, or it is not possible to make progress on them. </ins> <del> Streams with the same dependencies SHOULD be allocated the same amount of resources.  Thus, if streams B and C depend on stream A, and if no progress can be made on A, streams B and C are given an equal share of resources. </del> <ins> Streams with the same dependencies SHOULD be allocated resources proportionally based on their weight.  Thus, if stream B depends on stream A with weight 4, and C depends on stream A with weight 12, and if no progress can be made on A, stream B ideally receives one third of the resources allocated to stream C. </ins> A stream MUST NOT depend on itself.  An endpoint MAY either treat this as a StreamErrorHandler of type , or assign pri-default to the stream. <del> 5.3.3. </del> <ins> 5.3.2. </ins> Stream priorities are changed using the <del> frame.  Setting a priority group and weight causes a stream to become part of the identified group, and not dependent on any other stream. Setting a dependency causes a stream to become dependent on the identified stream, which can cause the reprioritized stream to move to a new priority group. All streams that are dependent on a reprioritized stream move with it.  Setting a dependency with the exclusive flag for a reprioritized stream moves all the dependencies of the stream it depends on to become dependencies of the reprioritized stream. </del> <ins> frame.  Setting a dependency causes a stream to become dependent on the identified stream.  All streams that are dependent on a reprioritized stream move with it.  Setting a dependency with the exclusive flag for a reprioritized stream moves all the dependencies of the stream it depends on to become dependencies of the reprioritized stream. </ins> <del> 5.3.4. </del> <ins> 5.3.3. </ins> When a stream is closed, its dependencies can be moved to become dependent on the stream the closed stream depends on, if any, or to <del> become new dependency tree roots otherwise. </del> <ins> become dependent on the connection otherwise.  The weights of new dependencies SHOULD be assigned by distributing the weight of the dependency of the closed stream proportionally based on the weights of its dependencies. </ins> It is possible for a stream to become closed while prioritization information that creates a dependency on that stream is in transit.

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: