Original text:
by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server. <del> For simplicity, a Payload Marker (0xFF) is shown in all examples for message formats: The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of RFC7252). </del> 3. The request/response interaction model of CoAP over TCP is the same introduces a length field with variable size. fig-frame shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which <del> includes the length information of variable size, shown here as an 8-bit length. </del>  4-bit unsigned integer.  A value between 0 and 12 directly indicates the length of the message in bytes starting with the The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of RFC7252). <del> The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases. </del>  For example: A CoAP message just containing a 2.03 code with the <del> token 7f and no options or payload would be encoded as shown in fig- frame2. </del>  The semantics of the other CoAP header fields are left unchanged. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined <del> in this document.  Any later, incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name. </del>  The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be <del> in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </del>  Release messages are indicated by the 7.04 code (Release). abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort <del> message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </del>  Abort messages are indicated by the 7.05 code (Abort). Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such <del> messages by sending an Abort message and otherwise ignoring the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </del>  5.7.

Reviewer comments:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)

Revised text:
by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server.  3. The request/response interaction model of CoAP over TCP is the same introduces a length field with variable size. fig-frame shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which  <ins> includes the length information of variable size. </ins> 4-bit unsigned integer.  A value between 0 and 12 directly indicates the length of the message in bytes starting with the The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of RFC7252).  <ins> For simplicity, a Payload Marker (0xFF) is shown in fig-frame; the Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of RFC7252).  (If present, the Payload Marker is included in the message length, which counts from the start of the Options field to the end of the Payload field.) </ins> For example: A CoAP message just containing a 2.03 code with the  <ins> token 7f and no options or payload is encoded as shown in fig-frame2. </ins> The semantics of the other CoAP header fields are left unchanged. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined  <ins> in this document. </ins> The WebSocket client includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be  <ins> in flight or responses outstanding when the sender decides to send a Release message.  The peer responding to the Release message SHOULD delay the closing of the connection until it has responded to all requests received by it before the Release message.  It also MAY wait for the responses to its own requests. </ins> Release messages are indicated by the 7.04 code (Release). abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort  <ins> message.  Messages may be in flight or responses outstanding when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </ins> Abort messages are indicated by the 7.05 code (Abort). Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such  <ins> messages by sending an Abort message and otherwise ignoring (not processing) the message.  No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. </ins> 5.7.