Original text:
9.6. <del> The header field (field.connection) provides a " </del>  <del> " connection option that a sender SHOULD send when it wishes to close the connection after the current request/response pair. </del>  <del> A client that sends a " </del>  <del> " connection option MUST NOT send further requests on that connection (after the one containing "close") and MUST close the connection after reading the final response message corresponding to this request. A server that receives a " " connection option MUST initiate a close of the connection (see below) after it sends the final response to the request that contained "close".  The server SHOULD send a "close" connection option in its final response on that connection.  The server MUST NOT process any further requests received on that connection. A server that sends a " " connection option MUST initiate a close of the connection (see below) after it sends the response containing "close".  The server MUST NOT process any further requests received on that connection. A client that receives a " " connection option MUST cease sending requests on that connection and close the connection after reading the response message containing the "close"; if additional pipelined requests had been sent on the connection, the client SHOULD NOT assume that they will be processed by the server. </del>  If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last

Reviewer comments:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Revised text:
9.6.  <ins> The "close" connection option is defined as a signal that the sender will close this connection after completion of the response.  A sender SHOULD send a </ins>  <ins> header field (field.connection) containing the close connection option when it intends to close a connection.  For example, </ins>  <ins> as a request header field indicates that this is the last request that the client will send on this connection, while in a response the same field indicates that the server is going to close this connection after the response message is complete. </ins>  <ins> Note that the field name "Close" is reserved, since using that name as a header field might conflict with the close connection option. A client that sends a close connection option MUST NOT send further requests on that connection (after the one containing the close) and MUST close the connection after reading the final response message corresponding to this request. A server that receives a close connection option MUST initiate closure of the connection (see below) after it sends the final response to the request that contained the close connection option. The server SHOULD send a close connection option in its final response on that connection.  The server MUST NOT process any further requests received on that connection. A server that sends a close connection option MUST initiate closure of the connection (see below) after it sends the response containing the close connection option.  The server MUST NOT process any further requests received on that connection. A client that receives a close connection option MUST cease sending requests on that connection and close the connection after reading the response message containing the close connection option; if additional pipelined requests had been sent on the connection, the client SHOULD NOT assume that they will be processed by the server. </ins> If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last