Code change:
An endpoint receiving a frame that changes the priority of a closed stream SHOULD alter the <del> weight of the priority group, or the dependencies of the streams that depend on it, if it has retained enough state to do so. Priority group information is part of the priority state of a stream. Priority groups that contain only closed streams can be assigned a weight of zero. </del> <ins> dependencies of the streams that depend on it, if it has retained enough state to do so. </ins> <del> The number of priority groups cannot exceed the number of non-closed streams.  This includes streams in the "reserved" state.  Priority state size for peer-initiated streams is limited by the value of .  Reserved streams do not count toward the concurrent stream limit of either peer, but only the endpoint that creates the reservation needs to maintain priority information.  Thus, the total amount of priority state for non-closed streams can be limited by an endpoint. 5.3.5. </del> <ins> 5.3.4. </ins> <del> Providing priority information is optional.  Streams are assigned to a priority group with an identifier equal to the stream identifier and a weight of 16. </del> <ins> Providing priority information is optional.  Streams are assigned a dependency on the connection with a weight of 16. </ins> <del> PushResources initially depend on their associated stream. </del> <ins> PushResources initially depend on their associated stream with a weight of 16. </ins> 5.4.

Related discussion:
text: The priority groups are abandoned in favor of a single weighted dependency tree. The root node of the tree is the connection, assigned the stream identifier 0x0. By default, streams are assigned a stream dependency of 0x0 with a weight of 16.
Just read through it, I think it looks good. I'd like to understand how weight of the stream is calculated and changed. Here is my understanding: The effective weight of each stream is determined by traversing tree node, taking into account of distribution of weight of parent stream among siblings. This effective weight is temporal on the tree and initial weight is unchanged for a stream, so when reprioritizing that stream, its weight is initial one. For example, suppose we have the following dependency tree: X<--(w)--Y means that Y depends on X with weight w (and w is initial weight). Calculated effective weight is like this: If parent stream is closed, then its initial weight is distributed to among the child streams and this updates initial weight of child stream. So, after A was closed, the initial weight of streams becomes like this:
NAME thanks for this. I'll have to read through this more carefully before I comment. NAME that seems right. Note that this means that a server might want to maintain more precision on it's weight values than the 8 bits we mandate in the protocol. That said, if there are deep dependency trees and you are killing off nodes that are high up, at some point you will need to round off, so I think that how much precision is allocated is largely a discretionary thing.
Looks good. , Martin Thomson EMAIL:
It seems that we can make a stream to depend on stream 0x0 exclusively, which makes all existing connections its descendant. This is not possible in the current draft version. I wonder this can be directly proxy-able since stream 0x0 is imaginable stream.
Yea, the idea is that '0' is a reserved stream ID, and so it is safe to use it as a flag for saying that (effectively) any stream with '0' as a parent has no parent. , Tatsuhiro Tsujikawa wrote:
Well, then we should explicitly say that receiver must treat exclusive bit as 0 if stream ID field is 0.