Original text:
message that on datagram transports is provided by the UDP/DTLS datagram layer. <del> TCP ensures reliable message transmission, so the CoAP over TCP messaging layer is not required to support acknowledgements or to </del>  detect duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format. 2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00) after processing at the message layer.  For Confirmable (CON), Non- Confirmable (NOM), and Acknowledgement (ACK) messages that are not Empty, their contents are repackaged into untyped messages. 2.3. </del> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). <del> 2.4. </del>  The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping The semantics of the other CoAP header fields are left unchanged. <del> 2.5. </del>  CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without

Reviewer comments:
Also updated one more case of "messaging layer" rather than "message layer of"
Consider either removing the UDP to TCP gateway section (URL) or merging into another section as an example. Given the differences in message format in UDP vs TCP, this is a topic that may be useful as an example, but left as an implementation detail of a gateway.
Good point - in Hannes's earlier draft, this was more of an example than a separate section - URL A UDP-to-TCP gateway will therefore discard all empty messages, such as empty ACKs (after operating on them at the message layer), and re- pack the contents of all non-empty CON, NON, or ACK messages (i.e., those ACK messages that have a piggy-backed response) into untyped messages (that happen to look like NON messages).

Revised text:
message that on datagram transports is provided by the UDP/DTLS datagram layer.  <ins> TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support acknowledgements or to </ins> detect duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format. 2.2.  Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort).  <ins> 2.3. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping The semantics of the other CoAP header fields are left unchanged.  <ins> 2.4. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without