Change:
<del> A TCP and TLS Transport for the Constrained Application Protocol (CoAP) </del> <ins> CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets </ins> draft-ietf-core-coap-tcp-tls-latest Abstract <del> The Hypertext Transfer Protocol (HTTP) was designed with TCP as the underlying transport protocol.  The Constrained Application Protocol (CoAP), while inspired by HTTP, has been defined to make use of UDP instead of TCP.  Therefore, reliable delivery and a simple congestion control and flow control mechanism are provided by the message layer of the CoAP protocol. </del> <ins> The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of the CoAP over UDP protocol includes services for reliable delivery, simple congestion control, and flow control. </ins> <del> A number of environments benefit from the use of CoAP directly over a reliable byte stream such as TCP, which already provides these services.  This document defines the use of CoAP over TCP as well as CoAP over TLS. </del> <ins> Some environments would benefit from the availability of CoAP over a reliable transport such as TCP or WebSockets, which already provides such services.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. </ins> 1. The RFC7252 was designed for Internet of Things (IoT) deployments, <del> assuming that UDP can be used unimpeded -- UDP RFC0768, or DTLS RFC6347 over UDP; it is a good choice for transferring small amounts of data across networks that follow the IP architecture.  Some CoAP deployments, however, may have to integrate well with existing enterprise infrastructure, where the use of UDP-based protocols may not be well-received or may even be blocked by firewalls. Middleboxes that are unaware of CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. Where NATs are still present, CoAP over TCP can also help with their traversal.  NATs often calculate expiration timers based on the transport layer protocol being used by application protocols.  Many NATs are built around the assumption that a transport layer protocol, such as TCP, gives them additional information about the session life cycle and keep TCP-based NAT bindings around for a longer period. UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter, as research confirms HomeGateway. </del> <ins> assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used unimpeded.  UDP is a good choice for transferring small amounts of data across networks that follow the IP architecture. Some CoAP deployments need to integrate well with existing enterprise infrastructures, where UDP-based protocols may not be well-received or may even be blocked by firewalls.  Middleboxes that are unaware of CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. To address such environments, this document defines additional bindings for CoAP, including TCP, TLS, and WebSockets. Where NATs are present, CoAP over TCP can help with their traversal. NATs often calculate expiration timers based on the transport layer protocol being used by application protocols.  Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport layer protocol, such as TCP, offers additional information about the session life cycle.  UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter, as confirmed by research HomeGateway. </ins> Some environments may also benefit from the ability of TCP to exchange larger payloads (such as firmware images) without application layer segmentation and to utilize the more sophisticated congestion control capabilities provided by many TCP implementations. (Note that there is ongoing work to add more elaborate congestion control to CoAP as well, see I-D.bormann-core-cocoa.) <del> Finally, CoAP may be integrated into a Web environment where the front-end uses CoAP from IoT devices to a cloud infrastructure but the CoAP messages are then transported in TCP between the back-end services.  A TCP-to-UDP gateway can be used at the cloud boundary to talk to the UDP-based IoT. </del> <ins> CoAP may be integrated into a Web environment where the front-end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services.  A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device. </ins> To make IoT devices work smoothly in these demanding environments, CoAP needs to make use of a different transport protocol, namely TCP RFC0793, in some situations secured by TLS RFC5246. <del> Conceptually, the CoAP over TCP/TLS specification replaces most of CoAP's message layer by a new message adapter on top of TCP or TLS that does provides a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information about each CoAP message that on datagram transports is provided by the datagram layer below (UDP, DTLS). The message adapter also adds a way to use signaling messages to perform various housekeeping operations on the TCP, see [I-D.bormann- core-signaling]. When CoAP is used over TLS then some of the housekeeping features are already available with the TLS Handshake protocol; less new functionality is then required. Modifications to CoAP beyond the replacement of the message layer (e.g., to introduce further optimizations) are intentionally avoided. 2. </del> <ins> Some corporate networks only allow Internet access via a HTTP proxy. In this case, the best transport for CoAP would be the RFC6455.  The WebSocket protocol provides two-way communication between a client and a server after upgrading an RFC7230 connection and may be available in an environment that blocks CoAP over UDP.  Another scenario for CoAP over WebSockets is a CoAP application running inside a web browser without access to connectivity other than HTTP and WebSockets. This document specifies how to access resources using CoAP requests and responses over the WebSocket Protocol.  This allows connectivity- limited applications to obtain end-to-end CoAP connectivity either by communicating CoAP directly with a CoAP server accessible over a WebSocket Connection or via a CoAP intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. 1.1. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> 3. </del> <ins> This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252. 2. </ins> The interaction model of CoAP over TCP is very similar to the one for CoAP over UDP, with the key difference that using TCP voids the need

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