Code change:
3.4.2. <del> The creator of a stream can assign a priority for that stream. Priority is represented as a 31 bit integer.  0 represents the highest priority and 2 </del> <ins> The endpoint establishing a new stream can assign a priority for the stream.  Priority is represented as an unsigned 31-bit integer.  0 represents the highest priority and 2 </ins> -1 represents the lowest priority. <del> Senders and receivers SHOULD use best-effort to process streams in the order of highest priority to lowest priority. </del> <ins> The purpose of this value is to allow the initiating endpoint to request that frames for the stream be processed with higher priority relative to any other concurrently active streams.  That is, if an endpoint receives interleaved frames for multiple streams, the endpoint ought to make a best-effort attempt at processing frames for higher priority streams before processing those for lower priority streams. Explicitly setting the priority for a stream does not guarantee any particular processing order for the stream relative to any other stream.  Nor is there is any mechanism provided by which the initiator of a stream can force or require a receiving endpoint to process frames from one stream before processing frames from another. </ins> 3.4.3. <del> When one side of the stream sends a frame with the FINAL flag set, the stream is half-closed from that endpoint.  The sender of the FINAL flag MUST NOT send further frames on that stream.  When both sides have half-closed, the stream is closed. </del> <ins> When an endpoint sends a frame for a stream with the FINAL flag set, the stream is considered to be half-closed for that endpoint. Subsequent frames MUST NOT be sent by that endpoint for the half closed stream for the remaining duration of the HTTP/2.0 session. When both endpoints have sent frames with the FINAL flag set, the stream is considered to be fully closed. If an endpoint receives additional frames for a stream that was previously half-closed by the sending peer, the recipient MUST respond with a StreamErrorHandler of type STREAM_CLOSED. </ins> <del> Receivers of frames on a half-closed stream MUST handle them as a StreamErrorHandler of type STREAM_CLOSED. </del> <ins> An endpoint that has not yet half-closed a stream by sending the FINAL flag can continue sending frames on the stream. </ins> <del> It is not necessary to half-close a stream if no frames have been sent.  This allows an endpoint to create a unidirectional stream that does not require an explicit close from the peer that does not transmit frames.  Endpoints can avoid committing resources for streams until the first frame is received. </del> <ins> It is not necessary for an endpoint to half-close a stream for which it has not sent any frames.  This allows endpoints to utilize fully unidirectional streams that do not require explicit action or acknowledgement from the receiver. </ins> 3.4.4.

Related discussion:
text: 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.