BLOCKED frame specification

Here's at least a starting point. Comments welcome.

6.x BLOCKED

The BLOCKED frame (type=0xPLACEHOLDER) conveys flow control and data
availability status useful in tuning and debugging flow control.

The BLOCKED frame contains no payload and does not define any flags.
Semantically the BLOCKED frame is used to indicate to a remote endpoint
that data subject to flow control was available to be sent, and that the
underlying transport was ready to send said data, but was prohibited from
sending said data due to either stream-level or connection-level flow
control windows being nonpositive. The specific flow control window
prohibiting the sending of said data is indicated in the stream id of the
BLOCKED frame. In the stream-level flow control blockage case, the frame's
stream identifier indicates the affected stream; otherwise the value "0"
indicates connection-level flow control blockage.

Endpoints MUST NOT send a successive BLOCKED frame on a given stream id
(including "0") unless the associated flow control window became positive
since the last time that a BLOCKED frame for that flow control window was
sent. This can happen only as a result of receiving a WINDOW_UPDATE frame
or appropriate SETTINGS frame increasing said flow control window. (TODO:
Add reference to appropriate sections of flow control spec?) (TODO: Add
GOAWAY-ENHANCE_YOUR_CALM usage here as appropriate behavior in this case?)

BLOCKED can be sent by a peer that has sent a frame bearing the END_STREAM
flag. This means that a receiver could receive a BLOCKED frame on a "half
closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an
error, see Section 5.1.