Original text:
cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect <del> on the current stream.  For a stream that is in the "half closed </del>  (remote)" or "closed" - state, this frame can only affect processing <del> of the current stream and not frame transmission. </del>  The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent

Reviewer comments:
Two issues were raised about the use of the words "existing" and "current" to refer to streams. These were a little squishy, so I tightened the language a little. The text no longer uses either word to refer to streams, instead using stream states to describe where the relevant text applies and favouring "identified" as a fallback.
uses some under specified termonlogy: For example is for a PRIORITY frame which can be sent/received in the any state the same as in the following contexts: Can be translated to the stream's state? For example does it roughly mean ? If so then the usage in the PRIORITY frame section is a bit more confusing because a PRIORITY frame could be the first valid frame sent/received for a stream.
NAME - Thanks for the clarification!
NAME - I do have a question regarding your clarifications to the SETTING frame (specifically the SETTINGSINITIALWINDOWSIZE portion). It seems a bit confusing if a PRIORITY frame has been exchanged on an IDLE stream for the SETTINGSINITIALWINDOWSIZE not to apply to it. Consider the following example: 1) Stream is in the state (no frames exchanged) 2) A PRIORITY frame for stream is received. 3) A SETTINGS frame is received to update SETTINGSINITIALWINDOW_SIZE. ... 4) Stream transitions into the state. Is seems a bit counter intuitive that stream 's window will be the window size prior to step 3. Just imagine there are many more SETTINGS frames exchanged (and other events) before step URL stream 's window will be even more difficult to understand how it got to where it is.
That's a fair point. The current text is: From this, you might infer that a reserved or idle stream isn't affected. Implicit in here is that you don't actually have an active flow control window until streams are in those states. There is no sense in performing any accounting until you are actually sending, right? But then, it's only accounting and that 32-bit number might be allocated and used in some implementations. So, I think that this can be clarified, rather than rely on people only accounting in those states, the text might be better saying: Does that make more sense?
This does make more sense. On a related URL is the rational to prohibit WINDOWUPDATES on the IDLE streams when PRIORITY frames have been exchanged? It seems like if a stream is allowed to be put into the priority tree (via a PRIORITY message) and its window size controllable (via SETTINGS) then why would a WINDOWUPDATE also not be allowed? I look to the following statement and think that accounting may already be required to track the PRIORITY and SETTINGS updates. The WINDOW_UPDATE accounting seems like it is very similar (or may be close to identical depending on the implementation).
We want to strictly limit the amount of state that is maintained for non-open streams. Currently, that is limited to priority. Opening that to more state isn't really necessary. For WINDOWUPDATE, there is only the case where you want to open the flow control window immediately after opening a stream, which currently causes a potential stall on the remote/sender side. As specified, you can create a priority graph that is separate from the other stream state (flow control in particular). If we allowed WINDOWUPDATE in idle (or reserved), then you need to commit more state. We already acknowledge that priority information needs special handling outside of the key stream states, so the risk is both accounted for, and already present. The most important factor though is that priority is expendable. Under DoS, you can drop priority on the floor. You can't do the same for flow control. Therefore, any state commitment needs to be strictly bounded for that.
Right. So for these cases the peer creating the stream will have to wait to expand (or shrink) the window until after the stream has transitioned out of the IDLE state. So state may not be required however if a peer wants to change the window for that stream then state will be necessary to keep and act upon when the state transition occurs. I"m not sure I follow. WINDOW_UPDATE is allowed in reserved according to . Priority is an interesting portion of the spec. It almost seems like you could ignore priority all together and be compliant :)
Hmm, strange how you forget these things. Yes, you can send WINDOWUPDATE in "reserved (remote)". This allows a client to affect the flow control window of the server that has promised a push. This is something that I know Firefox uses so that it can resume stalled pushes when it knows that they are needed. No extra credits over the initial window size are given to pushed streams until they are recognized as necessary. You can't send WINDOWUPDATE in "reserved (local)". After all, the other side (the client) won't be sending anything on that stream. So none of this really affects processing of the setting :)
I think I agree with you in general (it is not necessary). I agree that minimizing state on IDLE streams seems like more of a driving force, and I also recognize that the peer can wait to send WINDOW_UPDATES until transitioning out of IDLE. I can also imaging a scenario that if an endpoint puts the node into a priority tree, it is possible they have an estimate of what they are going to be sending. It may then follow the theme of "a more flexible expressions of priority" (from ) to also be able to control the window of those streams (at a finer granularity than the SETTINGS frame). Anyways thanks for the discussion and clarification.
Editorial problem, I hope: The spec uses the phrase "current stream" in two places (both related to PRIORITY), but without any definition of what that means: 1) "5.1 Stream States: ... half closed (local) ... PRIORITY frames received in this state are used to reprioritize streams that depend on the current stream." 2) "6.3 Priority ... Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream." I don't have alternate wording proposals because I'm not exactly sure what those sentences are trying to say. Note that I'm only talking about "current stream" in the singular. I see no confusion with the use of "current streams" (plural) in "6.9.2 Initial Flow Control Window Size".
"subject stream" or "identified stream" would work effectively well. I'll take suggestions.
Both sound fine, but "identified stream" is already used often in the spec and "subject stream" is never used.
Excuse me for trolling this issue but I couldn't help but notice how evil the issue number is.

Revised text:
cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect  <ins> on the identified stream.  For a stream that is in the "half closed </ins> (remote)" or "closed" - state, this frame can only affect processing  <ins> of the identified stream and its dependent streams and not frame transmission on that stream. </ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent