Draft: draft-ietf-core-coap-tcp-tls

Commentary: Consistent language for empty messages . Edits to Signaling section - including replacing Default Value in tables with   for clarity .
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.
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.
Empty messages (Code 0.00) are ignored by the recipient (see also
sec-ping).
Empty messages (Code 0.00) MUST be ignored by the recipient (see also
sec-ping).
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
needed.
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.
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
needed.
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.
As per Section 4.6 of RFC7252, the default value (and the value used
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.
As per Section 4.6 of RFC7252, the base value (and the value used
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.
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.
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.