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

Commentary: Performing an editorial pass during WGLC ... more commits to come ... 
 Is 7.00 reserved ? 
 Figure 2 : Comparison between CoAP over unreliable and reliable transport . Captions are not sentences and therefore do n't end in periods ( see Figure 1 ) . ( Comment not repeated further down . ) 
 2.1 . Messaging   , CoAP over TCP replaces most of the CoAP over UDP message layer ... s / CoAP over UDP message layer / message layer of CoAP over UDP/ 
 This document assumes that readers are familiar with the terms and concepts that are used in [ RFC6455 ] , [ RFC7252 ] , and [ RFC7641 ] . and RFC 7959 . 
 Cl.8.5 : The section references both [ RFC7595 ] and [ RFC4395 ] . RFC7595 obsoletes RFC4395 . 
 In Section 4.3.1 - It has the same restrictions as the Uri - Host Option ( Section 5.10 of [ RFC7252 ] ... This should be Section 5.10.1 
 The original text in This reference to 5.10 is no longer required because the table includes the format / length restrictions : unless " restrictions " is referring to the table elements for U = Unsafe , N = NoCacheKey , R = Repeatable which have not been used as properties for options in coap - tcp - tls . This is commented on in too . - can you comment ? 
 It is probably still useful to just point out that its value range was shaped after that of Uri - Host ( which inherits restrictions from RFC 3986 ) — it does not make sense to set a default value for Uri - Host here that is not a valid value for    ... 
 In , there was a dissent about whether a cocoa reference is needed . I 'm capturing the text . If cocoa is adopted as a working group item , then we can discuss adding before WGLC . informative : And from the Introduction : Some environments may also benefit from the ability of TCP to exchange larger payloads , such as firmware images , without application layer segmentation and to utilize the more sophisticated congestion control capabilities provided by many TCP implementations . 
 I am OK with your proposed resolution of adding a reference back into the document to CoCoA if it gets adopted as a WG item in the CORE WG sounds reasonable .
Some environments may also benefit from the ability of TCP to
exchange larger payloads, such as firmware images, without
application layer segmentation and to utilize the more sophisticated
congestion control capabilities provided by many TCP implementations.
Some environments may also benefit from the ability of TCP to
exchange larger payloads, such as firmware images, without
application layer segmentation and to utilize the more sophisticated
congestion control capabilities provided by many TCP implementations.
Note that there is ongoing work to add more elaborate congestion
control to CoAP (see I-D.ietf-core-cocoa).
This document assumes that readers are familiar with the terms and
concepts that are used in RFC6455, RFC7252, and RFC7641.
This document assumes that readers are familiar with the terms and
concepts that are used in RFC6455, RFC7252, RFC7641, and RFC7959.
The request/response interaction model of CoAP over TCP is the same
as CoAP over UDP.  The primary differences are in the message layer.
CoAP over UDP supports optional reliability by defining four types of
messages: Confirmable, Non-confirmable, Acknowledgement, and Reset.
TCP eliminates the need for the message layer to support reliability.
As a result, message types are not defined in CoAP over TCP.
Conceptually, CoAP over TCP replaces most of the CoAP over UDP
message layer with a framing mechanism on top of the byte stream
provided by TCP/TLS, conveying the length information for each
message that on datagram transports is provided by the UDP/DTLS
datagram layer.
TCP ensures reliable message transmission, so the CoAP over TCP
messaging layer is not required to support acknowledgements or
detection of 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.  All messages are also untyped.
The request/response interaction model of CoAP over TCP is the same
as CoAP over UDP.  The primary differences are in the message layer.
The message layer of CoAP over UDP supports optional reliability by
defining four Types of messages: Confirmable, Non-confirmable,
Acknowledgement, and Reset.  In addition, messages include a Message
ID to relate Acknowledgments to Confirmable messages and to detect
duplicate messages.
Conceptually, CoAP over TCP replaces most of the message layer of
CoAP over UDP with a framing mechanism on top of the byte stream
provided by TCP/TLS, conveying the length information for each
message that on datagram transports is provided by the UDP/DTLS
datagram layer.
TCP ensures reliable message transmission, so the CoAP over TCP
messaging layer is not required to support acknowledgements or to
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.
Since the underlying TCP connection provides retransmissions and
deduplication, there is no need for the reliability mechanisms
provided by CoAP over UDP.  The "T" and "Message ID" fields in the
CoAP message header are elided.
The "Ver" field is elided as well.  In constrast to the UDP
message layer for UDP and DTLS, the CoAP over TCP message layer
does not send a version number in each message.  If required in
the future, a new Capability and Settings Option (See negotiation)
could be defined to support version negotiation.
Since the underlying TCP connection provides retransmissions and
deduplication, there is no need for the reliability mechanisms
provided by CoAP over UDP.  The Type (T) and Message ID fields in
the CoAP message header are elided.
The Version (Vers) field is elided as well.  In constrast to the
UDP message layer for UDP and DTLS, the CoAP over TCP message
layer does not send a version number in each message.  If required
in the future, a new Capability and Settings Option (see
negotiation) could be defined to support version negotiation.
Signaling options are elective or critical as defined in
Section 5.4.1 of RFC7252).  If a Signaling option is critical and not
understood by the receiver, it MUST abort the connection (see sec-
abort).  If the option is understood but cannot be processed, the
option documents the behavior.
Signaling options are elective or critical as defined in
Section 5.4.1 of RFC7252.  If a Signaling option is critical and not
understood by the receiver, it MUST abort the connection (see sec-
abort).  If the option is understood but cannot be processed, the
option documents the behavior.
A client can use the Server-Name critical option to indicate the
default value for the Uri-Host Options in the messages that it sends
to the server.  It has the same restrictions as the Uri-Host Option
(Section 5.10 of RFC7252.
For TLS, the initial value for the Server-Name Option is given by the
SNI value.
For Websockets, the initial value for the Server-Name Option is given
by the HTTP Host header field.
The sender can use the Max-Message-Size elective option to indicate
the maximum message size in bytes that it can receive.
A client can use the critical Server-Name Option to indicate the
default value for the Uri-Host Options in the messages that it sends
to the server.  It has the same restrictions as the Uri-Host Option
(Section 5.10.1 of RFC7252).
For TLS, the base value for the Server-Name Option is given by the
SNI value.
For Websockets, the base value for the Server-Name Option is given by
the HTTP Host header field.
The sender can use the elective Max-Message-Size Option to indicate
the maximum message size in bytes that it can receive.
A sender can use the Block-wise Transfer elective Option to indicate
that it supports the block-wise transfer protocol RFC7959.
A sender can use the elective Block-wise Transfer Option to indicate
that it supports the block-wise transfer protocol RFC7959.
A Custody elective option can also be sent in a Ping message to
explicitly request the return of a Custody Option in the Pong
message.  A peer is always free to indicate that it has finished
processing all previous request/response messages by sending a
Custody Option in a Pong message.  A peer is also free NOT to send a
Custody Option in case it is still processing previous request/
response messages; however, it SHOULD delay its response to a Ping
with a Custody Option until it can also return one.
A release message indicates that the sender does not want to continue
maintaining the connection and opts for an orderly shutdown; the
details are in the options.  A diagnostic payload MAY be included.  A
release message will normally be replied to by the peer by closing
the TCP/TLS connection.  Messages may be in flight when the sender
decides to send a Release message.  The general expectation is that
these will still be processed.
The Bad-Server-Name elective option indicates that the default
indicated by the CSM Server-Name Option is unlikely to be useful for
this server.
The Alternative-Address elective option requests the peer to instead
open a connection of the same scheme as the present connection to the
alternative transport address given.  Its value is in the form
"authority" as defined in Section 3.2 of RFC3986.
The Hold-Off elective option indicates that the server is requesting
that the peer not reconnect to it for the number of seconds given in
the value.
A sender can also include an elective Custody Option in a Ping
message to explicitly request the inclusion of an elective Custody
Option in the corresponding Pong message.  The receiver SHOULD delay
its Pong message until it finishes processing all the request/
response messages received prior to the Ping message on the current
connection.
A Release message indicates that the sender does not want to continue
maintaining the connection and opts for an orderly shutdown.  The
details are in the options.  A diagnostic payload MAY be included.  A
peer will normally respond to a Release message by closing the TCP/
TLS connection.  Messages may be in flight when the sender decides to
send a Release message.  The general expectation is that these will
still be processed.
The elective Bad-Server-Name Option indicates that the default
indicated by the CSM Server-Name Option is unlikely to be useful for
this server.
The elective Alternative-Address Option requests the peer to instead
open a connection of the same scheme as the present connection to the
alternative transport address given.  Its value is in the form
"authority" as defined in Section 3.2 of RFC3986.
The elective Hold-Off Option indicates that the server is requesting
that the peer not reconnect to it for the number of seconds given in
the value.
The Bad-CSM-Option Option indicates that the sender is unable to
process the CSM option identified by its option number, e.g. when it
is critical and the option number is unknown by the sender, or when
there is parameter problem with the value of an elective option.
More detailed information SHOULD be included as a diagnostic payload.
The elective Bad-CSM-Option Option indicates that the sender is
unable to process the CSM option identified by its option number,
e.g. when it is critical and the option number is unknown by the
sender, or when there is parameter problem with the value of an
elective option.  More detailed information SHOULD be included as a
diagnostic payload.
RFC7252, Section 8 (Multicast CoAP) is not applicable to these
schemes.
Section 8 (Multicast CoAP) in RFC7252 is not applicable to these
schemes.
Each entry in the sub-registry must include the Signaling Code in the
range 7.01-7.31, its name, and a reference to its documentation.
Each entry in the sub-registry must include the Signaling Code in the
range 7.00-7.31, its name, and a reference to its documentation.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+ws".  The registration request complies
with RFC4395.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+ws".  The registration request complies
with RFC7595.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+wss".  The registration request
complies with RFC4395.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+wss".  The registration request
complies with RFC7595.