Draft: draft-ietf-core-coap-tcp-tls

Commentary: Adapted changes from Hannes simplified message format section to indicate reuse of restricted CoAP over TCP format
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.
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 at a CoAP server that exposes a WebSocket
endpoint (arch-1).  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.
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.  This means it is necessary for the client to identify 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.
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.
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 unreachable.  Because the
WebSocket server is the only way to reach the CoAP server, the CoAP
proxy should be a Reverse Proxy.
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.
Before CoAP requests and responses are exchanged, a WebSocket
connection is established as defined in Section 4 of RFC6455.
handshake-example shows an example.
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.
Since the underlying TCP connection provides retransmissions and
deduplication, there is no need for the reliability mechanisms
provided by CoAP over UDP.  The "T" and "Message ID" fields in the
CoAP message header are elided.
Furthermore, since the CoAP version is negotiated during the
opening handshake, the "Ver" field is 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.
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 RFC6455.
The message format shown in ws-message-format is the same as the CoAP
over TCP message format (see tcp-message-format) with one
restriction.  The Length (Len) field MUST be set to zero because the
WebSockets frame contains the length.
The CoAP over TCP message format 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 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 block-wise fashion as
defined in I-D.ietf-core-block.
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.
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.
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.
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 MAY be empty on
transmission and MUST be ignored on reception.
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".
For the first configuration discussed in websockets-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".
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 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 CoAP.