Change:
connection has no bearing on the meaning of the CoAP terms client and server. <del> 6. </del> <ins> 3. </ins> <del> CoAP RFC7252 defines the "coap" and "coaps" URI schemes for </del> <ins> CoAP over WebSockets can be used in a number of configurations.  The most basic configuration is a CoAP client seeking to retrieve or update a CoAP resource located at a CoAP server that exposes a WebSocket endpoint (arch-1).  The CoAP client takes the role of 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. The challenge in this configuration is to identify resource in the namespace of the CoAP server: When the WebSocket Protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the client can connect to any WebSocket endpoint.  This means it is necessary that the client is able to determine both the WebSocket endpoint (identified by a "ws" or "wss" URI) and the path and query of the CoAP resource within that endpoint from the same URI.  When the WebSocket Protocol is used from a web page, the choices are more limited RFC6454, but the challenge persists. uris proposes a new "coap+ws" URI scheme that identifies both a WebSocket endpoint and a resource within that endpoint as follows: Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint.  Depending on what transports are available to the proxy, it could forward the request to a CoAP server with a CoAP UDP endpoint (arch-2), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint.  The client specifies the resource to be updated or retrieved in the Proxy-URI Option. A third possible configuration is a CoAP server running inside a web browser (arch-3).  The web browser initially connects to a WebSocket endpoint and is then reachable through the WebSocket server.  When no connection exists, the CoAP server is not reachable; it therefore can be considered a I-D.dijk-core-sleepy-reqs.  Because the WebSocket server is the only way to reach the CoAP server, the CoAP proxy should be a Reverse Proxy. Further configurations are possible, including those where a WebSocket Connection is established through an HTTP proxy. CoAP over WebSockets is intentionally very similar to CoAP as defined over UDP.  Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. 3.1. Before CoAP requests and responses can be exchanged, a WebSocket Connection needs to be established as defined in Section 4 of RFC6455. handshake-example shows an example. 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 includes the hostname of the WebSocket server in the Host header field of its handshake as per RFC6455.  The Host header field also indicates the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server. 3.2. Once a WebSocket Connection has been established, CoAP requests and responses can be exchanged as WebSocket messages.  Since CoAP uses a binary message format, the messages are transmitted in binary data frames as specified in Sections 5 and 6 of RFC6455. The message format is very similar to the format specified for RFC7252.  The differences are as follows: Since the underlying TCP connection provides retransmissions and deduplication, there is no need for the reliability mechanisms provided by CoAP over UDP.  This means the "T" and "Message ID" fields in the CoAP message header can be elided. Furthermore, since the CoAP version is already negotiated during the opening handshake, the "Ver" field can be elided as well. The resulting message format is shown in ws-message-format.  The four most-significant bits of the first byte are reserved (R) and MUST be set to zero.  The remaining fields and structure are the same as defined in RFC7252. Requests and response messages can be fragmented as specified in Section 5.4 of RFC6455, though typically they are sent unfragmented as they tend to be small and fully buffered before transmission.  The WebSocket protocol does not provide means for multiplexing; if it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a blockwise fashion as defined in I-D.ietf-core-block. Messages MUST NOT be Empty (Code 0.00), i.e., messages always carry either a request or a response. 3.3. CoAP requests and responses are exchanged asynchronously over the WebSocket Connection, i.e., a CoAP client can send multiple requests without waiting for a response and the CoAP server can return responses in any order.  Responses MUST be returned over the same connection as the originating request.  Concurrent requests are differentiated by their Token, which is scoped locally to the connection. The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. 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. Since the WebSocket Protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. 3.4. 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), the client can send a Ping frame or an unsolicited Pong frame as specified in Section 5.5 of RFC6455.  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.  If the client observes one or more resources over the WebSocket Connection, then the CoAP server (or intermediary in the role of the CoAP server) MUST remove all entries associated with the client from the lists of observers when the connection is closed. 4. CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes for </ins> identifying CoAP resources and providing a means of locating the <del> resource.  RFC 7252 defines these resources for use with CoAP over UDP. </del> <ins> resource. 4.1. </ins> <del> The present specification introduces two new URI schemes, namely "coap+tcp" and "coaps+tcp".  The rules from Section 6 of RFC7252 apply to these two new URI schemes. </del> <ins> CoAP over TCP uses "coap_tcp" URI scheme.  CoAP over TLS uses the "coaps+tcp" scheme.  The rules from Section 6 of RFC7252 apply to both of these URI schemes. </ins> <del> RFC7252, Section 8 (Multicast CoAP), does not apply to the URI schemes defined in the present specification. </del> <ins> RFC7252, Section 8 (Multicast CoAP) is not applicable to these schemes. </ins> Resources made available via one of the "coap+tcp" or "coaps+tcp" schemes have no shared identity with the other scheme or with the

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with