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

Commentary: Changes since  (  's earlier ones included ): 
 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 do n'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 . )
The Payload Marker indicates the start of the optional payload and is
absent for zero-length payloads (see Section 3 of RFC7252).
In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed.  For this purpose, CoAP over TCP
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
includes the length information of variable size, shown here as an
8-bit length.
In a stream oriented transport protocol such as TCP, a form of
message delimitation is needed.  For this purpose, CoAP over TCP
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
includes the length information of variable size.
The following figures show the message format for the 0-bit, 16-bit,
and the 32-bit variable length cases.
For example: A CoAP message just containing a 2.03 code with the
token 7f and no options or payload would be encoded as shown in fig-
frame2.
For example: A CoAP message just containing a 2.03 code with the
token 7f and no options or payload is encoded as shown in fig-frame2.
The WebSocket client MUST include the subprotocol name "coap" in the
list of protocols, which indicates support for the protocol defined
in this document.  Any later, incompatible versions of CoAP or CoAP
over WebSockets will use a different subprotocol name.
The WebSocket client MUST include the subprotocol name "coap" in the
list of protocols, which indicates support for the protocol defined
in this document.
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 (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
in flight when the sender decides to send a Release message.  The
general expectation is that these will still be processed.
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 (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
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.
An Abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly
release.  The sender shuts down the connection immediately after the
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
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.
An Abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly
release.  The sender shuts down the connection immediately after the
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
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.
For CoAP over reliable transports, the recipient rejects such
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.
For CoAP over reliable transports, the recipient rejects such
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.