Change:
Layer Protocol Negotiation Extension" RFC7301 MUST be used to allow demultiplexing at the server-side. <del> 7. </del> <ins> 4.2. For the first configuration discussed in overview, this document defines two new URIs schemes that can be used for identifying CoAP resources and providing a means of locating these resources: "coap+ws" and "coap+wss". Similar to the "coap" and "coaps" schemes, the "coap+ws" and "coap+wss" schemes organize resources hierarchically under a CoAP origin server.  The key difference is that the server is potentially reachable on a WebSocket endpoint instead of a UDP endpoint. </ins> <del> This document defines how to convey CoAP over TCP and TLS.  CoAP RFC7252 makes use of DTLS 1.2 and this specification consequently uses TLS 1.2 RFC5246.  CoAP MUST NOT be used with older versions of TLS.  Guidelines for use of cipher suites and TLS extensions can be found in I-D.ietf-dice-profile. </del> <ins> The WebSocket endpoint is identified by a "ws" or "wss" URI that is composed of the authority part of the "coap+ws" or "coap+wss" URI, respectively, and the well-known path "/.well-known/coap" RFC5785. The path and query parts of a "coap+ws" or "coap+wss" URI identify a resource within the specified endpoint which can be operated on by the methods defined by the CoAP protocol. The syntax of the "coap+ws" and "coap+wss" URI schemes is specified below in Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty" and "query" are the same as in RFC3986. The port component is OPTIONAL; the default for "coap+ws" is port 80, while the default for "coap+wss" is port 443. Fragment identifiers are not part of the request URI and thus MUST NOT be transmitted in a WebSocket handshake or in the URI options of a CoAP request. 4.2.1. The steps for decomposing a "coap+ws" or "coap+wss" URI into CoAP options are the same as specified in Section 6.4 of RFC7252 with the following changes: The <scheme> component MUST be "coap+ws" or "coap+wss" when converted to ASCII lowercase. A Uri-Host Option MUST only be included in a request when the <host> component does not equal the uri-host component in the Host header field in the WebSocket handshake. A Uri-Port Option MUST only be included in a request if |port| does not equal the port component in the Host header field in the WebSocket handshake. The steps to construct a URI from a request's options are changed accordingly. 5. Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP over TLS.  The general TLS usage guidance in RFC7525 SHOULD be followed. Guidelines for use of cipher suites and TLS extensions can be found in I-D.ietf-dice-profile. </ins> TLS does not protect the TCP header.  This may, for example, allow an on-path adversary to terminate a TCP connection prematurely by spoofing a TCP reset message. <del> 8. </del> <ins> CoAP over WebSockets and CoAP over TLS-secured WebSockets do not introduce additional security issues beyond CoAP and DTLS-secured CoAP respectively RFC7252.  The security considerations of RFC6455 apply. </ins> <del> 8.1. </del> <ins> 6. 6.1. </ins> IANA is requested to assign the port number 5683 and the service name "coap+tcp", in accordance with RFC6335.

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