Change:
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

Discussion:
<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

A response is sent back as defined in RFC7252, as illustrated in fig- untyped2 (derived from RFC7252, Figure 6). <del> 4. </del> <ins> EDITOR: These are "leftover" paragraphs from the original Overview section.  Keeping until I perform a complete editorial pass of the "roughed in" material. 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 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.1. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping

The semantics of the other CoAP header fields are left unchanged. <del> 4.1. One observation is that, over a reliable byte stream transport, the message size limitations defined in Section 4.6 of RFC7252 are no longer strictly necessary.  Consenting [[how: There is currently no defined way to arrive at this consent. --cabo]] implementations may want to interchange messages with payload sizes larger than 1024 bytes, potentially also obviating the need for the Block protocol I- D.ietf-core-block.  It must be noted that entirely getting rid of the block protocol is not a generally applicable solution, as: a UDP-to-TCP gateway may simply not have the context to convert a message with a Block option into the equivalent exchange without any use of a Block option; large messages might also cause undesired head-of-line blocking; the 2-byte message length field causes another, larger upper bound to the message length. I-D.bormann-core-block-bert proposes to extend the block-wise transfer protocol to allow for larger block sizes as are possible over TCP and TLS. </del> <ins> 2.2. </ins> <del> The general assumption is therefore that the block protocol will continue to be used over TCP, even if TCP-based applications occasionally do exchange messages with payload sizes larger than desirable in UDP. 5. </del> <ins> EDITOR: This is extremely similar to the WebSocket section of the same name. </ins> As CoAP exchanges messages asynchronously over the TCP connection, the client can send multiple requests without waiting for responses.

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

schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers. <del> 6.1. </del> <ins> 4.1.1. </ins> The semantics defined in RFC7252, Section 6.1, apply to this URI scheme, with the following changes:

server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.) <del> 6.2. </del> <ins> 4.1.2. </ins> The semantics defined in RFC7252, Section 6.2, apply to this URI scheme, with the following changes:

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.

443 (see also alpnpid of [RFCthis]}) <del> 8.2. </del> <ins> 6.2. </ins> This document registers two new URI schemes, namely "coap+tcp" and "coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over

IANA is requested to add these new URI schemes to the registry established with RFC7595. <del> 8.3. </del> <ins> 6.2.1. This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+ws".  The registration request complies with RFC4395. coap+ws Permanent Defined in Section N of [RFCthis] The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket Protocol. The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. None. See Section N of [RFCthis] IETF chair <chair@ietf.org> IESG <iesg@ietf.org> [RFCthis] 6.2.2. This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+wss".  The registration request complies with RFC4395. coap+wss Permanent Defined in Section N of [RFCthis] The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket Protocol secured with Transport Layer Security (TLS). The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. None. See Section N of [RFCthis] IETF chair <chair@ietf.org> IESG <iesg@ietf.org> [RFCthis] 6.3. IANA is requested to register the 'coap' well-known URI in the "Well- Known URIs" registry.  This registration request complies with RFC5785: coap IETF [RFCthis] None. 6.4. </ins> IANA is requested to assign the following value in the registry "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created

[RFCthis] <ins> 6.5. IANA is requested to register the WebSocket CoAP subprotocol under the "WebSocket Subprotocol Name Registry": coap Constrained Application Protocol (CoAP) [RFCthis] </ins>