Code change:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Related discussion:
text: defined. A 31-bit stream identifier (see StreamCreation).  A value 0 is <del> reserved for frames that are directed at the session as a whole instead of a single stream. Frames contain between 0 and 65535 bytes of data. </del> <ins> reserved for frames that are associated with the session as a whole as opposed to an individual stream. </ins> Reserved bits in the frame header MUST be set to zero when sending and MUST be ignored when receiving frames, unless the semantics of the bit are known. <ins> The structure and content of the remaining frame data is entirely dependent on the frame type. </ins> 3.3.2. <del> A frame of the maximum size might be too large for implementations with limited resources to process.  Implementations MAY choose to support frames smaller than the maximum possible size.  However, implementations MUST be able to receive frames containing at least 8192 octets of data. </del> <ins> Implementatins with limited resources might not be capable of processing large frame sizes.  Such implementations MAY choose to place additional limits on the maximum frame size.  However, all implementations MUST be capable of receiving and processing frames containing at least 8192 octets of data. </ins> <del> An implementation MUST immediately close a stream if it is unable to process a frame related to that stream due to it exceeding a size limit.  The implementation MUST send a RST_STREAM containing FRAME_TOO_LARGE error code if the frame size limit is exceeded. </del> <ins> An implementation MUST terminate a stream immediately if it is unable to process a frame due it's size.  This is done by sending an RST_STREAM containing the FRAME_TOO_LARGE error code. </ins> 3.4. <del> Streams are independent sequences of bi-directional data divided into frames with several properties: </del> <ins> A "stream" is an independent, bi-directional sequence of frames exchanged between the client and server within an HTTP/2.0 session. Streams have several important characteristics: Streams can be established and used unilaterally or shared by either the client or server. </ins> <del> Streams can be created by either the client or server. </del> <ins> Streams can be rejected or cancelled by either endpoint. </ins> <del> Streams optionally carry a set of name-value header pairs. </del> <ins> Multiple types of frames can be sent by either endpoint within a single stream. </ins> <del> Streams can concurrently send data interleaved with other streams. </del> <ins> The order in which frames are sent within a stream is significant. Recipients are required to process frames in the order they are received. </ins> <del> Streams can be established and used unilaterally. </del> <ins> Streams optionally carry a set of name-value header pairs that are expressed within the headers block of HEADERS+PRIORITY, HEADERS, or PUSH_PROMISE frames. </ins> <del> Streams can be cancelled. </del> <ins> A single HTTP/2.0 session can contain multiple concurrently active streams, with either endpoint interleaving frames from multiple streams. </ins> 3.4.1. <del> Use of streams does not require negotiation.  A stream is not created, streams are used by sending a frame on the stream. </del> <ins> There is no coordination or shared action between the client and server required to create a stream.  Rather, new streams are established by sending a frame that references a previously unused stream identifier. </ins> <del> Streams are identified by a 31-bit numeric identifier.  Streams </del> <ins> All streams are identified by an unsigned 31-bit integer.  Streams </ins> initiated by a client use odd numbered stream identifiers; those initiated by the server use even numbered stream identifiers.  A <del> stream identifier of zero MUST NOT be used to create a new stream. The stream identifier of a new stream MUST be greater than all previously streams from that endpoint, unless the stream identifier was reserved (such as the promised stream identifier in a PUSH_PROMISE frame).  An endpoint that receives an unexpected stream identifier MUST handle it as a SessionErrorHandler of type PROTOCOL_ERROR. An endpoint MUST NOT create a stream if there are open streams that exceed the SETTINGS_MAX_CONCURRENT_STREAMS setting of its peer.  The maximum concurrent streams setting only applies to streams that an endpoint initiates: a client cannot initiate an odd numbered streams that exceed the setting provided by a server; a server cannot initiate more even numbered streams than permitted by the setting provided by the client.  Streams that are StreamHalfClose in any direction count toward this limit. A long-lived session can exhaust the available stream identifiers. An endpoint that is unable to create a new stream identifier can establish a new session for any new streams. </del> <ins> stream identifier of zero MUST NOT be used to establish a new stream. The identifier of a newly established stream MUST be numerically greater than all previously established streams from that endpoint within the HTTP/2.0 session, unless the identifier has been reserved using a PUSH_PROMISE frame.  An endpoint that receives an unexpected stream identifier MUST terminate the stream by responding with a SessionErrorHandler of type PROTOCOL_ERROR. A peer can limit the total number of concurrently active streams using the SETTINGS_MAX_CONCURRENT_STREAMS parameters within a SETTINGS frame.  The maximum concurrent streams setting is specific to each endpoint and applies only to the peer.  That is, clients specify the maximum number of concurrent streams the server can initiate, and servers specify the maximum number of concurrent streams the client can initiate.  Peer endpoints MUST NOT exceed this limit.  All concurrently active streams initiated by an endpoint, including streams that are StreamHalfClose in any direction, count toward that endpoint's limit. Stream identifiers cannot be reused within an HTTP/2.0 session. Accordingly, long-lived sessions can cause an endpoint to exhaust the available range of stream identifiers.  An endpoint that is unable to establish a new stream identifier can establish a new session for any new streams. </ins> An endpoint can request the early termination of an unwanted stream. Upon receipt of a frame, the receiver can terminate the corresponding