Change:
Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.

Discussion:
2.2. <del> A UDP-to-TCP gateway MUST discard all Empty messages 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. </del> <ins> 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. </ins> 2.3.

requests and responses can be transferred in a block-wise fashion as defined in I-D.ietf-core-block. <del> Empty messages (Code 0.00) are ignored by the recipient (see also </del> <ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also </ins> sec-ping). 3.3.

Most CSM Options are useful mainly as initial messages in the connection. <del> Both capability and settings options are cumulative, i.e., a Capability and Settings message does not invalidate a previously made capability indication or setting even if that is not repeated, and a capability message without any option is a no-operation (and can be used as such).  An option that is given might override a previous value for the same option; the option defines how to handle this, if </del> <ins> Both capability and settings options are cumulative.  A Capability and Settings message does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no-operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if </ins> needed. <del> Default values given below for CSM Options are not default values for the option (this would mean that an empty Capability and Settings message would set the option back to its default value).  Instead they give the base value for the Capability and Setting before any Capability and Settings message sends a modified value. </del> <ins> Base values are listed below for CSM Options.  These are the values for the Capability and Setting before any Capability and Settings messages sends a modified value. These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty Capability and Settings message would result in the option being set to its default value. </ins> Capability and Settings messages are indicated by the 7.01 code (CSM).

The sender can use the Max-Message-Size elective option to indicate the maximum message size in bytes that it can receive. <del> As per Section 4.6 of RFC7252, the default value (and the value used </del> <ins> As per Section 4.6 of RFC7252, the base value (and the value used </ins> when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability.

4.4. <del> In CoAP over TCP, Empty messages can always be sent and will be ignored.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient (see also sec-ping).  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the