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

Commentary: CoAP over WebSockets The following now seems unrelated : Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint . Depending on what transports are available Figure 12 : CoAP Client ( UDP client ) accesses sleepy CoAP Server ( WebSocket client ) via a CoAP proxy ( UDP server / WebSocket server ) s / sleepy// ( There is no mention of sleepiness here . ) CoAP over WebSockets is intentionally very similar to CoAP over UDP . Therefore , instead of presenting CoAP over WebSockets as a new protocol , this document specifies it as a series of deltas from [ RFC7252 ] . Probably best to delete that paragraph -- it is true not only for WS , but also for TCP . So why only here ? 3.1 . Opening Handshake Hmm , the title is confusing . WS also uses the same opening handshake as 2.3 . The parts that relate to both TCP / TLS and WS / S need to be factored out . 3.2 . Message Format The message format shown in Figure 14 is the same as the CoAP over TCP message format ( see Section 2.4 ) with one restriction . The  (  ) field MUST be set to zero because the WebSockets frame already contains the length . s / restriction / change/. The CoAP over TCP message format eliminates the Version field defined in CoAP over UDP . If CoAP version negotiation is required in the future , CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake . This paragraph is a bit weird . Maybe : As with CoAP over TCP , the message format for CoAP over Websockets eliminates the Version field defined in CoAP over UDP . If CoAP Empty messages ( Code 0.00 ) MUST be ignored by the recipient ( see also Section 4.4 ) . Why are we saying this here and not in Section 2 ? Factor out . 3.3 . Message Transmission Similar as with CoAP over TCP , Retransmission and deduplication of messages is provided by the WebSocket protocol . CoAP over WebSockets therefore does not make a distinction between Confirmable or Non - Confirmable messages , and does not provide Acknowledgement or Reset messages . 3.4 . Connection Health There is no way to retransmit a request without creating a new one . Re - registering interest in a resource is permitted , but entirely unnecessary . ( See the discussion we already had . ) [     reference is 
 Closing the Connection Does this mean , only the client must cancel the requests ? Or should the server do this also ? Then a clarfication may be useful . 
 The original - - was specific to Observe : ~ All updates to Observe are now captured in a single place - Appendix A. This specific case is in At this point , I think that Closing the Connection could simply be deleted because there are no specific changes required . 
 Let 's say a client has sent one or more requests to a server but has n't received any response yet , and/or is observing a resource at a server . If the client or the server closes the connection or if the connection goes down unexpectedly , then the client will never receive the responses or any further notifications . The client has to reconnect and send new requests . Neither the client nor the server needs to send anything to cancel active requests before closing the connection ; when a connection closes , all active requests are canceled automatically . The client should signal that to the code waiting for the responses , e.g. , by throwing an exception . The server should abort processing the requests or at least discard the responses once the requests have been processed . The server also should remove the client from the lists of observers ( at latest when it tries to send the next notification and it notices that the connection is down ) . 
 General - It 's not clear " how " mandatory the use of the CSM is . Clause 2.3 on TCP / TLS indicates that the CSM message must be sent at the start of the connection . Clause 3.1 on Websockets makes no mention of CSM messages . Clause 4.3 indicates that the CSM MUST be sent at the start of the connection also and makes no distinction between TCP / TLS and Websockets . Clause 2.3 also indicates that the connection must be aborted if the CSM is missing or invalid as the first message on the connection . Given the discussion about address changes does more information need to be provided what start of connection means ? 
 In the , the intent of this statement is unclear : There is no way to retransmit a request without creating a new one . Re - registering interest in a resource is permitted , but entirely unnecessary . 
 Response from   : In general , CoAP clients are not allowed to use a token while it is still in use . RFC 7641 defines an exception : a client is allowed to confirm its interest in receiving notifications for a resource by sending a request identical to the original registration request , including the token that is already in use . The above paragraph just says that this is also the case for CoAP over TCP / TLS / WebSockets , but points out that sending a Ping ( which checks the health of the connection and hence of all active observations ) is better than confirming the interest for all active observations individually . Response from Carsten : Yes , the text is much easier to understand in that context — in the old draft , it was clear that this talks about reregistering interest . So in the new text , we probably need to prefix a sentence like For use with UDP , RFC 7641 discusses ways to re - register interest in a resource to deal with the case that the server providing this resource might have lost the information about this interest . In CoAP over TCP , the framework of the current connection provides fate - sharing between the health of the connection and the health of the expression of interest . 
 After further review , I think that this note belongs in Appendix A with the other updates / guidance for Observe on reliable transports . Connection Health should limit its discussion to WebSocket specific changes - in this case , the use of the CoAP Ping Signaling message instead of WebSocket Ping / Pong .
Both the client and the server MUST send a Capabilities and Settings
message (CSM see csm) as its first message on the connection.  This
message establishes the initial settings and capabilities for the
endpoint such as maximum message size or support for block-wise
transfers.  The absence of options in the CSM indicates that base
values are assumed.
Once a connection is established, both the client and the server MUST
send a Capabilities and Settings message (CSM see csm) as its first
message on the connection.  This message establishes the initial
settings and capabilities for the endpoint such as maximum message
size or support for block-wise transfers.  The absence of options in
the CSM indicates that base values are assumed.
CoAP over WebSockets can be used in a number of configurations.  The
most basic configuration is a CoAP client retrieving or updating a
CoAP resource located at a CoAP server that exposes a WebSocket
endpoint (arch-1).  The CoAP client acts as the WebSocket client,
establishes a WebSocket connection, and sends a CoAP request, to
which the CoAP server returns a CoAP response.  The WebSocket
connection can be used for any number of requests.
Empty messages (Code 0.00) can always be sent and MUST be ignored by
the recipient.  This provides a basic keep-alive function that can
refresh NAT bindings.
If a client does not receive any response for some time after sending
a CoAP request (or, similarly, when a client observes a resource and
it does not receive any notification for some time), it can send a
CoAP Ping Signaling message (sec-ping) to test the connection and
verify that the server is responsive.
CoAP over WebSockets is intentionally similar to CoAP over TCP;
therefore, this section only specifies the differences between the
transports.
CoAP over WebSockets can be used in a number of configurations.  The
most basic configuration is a CoAP client retrieving or updating a
CoAP resource located on a CoAP server that exposes a WebSocket
endpoint (arch-1).  The CoAP client acts as the WebSocket client,
establishes a WebSocket connection, and sends a CoAP request, to
which the CoAP server returns a CoAP response.  The WebSocket
connection can be used for any number of requests.
CoAP over WebSockets is intentionally very similar to CoAP over UDP.
Therefore, instead of presenting CoAP over WebSockets as a new
protocol, this document specifies it as a series of deltas from
RFC7252.
The message format shown in ws-message-format is the same as the CoAP
over TCP message format (see tcp-message-format) with one
restriction.  The Length (Len) field MUST be set to zero because the
WebSockets frame contains the length.
The CoAP over TCP message format eliminates the Version field defined
in CoAP over UDP.  If CoAP version negotiation is required in the
future, CoAP over WebSockets can address the requirement by the
definition of a new subprotocol identifier that is negotiated during
the opening handshake.
The message format shown in ws-message-format is the same as the CoAP
over TCP message format (see tcp-message-format) with one change.
The Length (Len) field MUST be set to zero because the WebSockets
frame contains the length.
As with CoAP over TCP, the message format for CoAP over Websockets
eliminates the Version field defined in CoAP over UDP.  If CoAP
version negotiation is required in the future, CoAP over WebSockets
can address the requirement by the definition of a new subprotocol
identifier that is negotiated during the opening handshake.
Empty messages (Code 0.00) MUST be ignored by the recipient (see also
sec-ping).
As with CoAP over TCP, both the client and the server MUST send a
Capabilities and Settings message (CSM see csm) as its first message
on the WebSocket connection.
Retransmission and deduplication of messages is provided by the
WebSocket protocol.  CoAP over WebSockets therefore does not make a
distinction between Confirmable or Non-Confirmable messages, and does
not provide Acknowledgement or Reset messages.
When a client does not receive any response for some time after
sending a CoAP request (or, similarly, when a client observes a
resource and it does not receive any notification for some time), the
connection between the WebSocket client and the WebSocket server may
be lost or temporarily disrupted without the client being aware of
it.
To check the health of the WebSocket connection (and thereby of all
active requests, if any), a client can send a CoAP Ping Signaling
message (sec-ping).  WebSocket Ping and unsolicited Pong frames as
specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that
redundant maintenance traffic is not transmitted.
There is no way to retransmit a request without creating a new one.
Re-registering interest in a resource is permitted, but entirely
unnecessary.
The WebSocket connection is closed as specified in Section 7 of
RFC6455.
All requests for which the CoAP client has not received a response
yet are cancelled when the connection is closed.
As with CoAP over TCP, retransmission and deduplication of messages
is provided by the WebSocket protocol.  CoAP over WebSockets
therefore does not make a distinction between Confirmable or Non-
Confirmable messages, and does not provide Acknowledgement or Reset
messages.
As with CoAP over TCP, the client can test the health of the CoAP
over WebSocket connection by sending a CoAP Ping Signaling message
(sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5
of RFC6455) SHOULD NOT be used to ensure that redundant maintenance
traffic is not transmitted.
In CoAP over TCP, Empty messages (Code 0.00) can always be sent and
MUST be ignored by the recipient.  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 reliable transports, Empty messages (Code 0.00) can
always be sent and MUST be ignored by the recipient.  This provides a
basic keep-alive function.  In contrast, Ping and Pong messages are a
bidirectional exchange.