Code change:
The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. <del> 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. </del> <ins> 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. </ins> 3.4. <del> 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. 3.5. 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. </del> <ins> 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. </ins> 4.

Related discussion:
text: URL 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 Length (Len) 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.