Universitaet Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Zebra Technologies

820 W. Jackson Blvd. Suite 700 Chicago 60607 United States of America +1-847-634-6700 slemay@zebra.com

ARM Ltd.

110 Fulbourn Rd Cambridge CB1 9NJ Great Britain Hannes.tschofenig@gmx.net http://www.tschofenig.priv.at

Universitaet Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63905 hartke@tzi.org

Tampere University of Technology

Korkeakoulunkatu 10 Tampere FI-33720 Finland bilhanan.silverajan@tut.fi

Microsoft

One Microsoft Way Redmond 98052 United States of America brian.raymor@microsoft.com

Applications Area (app) CORE 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 support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7252 fixing an erratum in the URI syntax, RFC 7641 for use with the new transports, and RFC 7959 to enable the use of larger messages over a reliable transport.

The Constrained Application Protocol (CoAP) was designed for Internet of Things (IoT) deployments, assuming that UDP or Datagram Transport Layer Security (DTLS) 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. Emerging standards such as Lightweight Machine to Machine currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments in existing CoAP implementations and deployments. Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. To address these requirements, this document defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. For these cases, the reliability offered by the transport protocol subsumes the reliability functions of the message layer used for CoAP over UDP. (Note that both for a reliable transport and the CoAP over UDP message layer, the reliability offered is per transport hop: where proxies — see Sections 5.7 and 10 of — are involved, that layer’s reliability function does not extend end-to-end.) illustrates the layering:

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 . 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 (see ). 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. To allow IoT devices to better communicate in these demanding environments, CoAP needs to support different transport protocols, namely TCP , in some situations secured by TLS . CoAP applications running inside a web browser without access to connectivity other than HTTP and the WebSocket protocol may cross-proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross-proxy or transport them via the the WebSocket protocol, which provides two-way communication between a WebSocket client and a WebSocket server after upgrading an HTTP/1.1 connection. This document specifies how to access resources using CoAP requests and responses over the TCP, TLS and WebSocket protocols. This allows connectivity-limited applications to obtain end-to-end CoAP connectivity either by communicating CoAP directly with a CoAP server accessible over a TCP, TLS or WebSocket connection or via a CoAP intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. updates the “Observing Resources in the Constrained Application Protocol” specification for use with CoAP over reliable transports. is an extension to the CoAP protocol that enables CoAP clients to “observe” a resource on a CoAP server. (The CoAP client retrieves a representation of a resource and registers to be notified by the CoAP server when the representation is updated.) fixes an erratum on the URI scheme syntax in . defines semantics for a value 7 for the field “SZX” in a Block1 or Block2 option, updating .

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 . This document assumes that readers are familiar with the terms and concepts that are used in , , , and . The term “reliable transport” is used only to refer to transport protocols, such as TCP, which provide reliable and ordered delivery of a byte-stream. BERT extends to enable the use of larger messages over a reliable transport. A Block1 or Block2 option that includes an SZX value of 7. The payload of a CoAP message that is affected by a BERT Option in descriptive usage (see Section 2.1 of ). The peer that opens a reliable byte stream connection, i.e., the TCP active opener, TLS client, or WebSocket client. The peer that accepts the reliable byte stream connection opened by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server. For simplicity, a Payload Marker (0xFF) is shown in all examples for message formats:

The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of ).

The request/response interaction model of CoAP over TCP is the same as CoAP over UDP. The primary differences are in the message layer. The message layer of CoAP over UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgement, and Reset. In addition, messages include a Message ID to relate Acknowledgments to Confirmable messages and to detect duplicate messages.

Conceptually, CoAP over TCP replaces most of the message layer of CoAP over UDP with a framing mechanism on top of the byte-stream provided by TCP/TLS, conveying the length information for each message that on datagram transports is provided by the UDP/DTLS datagram layer. TCP ensures reliable message transmission, so the message layer of CoAP over TCP is not required to support acknowledgements or to detect duplicate messages. As a result, both the Type and Message ID fields are no longer required and are removed from the CoAP over TCP message format. illustrates the difference between CoAP over UDP and CoAP over reliable transport. The removed Type and Message ID fields are indicated by dashes.

| +------------------->| | | | | | ACK [0xbc90] | | (-------) [------] | | 2.05 Content | | 2.05 Content | | (Token 0x71) | | (Token 0x71) | | "22.5 C" | | "22.5 C" | |<-------------------+ |<-------------------+ | | | | CoAP over UDP CoAP over reliable transport ]]>

The CoAP message format defined in , as shown in , relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length information.

The CoAP over TCP message format is very similar to the format specified for CoAP over UDP. 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. The Type (T) and Message ID fields in the CoAP message header are elided. The Version (Vers) field is elided as well. In contrast to the message format of CoAP over UDP, the message format for CoAP over TCP does not include a version number. CoAP is defined in with a version number of 1. At this time, there is no known reason to support version numbers different from 1. If version negotiation needs to be addressed in the future, then Capabilities and Settings Messages (CSM see ) have been specifically designed to enable such a potential feature. In a stream oriented transport protocol such as TCP, a form of message delimitation is needed. For this purpose, CoAP over TCP introduces a length field with variable size. shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which includes the length information of variable size, shown here as an 8-bit length.

4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the message in bytes starting with the first bit of the Options field. Three values are reserved for special constructs: An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13. A 16-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 269. A 32-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 65805. The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of ). The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases.

For example: A CoAP message just containing a 2.03 code with the token 7f and no options or payload would be encoded as shown in .

0x01 TKL = 1 ___/ Code = 2.03 --> 0x43 Token = 0x7f ]]>

The semantics of the other CoAP header fields are left unchanged.

Once a connection is established, both endpoints MUST send a Capabilities and Settings message (CSM see ) as their first message on the connection. This message establishes the initial settings and capabilities for the endpoint, such as maximum message size or support for block-wise transfers. The absence of options in the CSM indicates that base values are assumed. To avoid a deadlock, the Connection Initiator MUST NOT wait for the Connection Acceptor to send its initial CSM message before sending its own initial CSM message. Conversely, the Connection Acceptor MAY wait for the Connection Initiator to send its initial CSM message before sending its own initial CSM message. To avoid unnecessary latency, a Connection Initiator MAY send additional messages without waiting to receive the Connection Acceptor’s CSM; however, it is important to note that the Connection Acceptor’s CSM might advertise capabilities that impact how the initiator is expected to communicate with the acceptor. For example, the acceptor CSM could advertise a Max-Message-Size option (see ) that is smaller than the base value (1152). Endpoints MUST treat a missing or invalid CSM as a connection error and abort the connection (see ). CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection. 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 (Connection Initiator) and the remote host (Connection Acceptor). If one side does not implement a CoAP server, an error response MUST be returned for all CoAP requests from the other side. The simplest approach is to always return 5.01 (Not Implemented). A more elaborate mock server could also return 4.xx responses such as 4.04 (Not Found) or 4.02 (Bad Option) where appropriate. Retransmission and deduplication of messages is provided by the TCP protocol.

Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. This provides a basic keep-alive function that can refresh NAT bindings. If a CoAP 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), it can send a CoAP Ping Signaling message (see ) to test the connection and verify that the CoAP server is responsive. When the underlying TCP connection is closed or reset, the signaling state and any observation state (see ) associated with the reliable connection are removed. In flight messages may or may not be lost.

CoAP over WebSockets is intentionally similar to CoAP over TCP; therefore, this section only specifies the differences between the transports. CoAP over WebSockets can be used in a number of configurations. The most basic configuration is a CoAP client retrieving or updating a CoAP resource located on a CoAP server that exposes a WebSocket endpoint (see ). The CoAP client acts as 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.

/ / \ CoAP | | Client \__/__/ <------------- \__\__/ Server | | | responses | | |___________| |___________| WebSocket =============> WebSocket Client Connection Server ]]>

The challenge with this configuration is how to identify a 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. and define how the “coap” and “coaps” URI schemes can be used to enable the client to identify both a WebSocket endpoint and the path and query of the CoAP resource within that endpoint. 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 (), an SMS endpoint (a.k.a. mobile phone), or even another WebSocket endpoint. The CoAP client specifies the resource to be updated or retrieved in the Proxy-Uri Option.

/ / \ CoAP / \ \ ---> / / \ CoAP | | Client \__/__/ <--- \__\__/ Proxy \__/__/ <--- \__\__/ Server | | | | | | | |___________| |___________| |___________| WebSocket ===> WebSocket UDP UDP Client Server Client Server ]]>

A third possible configuration is a CoAP server running inside a web browser (). 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 unreachable. Because the WebSocket server is the only way to reach the CoAP server, the CoAP proxy should be a reverse-proxy.

/ / \ CoAP / / \ ---> / \ \ CoAP | | Client \__/__/ <--- \__\__/ Proxy \__\__/ <--- \__/__/ Server | | | | | | | |___________| |___________| |___________| UDP UDP WebSocket <=== WebSocket Client Server Server Client ]]>

Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy.

Before CoAP requests and responses are exchanged, a WebSocket connection is established as defined in Section 4 of . 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 . The Host header field also indicates the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server.

Once a WebSocket connection is 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 . The message format shown in is the same as the CoAP over TCP message format (see ) with one change. The Length (Len) field MUST be set to zero because the WebSockets frame contains the length.

As with CoAP over TCP, the message format for CoAP over WebSockets 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. Requests and response messages can be fragmented as specified in Section 5.4 of , 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 block-wise fashion as defined in .

As with CoAP over TCP, both endpoints MUST send a Capabilities and Settings message (CSM see ) as their first message on the WebSocket connection. CoAP requests and responses are exchanged asynchronously over the WebSocket connection. 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. 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.

As with CoAP over TCP, a CoAP client can test the health of the CoAP over WebSocket connection by sending a CoAP Ping Signaling message (). WebSocket Ping and unsolicited Pong frames (Section 5.5 of ) SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted.

Signaling messages are introduced to allow peers to: Learn related characteristics, such as maximum message size for the connection Shut down the connection in an orderly fashion Provide diagnostic information when terminating a connection in response to a serious error condition Signaling is a third basic kind of message in CoAP, after requests and responses. Signaling messages share a common structure with the existing CoAP messages. There is a code, a token, options, and an optional payload. (See Section 3 of for the overall structure of the message format, option format, and option value format.)

A code in the 7.00-7.31 range indicates a Signaling message. Values in this range are assigned by the “CoAP Signaling Codes” sub-registry (see ). For each message, there is a sender and a peer receiving the message. Payloads in Signaling messages are diagnostic payloads as defined in Section 5.5.2 of ), unless otherwise defined by a Signaling message option.

Option numbers for Signaling messages are specific to the message code. They do not share the number space with CoAP options for request/response messages or with Signaling messages using other codes. Option numbers are assigned by the “CoAP Signaling Option Numbers” sub-registry (see ). Signaling options are elective or critical as defined in Section 5.4.1 of . If a Signaling option is critical and not understood by the receiver, it MUST abort the connection (see ). If the option is understood but cannot be processed, the option documents the behavior.

Capabilities and Settings messages (CSM) are used for two purposes: Each capability option advertises one capability of the sender to the recipient. Each setting option indicates a setting that will be applied by the sender. One CSM MUST be sent by both endpoints at the start of the connection. Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. Both capability and setting options are cumulative. A CSM does not invalidate a previously sent capability indication or setting even if it is not repeated. A capability message without any option is a no-operation (and can be used as such). An option that is sent might override a previous value for the same option. The option defines how to handle this case if needed. Base values are listed below for CSM Options. These are the values for the capability and setting before any Capabilities and Settings messages send a modified value. These are not default values for the option, as defined in Section 5.4.4 in . A default value would mean that an empty Capabilities and Settings message would result in the option being set to its default value. Capabilities and Settings messages are indicated by the 7.01 code (CSM).

The sender can use the elective Max-Message-Size Option to indicate the maximum message size in bytes that it can receive. # C R Applies to Name Format Length Base Value 2     CSM Max-Message-Size uint 0-4 1152 As per Section 4.6 of , the base value (and the value used when this option is not implemented) is 1152. The active value of the Max-Message-Size Option is replaced each time the option is sent with a modified value. Its starting value is its base value.

# C R Applies to Name Format Length Base Value 4     CSM Block-wise Transfer empty 0 (none) A sender can use the elective Block-wise Transfer Option to indicate that it supports the block-wise transfer protocol . If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not. An implementation that supports block-wise transfers SHOULD indicate the Block-wise Transfer Option. If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same or a different CSM message), the Block-wise Transfer Option also indicates support for BERT (see ). Subsequently, if the Max-Message-Size Option is indicated with a value equal to or less than 1152, BERT support is no longer indicated.

In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. This provides a basic keep-alive function. In contrast, Ping and Pong messages are a bidirectional exchange. Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical token in response. Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical. As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).

# C R Applies to Name Format Length Base Value 2     Ping, Pong Custody empty 0 (none) When responding to a Ping message, the receiver can include an elective Custody Option in the Pong message. This option indicates that the application has processed all the request/response messages received prior to the Ping message on the current connection. (Note that there is no definition of specific application semantics for “processed”, but there is an expectation that the receiver of a Pong Message with a Custody Option should be able to free buffers based on this indication.) A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody Option in the corresponding Pong message. In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/response messages received prior to the Ping message on the current connection.

A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of ) MAY be included. A peer will normally respond to a Release message by closing the TCP/TLS connection. Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed. Release messages are indicated by the 7.04 code (Release). Release messages can indicate one or more reasons using elective options. The following options are defined: # C R Applies to Name Format Length Base Value 2   x Release Alternative-Address string 1-255 (none) The elective Alternative-Address Option requests the peer to instead open a connection of the same scheme as the present connection to the alternative transport address given. Its value is in the form “authority” as defined in Section 3.2 of . The Alternative-Address Option is a repeatable option as defined in Section 5.4.5 of . When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses. # C R Applies to Name Format Length Base Value 4     Release Hold-Off uint 0-3 (none) The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in the value.

An Abort message indicates that the sender is unable to continue maintaining the connection and cannot even wait for an orderly release. The sender shuts down the connection immediately after the abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction). A diagnostic payload (see Section 5.5.2 of ) SHOULD be included in the Abort message. Messages may be in flight when the sender decides to send an Abort message. The general expectation is that these will NOT be processed. Abort messages are indicated by the 7.05 code (Abort). Abort messages can indicate one or more reasons using elective options. The following option is defined: # C R Applies to Name Format Length Base Value 2     Abort Bad-CSM-Option uint 0-2 (none) The elective Bad-CSM-Option Option indicates that the sender is unable to process the CSM option identified by its option number, e.g. when it is critical and the option number is unknown by the sender, or when there is parameter problem with the value of an elective option. More detailed information SHOULD be included as a diagnostic payload. For CoAP over UDP, messages which contain syntax violations are processed as message format errors. As described in Sections 4.2 and 4.3 of , such messages are rejected by sending a matching Reset message and otherwise ignoring the message. For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring the message. No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload.

An encoded example of a Ping message with a non-empty token is shown in .

0x01 TKL = 1 ___/ Code = 7.02 Ping --> 0xe2 Token = 0x42 ]]>

An encoded example of the corresponding Pong message is shown in .

0x01 TKL = 1 ___/ Code = 7.03 Pong --> 0xe3 Token = 0x42 ]]>

The message size restrictions defined in Section 4.6 of CoAP to avoid IP fragmentation are not necessary when CoAP is used over a reliable transport. While this suggests that the Block-wise transfer protocol is also no longer needed, it remains applicable for a number of cases: large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used 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 (it would need to convert the entire blockwise exchange from start to end into a single exchange) The ‘Block-wise Extension for Reliable Transport (BERT)’ extends the Block protocol to enable the use of larger messages over a reliable transport. The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a “BERT option”). SZX == 7 is a reserved value in . In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the capability to process BERT blocks. As with the basic Block protocol, the recipient of a CoAP request with a BERT option in control usage is allowed to respond with a different SZX value, e.g. to send a non-BERT block instead. In descriptive usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that the payload is also allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block). The recipient of a non-final BERT block (M=1) conceptually partitions the payload into a sequence of 1024-byte blocks and acts exactly as if it had received this sequence in conjunction with block numbers starting at, and sequentially increasing from, the block number given in the Block Option. In other words, the entire BERT block is positioned at the byte position that results from multiplying the block number with 1024. The position of further blocks to be transferred is indicated by incrementing the block number by the number of elements in this sequence (i.e., the size of the payload divided by 1024 bytes). As with SZX == 6, the recipient of a final BERT block (M=0) simply appends the payload at the byte position that is indicated by the block number multiplied with 1024. The following examples illustrate BERT options. A value of SZX == 7 is labeled as “BERT” or as “BERT(nnn)” to indicate a payload of size nnn. In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number (NUM), more bit (M), and block size (2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33 would be shown as 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128.

shows a GET request with a response that is split into three BERT blocks. The first response contains 3072 bytes of payload; the second, 5120; and the third, 4711. Note how the block number increments to move the position inside the response body forward.

| | | | <------ 2.05 Content, 2:0/1/BERT(3072) | | | | GET, /status, 2:3/0/BERT ------> | | | | <------ 2.05 Content, 2:3/1/BERT(5120) | | | | GET, /status, 2:8/0/BERT ------> | | | | <------ 2.05 Content, 2:8/0/BERT(4711) | ]]>

demonstrates a PUT exchange with BERT blocks.

| | | | <------ 2.31 Continue, 1:0/1/BERT | | | | PUT, /options, 1:8/1/BERT(16384) ------> | | | | <------ 2.31 Continue, 1:8/1/BERT | | | | PUT, /options, 1:24/0/BERT(5683) ------> | | | | <------ 2.04 Changed, 1:24/0/BERT | | | ]]>

CoAP over UDP defines the “coap” and “coaps” URI schemes. This document corrects an erratum in Sections 6.1 and 6.2 of and defines how to use the schemes with the new transports. Section 8 (Multicast CoAP) in is not applicable to these new transports. The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) . The definitions of “host”, “port”, “path-abempty”, “query”, and “fragment” are adopted from . The ABNF syntax defined in Sections 6.1 and 6.2 of for “coap” and “coaps” schemes lacks the fragment identifer. This specification updates the two rules in those sections as follows:

The “coap” URI scheme defined in Section 6.1 of can also be used to identify CoAP resources that are intended to be accessible using CoAP over TCP. The syntax defined in Section 6.1 of applies to this transport, with the following change: The port subcomponent indicates the TCP port at which the CoAP server is located. (If it is empty or not given, then the default port 5683 is assumed, as with UDP.)

The “coaps” URI scheme defined in Section 6.2 of can also be used to identify CoAP resources that are intended to be accessible using CoAP over TCP secured with TLS. The syntax defined in Section 6.2 of applies to this transport, with the following changes: The port subcomponent indicates the TCP port at which the TLS server for the CoAP Connection Acceptor is located. If it is empty or not given, then the default port 5684 is assumed. If a TLS server does not support the Application-Layer Protocol Negotiation Extension (ALPN) or wishes to accommodate TLS clients that do not support ALPN, it MAY offer a coaps endpoint on the default TCP port 5684. This endpoint MAY also be ALPN enabled. A TLS server MAY offer coaps endpoints on TCP ports other than 5684; these then MUST be ALPN enabled. For TCP ports other than port 5684, the TLS client MUST use the ALPN extension to advertise the “coap” protocol identifier (see ) in the list of protocols in its ClientHello. If the TCP server selects and returns the “coap” protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the TLS server either does not negotiate the ALPN extension or returns a no_application_protocol alert, the TLS client MUST close the connection. For TCP port 5684, a TLS client MAY use the ALPN extension to advertise the “coap” protocol identifier in the list of protocols in its ClientHello. If the TLS server selects and returns the “coap” protocol identifier using the ALPN extension in its ServerHello, then the connection succeeds. If the TLS server returns a no_application_protocol alert, then the TLS client MUST close the connection. If the TLS server does not negotiate the ALPN extension, then coaps over TCP is implicitly selected. For TCP port 5684, if the TLS client does not use the ALPN extension to negotiate the protocol, then coaps over TCP is implicitly selected.

The “coap” URI scheme defined in Section 6.1 of can also be used to identify CoAP resources that are intended to be accessible using CoAP over WebSockets. The WebSocket endpoint is identified by a “ws” URI that is composed of the authority part of the “coap” URI and the well-known path “/.well-known/coap” . The path and query parts of the “coap” URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP:

Note that the default port for “coap” is 5683, while the default port for “ws” is 80. Therefore, if the port given for “coap” is 80, the default port for “ws” can be used. If the port is not given for “coap”, then an explicit port number of 5683 needs to be given for “ws”.

The “coaps” URI scheme defined in Section 6.2 of can also be used to identify CoAP resources that are intended to be accessible using CoAP over WebSockets secured by TLS. The WebSocket endpoint is identified by a “wss” URI that is composed of the authority part of the “coaps” URI and the well-known path “/.well-known/coap” . The path and query parts of the “coaps” URI identify a resource within the specified endpoint which can be operated on by the methods defined by CoAP.

Note that the default port for “coaps” is 5684, while the default port for “wss” is 443. If the port given for “coap” is 443, the default port for “wss” can be used. If the port is not given for “coaps”, then an explicit port number of 5684 needs to be given for “wss”.

Except for the transports over WebSockets, CoAP over reliable transports maintains the property from Section 5.10.1 of : The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Unless otherwise noted, the default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. The default value of the Uri-Port Option is the destination TCP port. For CoAP over TLS, these default values are the same unless Server Name Indication (SNI) is negotiated. In this case, the default value of the Uri-Host Option in requests from the TLS client to the TLS server is the SNI host. For CoAP over WebSockets, the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server is indicated by the Host header field from the WebSocket handshake.

The steps are the same as specified in Section 6.4 of with minor changes. This step from :

is updated to:

The steps are the same as specified in Section 6.5 of with minor changes. This step from :

is updated to:

This step from :

is updated to:

As in the “Happy Eyeballs” approach to using IPv6 and IPv4 , an application may want to try out multiple transports for a given URI at the same time, e.g., DTLS over UDP and TLS over TCP. However, two important caveats need to be considered: Initiating multiple instances of the same exchange with the intention of using only one of the successful results is only safe for idempotent exchanges (see Section 5.1 of ). An important setback in using the UDP or DTLS over UDP transport through NATs and other middleboxes can be the quick loss of NAT bindings during idling periods . This will not be evident right on the initial exchange. After the initial exchange, or whenever important information is learned about which selection to prefer, an endpoint may want to cache this information; however, the information may become stale after the endpoint moves or the network changes. A cache timeout (possibly enhanced by movement detection) is advisable. Alternatively, or additionally, the choice of transport may be aided by configuration and resource directory information; the self-description of a node may also include target attributes for links given to resources there. Details of such attributes are out of scope for the present document; see for instance .

Security Challenges for the Internet of Things recommends: … it is essential that IoT protocol suites specify a mandatory to implement but optional to use security solution. This will ensure security is available in all implementations, but configurable to use when not necessary (e.g., in closed environment). … even if those features stretch the capabilities of such devices. A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate. Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see ).

The TLS usage guidance in applies, including the guidance about cipher suites in that document that are derived from the mandatory to implement (MTI) cipher suites defined in . (Note that this selection caters for the device-to-cloud use case of CoAP over TLS more than for any use within a back-end environment, where the standard TLS 1.2 cipher suites or the more recent ones defined in are more appropriate.) During the provisioning phase, a CoAP device is provided with the security information that it needs, including keying materials, access control lists, and authorization servers. At the end of the provisioning phase, the device will be in one of four security modes: TLS is disabled. TLS is enabled. The guidance in Section 4.2 of applies. TLS is enabled. The guidance in Section 4.3 of applies. TLS is enabled. The guidance in Section 4.4 of applies. The “NoSec” mode is optional-to-implement. The system simply sends the packets over normal TCP which is indicated by the “coap” scheme and the TCP CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. “PreSharedKey”, “RawPublicKey”, or “Certificate” is mandatory-to-implement for the TLS binding depending on the credential type used with the device. These security modes are achieved using TLS and are indicated by the “coaps” scheme and TLS-secured CoAP default port.

A CoAP client requesting a resource identified by a “coaps” URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a “wss” URI. This is described in . The client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.1 of applies. When a CoAP server exposes resources identified by a “coaps” URI, the guidance in Section 4.4 of applies towards mandatory-to-implement TLS functionality for certificates. For the server-side requirements in accepting incoming connections over a HTTPS (HTTP-over-TLS) port, the guidance in Section 4.2 of applies. Note that this formally inherits the mandatory to implement cipher suites defined in . However, modern usually browsers implement more recent cipher suites that then are automatically picked up via the JavaScript WebSocket API. WebSocket Servers that provide Secure CoAP over WebSockets for the browser use case will need to follow the browser preferences and MUST follow .

The security considerations of apply. For CoAP over WebSockets and CoAP over TLS-secured WebSockets, the security considerations of also apply.

The guidance given by an Alternative-Address Option cannot be followed blindly. In particular, a peer MUST NOT assume that a successful connection to the Alternative-Address inherits all the security properties of the current connection.

IANA is requested to create a third sub-registry for values of the Code field in the CoAP header (Section 12.1 of ). The name of this sub-registry is “CoAP Signaling Codes”. Each entry in the sub-registry must include the Signaling Code in the range 7.00-7.31, its name, and a reference to its documentation. Initial entries in this sub-registry are as follows: Code Name Reference 7.01 CSM [RFCthis] 7.02 Ping [RFCthis] 7.03 Pong [RFCthis] 7.04 Release [RFCthis] 7.05 Abort [RFCthis] All other Signaling Codes are Unassigned. The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in .

IANA is requested to create a sub-registry for Options Numbers used in CoAP signaling options within the “CoRE Parameters” registry. The name of this sub-registry is “CoAP Signaling Option Numbers”. Each entry in the sub-registry must include one or more of the codes in the Signaling Codes subregistry (), the option number, the name of the option, and a reference to the option’s documentation. Initial entries in this sub-registry are as follows: Applies to Number Name Reference 7.01 2 Max-Message-Size [RFCthis] 7.01 4 Block-wise-Transfer [RFCthis] 7.02, 7.03 2 Custody [RFCthis] 7.04 2 Alternative-Address [RFCthis] 7.04 4 Hold-Off [RFCthis] 7.05 2 Bad-CSM-Option [RFCthis] The IANA policy for future additions to this sub-registry is based on number ranges for the option numbers, analogous to the policy defined in Section 12.2 of . The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following properties: Whether the option is critical or elective, as determined by the Option Number. Whether the option is repeatable. The format and length of the option’s value. The base value for the option, if any.

IANA is requested to assign the port number 5683 and the service name “coap”, in accordance with . coap tcp IESG <iesg@ietf.org> IETF Chair <chair@ietf.org> Constrained Application Protocol (CoAP) [RFCthis] 5683

IANA is requested to assign the port number 5684 and the service name “coaps+tcp”, in accordance with . The port number is requested also to address the exceptional case of TLS implementations that do not support the “Application-Layer Protocol Negotiation Extension” . coaps tcp IESG <iesg@ietf.org> IETF Chair <chair@ietf.org> Constrained Application Protocol (CoAP) , [RFCthis] 5684

IANA is requested to register the ‘coap’ well-known URI in the “Well-Known URIs” registry. This registration request complies with : coap IETF [RFCthis] None.

IANA is requested to assign the following value in the registry “Application Layer Protocol Negotiation (ALPN) Protocol IDs” created by . The “coap” string identifies CoAP when used over TLS. CoAP 0x63 0x6f 0x61 0x70 (“coap”) [RFCthis]

IANA is requested to register the WebSocket CoAP subprotocol under the “WebSocket Subprotocol Name Registry”: coap Constrained Application Protocol (CoAP) [RFCthis]

IANA is requested to add [RFCthis] to the references for the following entries registered by in the “CoAP Option Numbers” sub-registry defined by : Number Name Reference 23 Block2 RFC 7959, [RFCthis] 27 Block1 RFC 7959, [RFCthis]

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs, specifically for the "http" and "https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes. The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines some simple advanced CoRE Congestion Control mechanisms, Simple CoCoA. It is making use of input from simulations and experiments in real networks. This document defines Object Security of CoAP (OSCOAP), a method for application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding. OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this document. In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. Open Mobile Alliance Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

In this appendix, “client” and “server” refer to the CoAP client and CoAP server.

When using the Observe Option with CoAP over UDP, notifications from the server set the option value to an increasing sequence number for reordering detection on the client since messages can arrive in a different order than they were sent. This sequence number is not required for CoAP over reliable transports since the TCP protocol ensures reliable and ordered delivery of messages. The value of the Observe Option in 2.xx notifications MAY be empty on transmission and MUST be ignored on reception.

For CoAP over UDP, server notifications to the client can be confirmable or non-confirmable. A confirmable message requires the client to either respond with an acknowledgement message or a reset message. An acknowledgement message indicates that the client is alive and wishes to receive further notifications. A reset message indicates that the client does not recognize the token which causes the server to remove the associated entry from the list of observers. Since TCP eliminates the need for the message layer to support reliability, CoAP over reliable transports does not support confirmable or non-confirmable message types. All notifications are delivered reliably to the client with positive acknowledgement of receipt occurring at the TCP level. If the client does not recognize the token in a notification, it MAY immediately abort the connection (see ).

For CoAP over UDP, if a client does not receive a notification for some time, it MAY send a new GET request with the same token as the original request to re-register its interest in a resource and verify that the server is still responsive. For CoAP over reliable transports, it is more efficient to check the health of the connection (and all its active observations) by sending a CoAP Ping Signaling message () rather than individual requests to confirm active observations.

For CoAP over UDP, a client that is no longer interested in receiving notifications can “forget” the observation and respond to the next notification from the server with a reset message to cancel the observation. For CoAP over reliable transports, a client MUST explicitly deregister by issuing a GET request that has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister). If the client observes one or more resources over a reliable transport, then the CoAP server (or intermediary in the role of the CoAP server) MUST remove all entries associated with the client endpoint from the lists of observers when the connection is either closed or times out.

This section gives examples for the first two configurations discussed in . An example of the process followed by a CoAP client to retrieve the representation of a resource identified by a “coap” URI might be as follows. below illustrates the WebSocket and CoAP messages exchanged in detail. The CoAP client obtains the URI <coap://example.org/sensors/temperature?u=Cel>, for example, from a resource representation that it retrieved previously. It establishes a WebSocket connection to the endpoint URI composed of the authority “example.org” and the well-known path “/.well-known/coap”, <ws://example.org/.well-known/coap>. It sends a single-frame, masked, binary message containing a CoAP request. The request indicates the target resource with the Uri-Path (“sensors”, “temperature”) and Uri-Query (“u=Cel”) options. It waits for the server to return a response. The CoAP client uses the connection for further requests, or the connection is closed.

| GET /.well-known/coap HTTP/1.1 | | Host: example.org | | Upgrade: websocket | | Connection: Upgrade | | Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== | | Sec-WebSocket-Protocol: coap | | Sec-WebSocket-Version: 13 | | |<=========+ HTTP/1.1 101 Switching Protocols | | Upgrade: websocket | | Connection: Upgrade | | Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= | | Sec-WebSocket-Protocol: coap | | | | +--------->| Binary frame (opcode=%x2, FIN=1, MASK=1) | | +-------------------------+ | | | GET | | | | Token: 0x53 | | | | Uri-Path: "sensors" | | | | Uri-Path: "temperature" | | | | Uri-Query: "u=Cel" | | | +-------------------------+ | | |<---------+ Binary frame (opcode=%x2, FIN=1, MASK=0) | | +-------------------------+ | | | 2.05 Content | | | | Token: 0x53 | | | | Payload: "22.3 Cel" | | | +-------------------------+ : : : : | | +--------->| Close frame (opcode=%x8, FIN=1, MASK=1) | | |<---------+ Close frame (opcode=%x8, FIN=1, MASK=0) | | ]]>

shows how a CoAP client uses a CoAP forward proxy with a WebSocket endpoint to retrieve the representation of the resource “coap://[2001:db8::1]/”. The use of the forward proxy and the address of the WebSocket endpoint are determined by the client from local configuration rules. The request URI is specified in the Proxy-Uri Option. Since the request URI uses the “coap” URI scheme, the proxy fulfills the request by issuing a Confirmable GET request over UDP to the CoAP server and returning the response over the WebSocket connection to the client.

| | Binary frame (opcode=%x2, FIN=1, MASK=1) | | | +------------------------------------+ | | | | GET | | | | | Token: 0x7d | | | | | Proxy-Uri: "coap://[2001:db8::1]/" | | | | +------------------------------------+ | | | | +--------->| CoAP message (Ver=1, T=Con, MID=0x8f54) | | | +------------------------------------+ | | | | GET | | | | | Token: 0x0a15 | | | | +------------------------------------+ | | | | |<---------+ CoAP message (Ver=1, T=Ack, MID=0x8f54) | | | +------------------------------------+ | | | | 2.05 Content | | | | | Token: 0x0a15 | | | | | Payload: "ready" | | | | +------------------------------------+ | | | |<---------+ | Binary frame (opcode=%x2, FIN=1, MASK=0) | | | +------------------------------------+ | | | | 2.05 Content | | | | | Token: 0x7d | | | | | Payload: "ready" | | | | +------------------------------------+ | | | ]]>

The RFC Editor is requested to remove this section at publication.

Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann-core-block-bert-01 Merged draft-bormann-core-coap-sig-02

Editorial updates Added mandatory exchange of Capabilities and Settings messages after connecting Added support for coaps+tcp port 5684 and more details on Application-Layer Protocol Negotiation (ALPN) Added guidance on CoAP Signaling Ping-Pong versus WebSocket Ping-Pong Updated references and requirements for TLS security considerations

Updated references Added Appendix: Updates to RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) Updated Capability and Settings Message (CSM) exchange in the Opening Handshake to allow initiator to send messages before receiving acceptor CSM

Addressed feedback from Working Group Last Call Added Securing CoAP section and informative reference to OSCOAP Removed the Server-Name and Bad-Server-Name Options Clarified the Capability and Settings Message (CSM) exchange Updated Pong response requirements Added Connection Initiator and Connection Acceptor terminology where appropriate Updated LWM2M 1.0 informative reference

Addressed feedback from second Working Group Last Call

Addressed feedback from IETF Last Call Addressed feedback from ARTART review Addressed feedback from GENART review Addressed feedback from TSVART review Added fragment identifiers to URI schemes Added “Updates RFC7959” for BERT Added “Updates RFC6455” to extend well-known URI mechanism to ws and wss Clarified well-known URI mechanism use for all URI schemes Changed NoSec to optional-to-implement

Reverted “Updates RFC6455” to extend well-known URI mechanism to ws and wss; point to instead Don’t use port 443 as the default port for coaps+tcp Remove coap+tt and coaps+tt URI schemes (where tt is tcp or ws); map everything to coap/coaps

We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster, Matthias Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Goran Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu Wei for their feedback. Last-call reviews from Mark Nottingham and Yoshifumi Nishida as well as several IESG reviewers provided extensive comments; from the IESG, we would like to specifically call out Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kühlewind, and the responsible AD Alexey Melnikov.