CORE                                                          C. Bormann, Ed. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                                S. Lemay
Expires: October 23, 2016                           V. Solorzano Barboza January 9, 2017                              Zebra Technologies
                                                           H. Tschofenig
                                                                ARM Ltd.
                                                          April 21,
                                                               K. Hartke
                                                 Universitaet Bremen TZI
                                                           B. Silverajan
                                        Tampere University of Technology
                                                          B. Raymor, Ed.
                                                               Microsoft
                                                           July 08, 2016

A TCP and TLS Transport for the Constrained

 CoAP (Constrained Application Protocol (CoAP)
                    draft-ietf-core-coap-tcp-tls-02 Protocol) over TCP, TLS, and WebSockets
                    draft-ietf-core-coap-tcp-tls-03

Abstract

   The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
   underlying transport protocol.  The Constrained Application Protocol (CoAP), while although inspired by
   HTTP, has been defined was designed to make use of UDP instead of TCP.  Therefore, reliable delivery and a simple congestion
   control and flow control mechanism are provided by the  The message layer of
   the CoAP protocol.

   A number of over UDP protocol includes support for reliable delivery,
   simple congestion control, and flow control.

   Some environments benefit from the use availability of CoAP directly carried over a
   reliable byte stream transports such as TCP, which already provides these
   services. TCP or TLS.  This document defines outlines the
   changes required to use of CoAP over TCP as well as CoAP over TLS. TCP, TLS, and WebSockets
   transports.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 23, 2016. January 9, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  CoAP over TCP . . .   3
   3.  Constrained Application Protocol . . . . . . . . . . . . . .   3
   4.  Message Format . . . . . . .   5
     2.1.  Messaging Model . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Discussion
     2.2.  UDP-to-TCP gateways . . . . . . . . . . . . . . . . . . .   6
     2.3.  Message Format  . . . .   8
   5. . . . . . . . . . . . . . . . . .   6
     2.4.  Message Transmission  . . . . . . . . . . . . . . . . . .   9
   3.  CoAP over WebSockets  . .   8
   6.  CoAP URI . . . . . . . . . . . . . . . . . .  10
     3.1.  Opening Handshake . . . . . . . .   9
     6.1.  coap+tcp URI scheme . . . . . . . . . . . .  12
     3.2.  Message Format  . . . . . . .   9
     6.2.  coaps+tcp URI scheme . . . . . . . . . . . . . .  12
     3.3.  Message Transmission  . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . .  13
     3.4.  Connection Health . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . .  14
     3.5.  Closing the Connection  . . . . . .  10
     8.1.  Service Name and Port Number Registration . . . . . . . .  10
     8.2.  URI Schemes . . .  14
   4.  Signaling . . . . . . . . . . . . . . . . . . . .  11
     8.3.  ALPN Protocol ID . . . . . .  14
     4.1.  Signaling Codes . . . . . . . . . . . . . .  11
   9.  Acknowledgements . . . . . . .  15
     4.2.  Signaling Option Numbers  . . . . . . . . . . . . . . .  12
   10. References .  15
     4.3.  Capability and Settings Messages (CSM)  . . . . . . . . .  15
     4.4.  Ping and Pong Messages  . . . . . . . . . . . . . . .  12
     10.1.  Normative References . .  17
     4.5.  Release Messages  . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . .  18
     4.6.  Abort Messages  . . . . . . . . . . . . .  13
   Authors' Addresses . . . . . . . .  19
     4.7.  Capability and Settings examples  . . . . . . . . . . . .  20
   5.  Block-wise Transfer and Reliable Transports . . .  13

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] was designed
   for Internet of Things (IoT) deployments, 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 . . . . . .  21
     5.1.  Example: GET 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 BERT Blocks . . . . . . . . . . . . . .  22
     5.2.  Example: PUT with BERT Blocks . . . . . . . . . . . . . .  22
   6.  CoAP usage
   for IoT can make the use of UDP brittle, resulting in lost or
   malformed packets.

   Where NATs are still present, URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  23
     6.1.  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].

   Some environments may also benefit from 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].)

   Finally, TLS URIs  . . . . . . . . . . . . . . .  23
     6.2.  CoAP over WebSockets URIs . . . . . . . . . . . . . . . .  24
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
     7.1.  Signaling Messages  . . . . . . . . . . . . . . . . . . .  26
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     8.1.  Signaling Codes . . . . . . . . . . . . . . . . . . . . .  26
     8.2.  CoAP Signaling Option Numbers Registry  . . . . . . . . .  27
     8.3.  Service Name and Port Number Registration . . . . . . . .  27
     8.4.  URI Scheme Registration . . . . . . . . . . . . . . . . .  29
     8.5.  Well-Known URI Suffix Registration  . . . . . . . . . . .  31
     8.6.  ALPN Protocol ID  . . . . . . . . . . . . . . . . . . . .  31
     8.7.  WebSocket Subprotocol Registration  . . . . . . . . . . .  31
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  33
   Appendix A.  Negotiating Protocol Versions  . . . . . . . . . . .  34
   Appendix B.  CoAP over WebSocket Examples . . . . . . . . . . . .  34
   Appendix C.  Change Log . . . . . . . . . . . . . . . . . . . . .  38
     C.1.  Since draft-core-coap-tcp-tls-02  . . . . . . . . . . . .  38
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  38
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] was designed
   for Internet of Things (IoT) deployments, 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 how to transport
   CoAP over TCP, CoAP over TLS, and CoAP over WebSockets.  Figure 1
   illustrates the layering:

        +--------------------------------+
        |          Application           |
        +--------------------------------+
        +--------------------------------+
        |  Requests/Responses/Signaling  |  CoAP (RFC 7252) / This Document
        |--------------------------------|
        |        Message Framing         |  This Document
        +--------------------------------+
        |      Reliable Transport        |
        +--------------------------------+

            Figure 1: Layering of CoAP over Reliable Transports

   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 [HomeGateway].

   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.

   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 [RFC0793], in some situations secured by TLS [RFC5246].

   In addition, some corporate networks only allow Internet access via a
   HTTP proxy.  In this case, the best transport for CoAP would be the
   WebSocket Protocol [RFC6455].  The WebSocket protocol provides two-
   way communication between a client and a server after upgrading an
   HTTP/1.1 [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 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.

1.1.  Terminology

   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].

   This document assumes that readers are familiar with the terms and
   concepts that are used in [RFC6455] and [RFC7252].

   BERT Option:
      A Block1 or Block2 option that includes an SZX value of 7.

   BERT Block:
      The payload of a CoAP message that is affected by a BERT Option in
      descriptive usage (Section 2.1 of [I-D.ietf-core-block]).

2.  CoAP over TCP

   The request/response interaction model of CoAP over TCP is the same
   as CoAP over UDP.  The primary differences are in the message layer.
   CoAP over UDP supports optional reliability by defining four types of
   messages: Confirmable, Non-confirmable, Acknowledgement, and Reset.
   TCP eliminates the need for the message layer to support reliability.
   As a result, message types are not defined in CoAP over TCP.

2.1.  Messaging Model

   Conceptually, CoAP over TCP replaces most of the CoAP over UDP
   message layer 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 CoAP over TCP
   messaging layer is not required to support acknowledgements or
   detection of 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.  All messages are also untyped.

   Figure 2 illustrates the difference between CoAP over UDP and CoAP
   over reliable transport.  The removed Type (no type) and Message ID
   fields are indicated by dashes.

        Client                Server   Client                Server
           |                    |         |                    |
           |   CON [0xbc90]     |         | (-------) [------] |
           | GET /temperature   |         | GET /temperature   |
           |   (Token 0x71)     |         |   (Token 0x71)     |
           +------------------->|         +------------------->|
           |                    |         |                    |
           |   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

      Figure 2: Comparison between CoAP over unreliable and reliable
                                transport.

2.2.  UDP-to-TCP gateways

   A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00)
   after processing at the message layer.  For Confirmable (CON), Non-
   Confirmable (NOM), and Acknowledgement (ACK) messages that are not
   Empty, their contents are repackaged into untyped messages.

2.3.  Message Format

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver| T |  TKL  |      Code     |          Message ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: RFC 7252 defined CoAP Message Format.

   The CoAP over TCP message format is very similar to the format
   specified for CoAP over UDP.  The differences are as follows:

   o  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.

   o  The "Ver" field is elided as well.  In constrast to the UDP
      message layer for UDP and DTLS, the CoAP over TCP message layer
      does not send a version number in each message.  If required in
      the future, a new Capability and Settings Option (See Appendix A)
      could be defined to support version negotiation.

   o  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.  Figure 4 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.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=13 |  TKL  |Extended Length|      Code     | TKL bytes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 4: CoAP frame with 8-bit Extended Length field.

   Length (Len):  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:

      13:  An 8-bit unsigned integer (Extended Length) follows the
         initial byte and indicates the length of options/payload minus
         13.

      14:  A 16-bit unsigned integer (Extended Length) in network byte
         order follows the initial byte and indicates the length of
         options/payload minus 269.

      15:  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 on CoAP Options (see
   section 3.1 of [RFC7252]).

   The following figures show the message format for the 0-bit, 16-bit,
   and the 32-bit variable length cases.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Len  |  TKL  |      Code     | Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 5: CoAP message format without an Extended Length field.

   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
   Figure 6.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x01     |      0x43     |      0x7f     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            Figure 6: CoAP message with no options or payload.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=14 |  TKL  | Extended Length (16 bits)     |   Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7: CoAP message format with 16-bit Extended Length field.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=15 |  TKL  | Extended Length (32 bits)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |    Code       |  Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8: CoAP message format with 32-bit Extended Length field.

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

2.4.  Message Transmission

   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 and the remote host.

   Retransmission and deduplication of messages is provided by the TCP/
   TLS protocol.

   Since the TCP protocol provides ordered delivery of messages, the
   mechanism for reordering detection when observing resources [RFC7641]
   is not needed.  The value of the Observe Option in notifications MAY
   be empty on transmission and MUST be ignored on reception.

3.  CoAP over WebSockets

   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 (Figure 9).  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.

            ___________                            ___________
           |           |                          |           |
           |          _|___      requests      ___|_          |
           |   CoAP  /  \  \  ------------->  /  /  \  CoAP   |
           |  Client \__/__/  <-------------  \__\__/ Server  |
           |           |         responses        |           |
           |___________|                          |___________|
                   WebSocket  =============>  WebSocket
                     Client     Connection     Server

       Figure 9: CoAP Client (WebSocket client) accesses CoAP Server
                            (WebSocket 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.  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.

   Section 6.2 defines a new "coap+ws" URI scheme that identifies both a
   WebSocket endpoint and a resource within that endpoint as follows:

             coap+ws://example.org/sensors/temperature?u=Cel
                  \______  ______/\___________  ___________/
                         \/                   \/
                                            Uri-Path: "sensors"
       ws://example.org/.well-known/coap    Uri-Path: "temperature"
                                            Uri-Query: "u=Cel"

                    Figure 10: The "coap+ws" URI Scheme

   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 (Figure 11), 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.

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

    Figure 11: CoAP Client (WebSocket client) accesses CoAP Server (UDP
          server) via a CoAP proxy (WebSocket server/UDP client)

   A third possible configuration is a CoAP server running inside a web
   browser (Figure 12).  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  /  /  \ ---> /  \  \  CoAP   |
    |  Client \__/__/ <--- \__\__/ Proxy \__\__/ <--- \__/__/ Server  |
    |           |              |           |              |           |
    |___________|              |___________|              |___________|
               UDP            UDP      WebSocket <=== WebSocket
             Client          Server      Server        Client

      Figure 12: CoAP Client (UDP client) accesses sleepy CoAP Server
     (WebSocket client) via a CoAP proxy (UDP server/WebSocket server)

   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 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.  Opening Handshake

   Before CoAP requests and responses are exchanged, a WebSocket
   connection is established as defined in Section 4 of [RFC6455].
   Figure 13 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.

            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

                Figure 13: Example of an Opening Handshake

3.2.  Message Format

   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 Figure 14 is the same as the CoAP over
   TCP message format (see Section 2.3) with one restriction.  The
   Length (Len) field MUST be set to zero because the WebSockets frame
   contains the length.

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Len |  TKL  |      Code     |    Token (TKL bytes) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 1 1 1 1|    Payload (if any) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 14: CoAP Message Format over WebSockets

   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].

   Empty messages (Code 0.00) MUST be ignored by the recipient (see also
   Section 4.4).

3.3.  Message Transmission

   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.

   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 observing resources
   [RFC7641] is not needed.  The value of the Observe Option in
   notifications MAY be empty on transmission and MUST be ignored on
   reception.

3.4.  Connection Health

   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.  Closing the Connection

   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.  Signaling

   Signaling messages are introduced to allow peers to:

   o  Share characteristics such as maximum message size for the
      connection

   o  Shutdown the connection in an ordered fashion

   o  Terminate the 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 [RFC7252] for the overall structure, as adapted to
   the specific transport.)

4.1.  Signaling Codes

   A code in the 7.01-7.31 range indicates a Signaling message.  Values
   in this range are assigned by the "CoAP Signaling Codes" sub-registry
   (see Section 8.1).

   For each message, there is a sender and a peer receiving the message.

   Payloads in Signaling messages are diagnostic payloads (see
   Section 5.5.2 of [RFC7252]), unless otherwise defined by a Signaling
   message option.

4.2.  Signaling Option Numbers

   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 Section 8.2).

   Signaling options are elective or critical as defined in
   Section 5.4.1 of [RFC7252]).  If a Signaling option is critical and
   not understood by the receiver, it MUST abort the connection (see
   Section 4.6).  If the option is understood but cannot be processed,
   the option documents the behavior.

4.3.  Capability and Settings Messages (CSM)

   Capability and Settings messages (CSM) are used for two purposes:

   o  Each capability option advertises one capability of the sender to
      the recipient.

   o  Setting options indicate a setting that will be applied by the
      sender.

   Most CSM Options are useful mainly as initial messages in the
   connection.

   Both capability and settings options are cumulative.  A Capability
   and Settings message 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 Capability and Settings
   messages sends a modified value.

   These are not default values for the option as defined in
   Section 5.4.4 in [RFC7252].  A default value would mean that an empty
   Capability and Settings message would result in the option being set
   to its default value.

   Capability and Settings messages are indicated by the 7.01 code
   (CSM).

4.3.1.  Server-Name Setting Option

   +--------+------------+-------------+--------+--------+-------------+
   | Number | Applies to | Name        | Format | Length |  Base Value |
   +--------+------------+-------------+--------+--------+-------------+
   | 1      | CSM        | Server-Name | string |  1-255 | (see below) |
   +--------+------------+-------------+--------+--------+-------------+

   A client can use the Server-Name critical option to indicate the
   default value for the Uri-Host Options in the messages that it sends
   to the server.  It has the same restrictions as the Uri-Host Option
   (Section 5.10 of [RFC7252].

   For TLS, the initial value for the Server-Name Option is given by the
   SNI value.

   For Websockets, the initial value for the Server-Name Option is given
   by the HTTP Host header field.

4.3.2.  Max-Message-Size Capability Option

   The sender can use the Max-Message-Size elective option to indicate
   the maximum message size in bytes that it can receive.

   +--------+-----------+------------------+--------+--------+---------+
   | Number | Applies   | Name             | Format | Length |    Base |
   |        | to        |                  |        |        |   Value |
   +--------+-----------+------------------+--------+--------+---------+
   | 2      | CSM       | Max-Message-Size |   uint |    0-4 |    1152 |
   +--------+-----------+------------------+--------+--------+---------+

   As per Section 4.6 of [RFC7252], the base value (and the value used
   when this option is not implemented) is 1152.  A peer that relies on
   this option being indicated with a certain minimum value will enjoy
   limited interoperability.

4.3.3.  Block-wise Transfer Capability Option

   +--------+-----------+----------------+--------+--------+-----------+
   | Number | Applies   | Name           | Format | Length |      Base |
   |        | to        |                |        |        |     Value |
   +--------+-----------+----------------+--------+--------+-----------+
   | 4      | CSM       | Block-wise     |  empty |      0 |    (none) |
   |        |           | Transfer       |        |        |           |
   +--------+-----------+----------------+--------+--------+-----------+

   A sender can use the Block-wise Transfer elective Option to indicate
   that it supports the block-wise transfer protocol
   [I-D.ietf-core-block].

   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 Section 5).

4.4.  Ping and Pong Messages

   In CoAP over TCP, Empty messages (Code 0.00) can always be sent and
   MUST be ignored by the recipient (see also Section 4.4).  This
   provides a basic keep-alive function that can refresh NAT bindings.
   In contrast, Ping and Pong messages are a bidirectional exchange.

   Upon receipt of a Ping message, a single Pong message is returned
   with the identical token.  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).

4.4.1.  Custody Option

     +--------+------------+---------+--------+--------+------------+
     | Number | Applies to | Name    | Format | Length | Base Value |
     +--------+------------+---------+--------+--------+------------+
     | 2      | Ping, Pong | Custody |  empty |      0 |     (none) |
     +--------+------------+---------+--------+--------+------------+

   A peer replying to a Ping message can add a Custody elective option
   to the Pong message it returns.  This option indicates that the
   application has processed all request/response messages that it has
   received in the present connection ahead of the Ping message that
   prompted the Pong message.  (Note that there is no definition of
   specific application semantics of "processed", but there is an
   expectation that the sender of the Ping leading to the Pong with a
   Custody Option should be able to free buffers based on this
   indication.)

   A Custody elective option can also be sent in a Ping message to
   explicitly request the return of a Custody Option in the Pong
   message.  A peer is always free to indicate that it has finished
   processing all previous request/response messages by sending a
   Custody Option in a Pong message.  A peer is also free NOT to send a
   Custody Option in case it is still processing previous request/
   response messages; however, it SHOULD delay its response to a Ping
   with a Custody Option until it can also return one.

4.5.  Release Messages

   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 MAY be included.  A
   release message will normally be replied to by the peer 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:

   +--------+-----------+-----------------+--------+--------+----------+
   | Number | Applies   | Name            | Format | Length |     Base |
   |        | to        |                 |        |        |    Value |
   +--------+-----------+-----------------+--------+--------+----------+
   | 2      | Release   | Bad-Server-Name |  empty |      0 |   (none) |
   +--------+-----------+-----------------+--------+--------+----------+
   The Bad-Server-Name elective option indicates that the default
   indicated by the CSM Server-Name Option is unlikely to be useful for
   this server.

   +--------+----------+-------------------+--------+--------+---------+
   | Number | Applies  | Name              | Format | Length |    Base |
   |        | to       |                   |        |        |   Value |
   +--------+----------+-------------------+--------+--------+---------+
   | 4      | Release  | Alternate-Address | string |  1-255 |  (none) |
   +--------+----------+-------------------+--------+--------+---------+

   The Alternative-Address elective option requests the peer to instead
   open a connection of the same kind as the present connection to the
   alternative transport address given.  Its value is in the form
   "authority" as defined in Section 3.2 of [RFC3986].

     +--------+------------+----------+--------+--------+------------+
     | Number | Applies to | Name     | Format | Length | Base Value |
     +--------+------------+----------+--------+--------+------------+
     | 6      | Release    | Hold-Off |   uint |    0-3 |     (none) |
     +--------+------------+----------+--------+--------+------------+

   The Hold-Off elective option indicates that the server is requesting
   that the peer not reconnect to it for the number of seconds given in
   the value.

4.6.  Abort Messages

   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
   SHOULD be integrated into 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:

   +--------+-----------+----------------+--------+--------+-----------+
   | Number | Applies   | Name           | Format | Length |      Base |
   |        | to        |                |        |        |     Value |
   +--------+-----------+----------------+--------+--------+-----------+
   | 2      | Abort     | Bad-CSM-Option |   uint |    0-2 |    (none) |
   +--------+-----------+----------------+--------+--------+-----------+
   The 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 Web environment where diagnostic payload.

   One reason for an sender to generate an abort message is a general
   syntax error in the
   front-end uses byte stream received.  No specific option has
   been defined for this, as the details of that syntax error are best
   left to a diagnostic payload.

4.7.  Capability and Settings examples

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

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x01     |      0xe2     |      0x42     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                      Figure 15: Ping Message Example

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

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0x01     |      0xe3     |      0x42     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                      Figure 16: Pong Message Example

5.  Block-wise Transfer and Reliable Transports

   The message size restrictions defined in Section 4.6 of CoAP from IoT devices
   [RFC7252] to avoid IP fragmentation are not necessary when CoAP is
   used over a cloud infrastructure but reliable byte stream transport.  While this suggests that
   the CoAP messages are then transported in Block-wise transfer protocol [I-D.ietf-core-block] is also no
   longer needed, it remains applicable for a number of cases:

   o  large messages, such as firmware downloads, may cause undesired
      head-of-line blocking when a single TCP between the back-end
   services.  A TCP-to-UDP gateway can be connection is used at

   o  a UDP-to-TCP gateway may simply not have the cloud boundary to
   talk context to convert a
      message with a Block Option into the UDP-based IoT.

   To make IoT devices work smoothly in these demanding environments,
   CoAP needs to make equivalent exchange without
      any use of a different transport protocol, namely TCP
   [RFC0793], in some situations secured by TLS [RFC5246].

   The present document describes a shim header that conveys length
   information about each CoAP message.  Modifications Block Option (it would need to CoAP beyond
   the replacement of convert the message layer (e.g., entire
      blockwise exchange from start to introduce further
   optimizations) are intentionally avoided.

2.  Terminology end into a single exchange)

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are 'Block-wise Extension for Reliable Transport (BERT)' extends the
   Block protocol to be interpreted as described in
   [RFC2119].

3.  Constrained Application Protocol

   The interaction model enable the use of CoAP larger messages over TCP 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 very similar to a reserved
   value in [I-D.ietf-core-block].

   In control usage, a BERT option is interpreted in the one for
   CoAP over UDP, with same way as the key difference
   equivalent Option with SZX == 6, except that using TCP voids it also indicates the need
   capability to provide certain transport layer protocol features, such as
   reliable delivery, fragmentation and reassembly, as well as
   congestion control, at process BERT blocks.  As with the basic Block protocol,
   the recipient of a CoAP level.  The protocol stack is
   illustrated request with a BERT option in Figure 1 (derived from [RFC7252], Figure 1).

           +----------------------+
           |      Application     |
           +----------------------+
           +----------------------+
           |  Requests/Responses  |  CoAP (RFC7252)
           |----------------------|
           |    Message adapter   |  This Document
           +----------------------+
           +-----------+    ^
           |    TLS    |    |
           +-----------+    v
           +----------------------+
           |          TCP         |
           +----------------------+

              Figure 1: The CoAP over TLS/TCP Protocol Stack

   Since TCP offers reliable delivery, there control usage
   is no need allowed to offer respond with a
   redundant acknowledgement at the CoAP messaging layer.

   Since there is no need different SZX value, e.g. to carry around acknowledgement semantics,
   messages do not require send a message type; no message layer
   acknowledgement non-
   BERT block instead.

   In descriptive usage, a BERT Option is expected or even possible.  By interpreted in the nature of TCP,
   messages are always transmitted reliably over TCP.  Figure 2 (derived
   from [RFC7252], Figure 3) shows this message exchange graphically.  A
   UDP-to-TCP gateway will therefore discard all empty messages, such same way as
   empty ACKs (after operating on them at
   the message layer), and re-
   pack equivalent Option with SZX == 6, except that the contents payload is
   allowed to contain a multiple of all non-empty CON, NON, 1024 bytes (non-final BERT block) or ACK messages (i.e.,
   those ACK messages that have
   more than 1024 bytes (final BERT block).

   The recipient of a piggy-backed response) non-final BERT block (M=1) conceptually partitions
   the payload into untyped
   messages.

   Similarly, there 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 no need
   positioned at the byte position that results from multiplying the
   block number with 1024.  The position of further blocks to detect duplicate delivery 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
   message.  In UDP CoAP, final BERT block (M=0) simply
   appends the Message ID is used for relating
   acknowledgements to Confirmable messages as well as for duplicate
   detection.  Since payload at the Message ID thus is not meaningful over TCP, it byte position that is elided (as indicated by the dashes in Figure 2).

           Client                Server
              |                     |
              | (no type) [------]  |
              +-------------------->|
              |                     |

             Figure 2: Untyped Message Transmission over TCP.
   block number multiplied with 1024.

   The following examples illustrate BERT options.  A response value of SZX == 7
   is sent back labeled as defined in [RFC7252], "BERT" or as illustrated in
   Figure 3 (derived from [RFC7252], Figure 6).

           Client                Server
              |                    |
              | (no type) [------] |
              | GET /temperature   |
              |   (Token 0x74)     |
              +------------------->|
              |                    |
              | (no type) [------] |
              |   2.05 Content     |
              |   (Token 0x74)     |
              |     "22.5 C"       |
              |<-------------------+
              |                    |

                                 Figure 3

4.  Message Format

   The CoAP message format defined in [RFC7252], "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 exponent (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 in as
   1:3/1/128.

5.1.  Example: GET with BERT Blocks

   Figure 4,
   relies on 17 shows a GET request with a response that is split into
   three BERT blocks.  The first response contains 3072 bytes of
   payload; the datagram transport (UDP, or DTLS over UDP) for keeping second, 5120; and the individual messages separate.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver| T third, 4711.  Note how the block
   number increments to move the position inside the response body
   forward.

   CLIENT                                       SERVER
     |  TKL                                            |      Code
     |          Message ID GET, /status                       ------> |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                            |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | <------   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)   |

                     Figure 4: RFC 7252 defined CoAP Message Format.

   In 17: GET with BERT blocks.

5.2.  Example: PUT with BERT Blocks

   Figure 18 demonstrates a stream oriented transport protocol such as TCP, PUT exchange with BERT blocks.

   CLIENT                                        SERVER
     |                                             |
     | PUT, /options, 1:0/1/BERT(8192)     ------> |
     |                                             |
     | <------   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         |
     |                                             |

                     Figure 18: PUT with BERT blocks.

6.  CoAP URIs

   CoAP over UDP [RFC7252] defines the "coap" and "coaps" URI schemes
   for identifying CoAP resources and providing a form means of
   message delimitation locating the
   resource.

6.1.  CoAP over TCP and TLS URIs

   CoAP over TCP uses the "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.

   [RFC7252], Section 8 (Multicast CoAP) is needed.  For not applicable to these
   schemes.

   Resources made available via one of the "coap+tcp" or "coaps+tcp"
   schemes have no shared identity with the other scheme or with the
   "coap" or "coaps" scheme, even if their resource identifiers indicate
   the same authority (the same host listening to the same port).  The
   schemes constitute distinct namespaces and, in combination with the
   authority, are considered to be distinct origin servers.

6.1.1.  coap+tcp URI scheme

   coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] path-abempty
                  [ "?" query ]

   The semantics defined in [RFC7252], Section 6.1, apply to this purpose, CoAP over TCP
   introduces a length field URI
   scheme, with variable size.  Figure 5 shows the
   adjusted CoAP header format with a modified structure for following changes:

   o  The port subcomponent indicates the fixed
   header (first 4 bytes of TCP port at which the UDP CoAP header), which includes
      server is located.  (If it is empty or not given, then the
   length information of variable size, shown here default
      port 5683 is assumed, as an 8-bit length.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=13 |  TKL  | Length (8-bit)|      Code     | TKL bytes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: CoAP Header with 8-bit Length UDP.)

6.1.2.  coaps+tcp URI scheme

   coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] path-abempty
                   [ "?" query ]

   The semantics defined in Header. [RFC7252], Section 6.2, apply to this URI
   scheme, with the following changes:

   o  The initial byte of port subcomponent indicates the frame contains two nibbles, in a similar way TCP port at which the TLS
      server for the CoAP server is located.  If it is empty or not
      given, then the default port 443 is assumed (this is different
      from the default port for "coaps", i.e., CoAP over DTLS over UDP).

   o  When CoAP is exchanged over TLS port 443, the "TLS Application
      Layer Protocol Negotiation Extension" [RFC7301] MUST be used to
      allow demultiplexing at the server-side.

6.2.  CoAP option encoding (see Section 3.1 of [RFC7252]).

   Len:  The first nibble, Len, is interpreted as a 4-bit unsigned
      integer.  A value between 0 and 12 directly indicates the length
      of message in bytes starting with over WebSockets URIs

   For the first bit of the Options
      field.  The other three values have a special meaning:

      13:  An 8-bit unsigned integer follows the initial byte and
         indicates the length of options/payload minus 13.

      14:  A 16-bit unsigned integer configuration discussed in network byte order follows the
         initial byte Section 3, this document
   defines two new URIs schemes that can be used for identifying CoAP
   resources and indicates the length providing a means of options/payload minus
         269.

      15:  A 32-bit unsigned integer in network byte order follows locating these resources:
   "coap+ws" and "coap+wss".

   Similar to the
         initial byte "coap" and indicates "coaps" schemes, the length of options/payload minus
         65805.

   TKL: "coap+ws" and
   "coap+wss" schemes organize resources hierarchically under a CoAP
   origin server.  The second nibble of the initial byte indicates key difference is that the token
      length. server is potentially
   reachable on a WebSocket endpoint instead of a UDP endpoint.

   The following figures show the shim headers for the 0-bit, 16-bit,
   and the 32-bit headers.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Len  |  TKL  |      Code     | Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 6: CoAP Header with elided Length Header.

   For example: A CoAP message just containing WebSocket endpoint is identified by a 2.03 code with "ws" or "wss" URI that is
   composed of the
   token 7f authority part of the "coap+ws" or "coap+wss" URI,
   respectively, and no options the well-known path "/.well-known/coap" [RFC5785].
   The path and query parts of a "coap+ws" or payload would be encoded as shown in
   Figure 7.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x01     |      0x43     |      0x7f     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                      Figure 7: CoAP Header Example.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=14 |  TKL  | Length (16 bits)              |   Code        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8: CoAP Header with 16-bit Length in Header.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Len=15 |  TKL  | Length (32 bits)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |    Code       |  Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9: CoAP Header with 32-bit Length in Header. "coap+wss" URI identify a
   resource within the specified endpoint which can be operated on by
   the methods defined by CoAP.

   The semantics syntax of the other CoAP header fields "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 left unchanged.

4.1.  Discussion

   One observation the
   same as in [RFC3986].

     coap-ws-URI =
        "coap+ws:" "//" host [ ":" port ] path-abempty [ "?" query ]

     coap-wss-URI =
        "coap+wss:" "//" host [ ":" port ] path-abempty [ "?" query ]

   The port component is that, over 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 reliable byte stream transport, WebSocket handshake or in the
   message size limitations defined URI options of
   a CoAP request.

6.2.1.  Decomposing and Composing URIs

   The steps for decomposing a "coap+ws" or "coap+wss" URI into CoAP
   options are the same as specified in Section 4.6 6.4 of [RFC7252] with
   the following changes:

   o  The <scheme> component MUST be "coap+ws" or "coap+wss" when
      converted to ASCII lowercase.

   o  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.

   o  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 no
   longer strictly necessary.  Consenting [[how: There is currently no
   defined way changed
   accordingly.

7.  Security Considerations

   The security considerations of [RFC7252] apply.

   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].

   TLS does not protect the TCP header.  This may, for example, allow an
   on-path adversary to arrive at this consent. --cabo]] implementations may
   want terminate a TCP connection prematurely by
   spoofing a TCP reset message.

   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.

7.1.  Signaling Messages

   o  The guidance given by an Alternative-Address Option cannot be
      followed blindly.  In particular, a peer MUST NOT assume that a
      successful connection to interchange messages with payload sizes larger than 1024
   bytes, potentially also obviating the need for Alternative-Address inherits all the Block protocol
   [I-D.ietf-core-block].  It must be noted that entirely getting rid
      security properties of the block protocol is not a generally applicable solution, as: current connection.

   o  a UDP-to-TCP gateway may simply not have  SNI vs. Server-Name: Any security negotiated in the context to convert a
      message with a Block option into TLS handshake
      is for the equivalent exchange without
      any use of a Block option;

   o  large messages might also cause undesired head-of-line blocking;

   o SNI name exchanged in the 2-byte message length field causes another, larger upper bound
      to TLS handshake and checked
      against the message length.

   [I-D.bormann-core-block-bert] proposes certificate provided by the server.  The Server-Name
      Option cannot be used to extend these security properties to the block-wise
   transfer protocol
      additional server name.

8.  IANA Considerations

8.1.  Signaling Codes

   IANA is requested to allow create a third sub-registry for larger block sizes as are possible
   over TCP and TLS. values of the
   Code field in the CoAP header (Section 12.1 of [RFC7252]).  The general assumption name
   of this sub-registry is therefore that "CoAP Signaling Codes".

   Each entry in the block protocol will
   continue sub-registry must include the Signaling Code in the
   range 7.01-7.31, its name, and a reference to be used over TCP, even if TCP-based applications
   occasionally do exchange messages with payload sizes larger than
   desirable its documentation.

   Initial entries in UDP.

5.  Message Transmission

   As 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] |
                      +------+---------+-----------+

                        Table 1: CoAP exchanges messages asynchronously over the TCP connection,
   the client can send multiple requests without waiting Signal Codes

   All other Signaling Codes are Unassigned.

   The IANA policy for responses.
   For future additions to this reason, and due sub-registry is "IETF
   Review or IESG Approval" as described in [RFC5226].

8.2.  CoAP Signaling Option Numbers Registry

   IANA is requested to create a sub-registry for signaling options
   similar to the nature CoAP Option Numbers Registry (Section 12.2 of TCP, responses are returned
   during the same TCP connection as the request.  In
   [RFC7252]), with the event single change that a fourth column is added to
   the
   connection gets terminated, all requests sub-registry that have not yet elicited a
   response are implicitly canceled; clients may transmit is one of the request
   again once a connection codes in the Signaling Codes
   subregistry (Section 8.1).

   The name of this sub-registry is reestablished.

   Furthermore, since TCP "CoAP Signaling Option Numbers".

   Initial entries in this sub-registry are as follows:

         +--------+------------+---------------------+-----------+
         | Number | Applies to | Name                | Reference |
         +--------+------------+---------------------+-----------+
         |      1 | CSM        | Server-Name         | [RFCthis] |
         |        |            |                     |           |
         |      2 | CSM        | Max-Message-Size    | [RFCthis] |
         |        |            |                     |           |
         |      4 | CSM        | Block-wise-Transfer | [RFCthis] |
         |        |            |                     |           |
         |      2 | Ping, Pong | Custody             | [RFCthis] |
         |        |            |                     |           |
         |      2 | Release    | Bad-Server-Name     | [RFCthis] |
         |        |            |                     |           |
         |      4 | Release    | Alternative-Address | [RFCthis] |
         |        |            |                     |           |
         |      6 | Release    | Hold-Off            | [RFCthis] |
         |        |            |                     |           |
         |      2 | Abort      | Bad-CSM-Option      | [RFCthis] |
         +--------+------------+---------------------+-----------+

                     Table 2: CoAP Signal Option Codes

   The IANA policy for future additions to this sub-registry is bidirectional, requests can be sent from
   both based on
   number ranges for the connecting host and option numbers, analogous to the endpoint that accepted policy defined
   in Section 12.2 of [RFC7252].

8.3.  Service Name and Port Number Registration

   IANA is requested to assign the
   connection.  In other words, port number 5683 and the question who initiated service name
   "coap+tcp", in accordance with [RFC6335].

   Service Name.
      coap+tcp

   Transport Protocol.
      tcp

   Assignee.
      IESG <iesg@ietf.org>

   Contact.
      IETF Chair <chair@ietf.org>

   Description.
      Constrained Application Protocol (CoAP)

   Reference.
      [RFCthis]

   Port Number.
      5683

   Similarly, IANA is requested to assign the TCP
   connection has service name "coaps+tcp",
   in accordance with [RFC6335].  However, no bearing on separate port number is
   used for "coaps" over TCP; instead, the meaning ALPN protocol ID defined in
   Section 8.6 is used over port 443.

   Service Name.
      coaps+tcp

   Transport Protocol.
      tcp

   Assignee.
      IESG <iesg@ietf.org>

   Contact.
      IETF Chair <chair@ietf.org>

   Description.
      Constrained Application Protocol (CoAP)

   Reference.
      [RFC7301], [RFCthis]

   Port Number.
      443 (see also Section 8.6 of the CoAP terms client and
   server.

6.  CoAP [RFCthis]})

8.4.  URI

   CoAP [RFC7252] defines the "coap" and "coaps" Scheme Registration

   This document registers two new URI schemes schemes, namely "coap+tcp" and
   "coaps+tcp", for
   identifying the use of CoAP resources over TCP and providing a means of locating the
   resource.  RFC 7252 defines these resources for use with CoAP over
   UDP. TLS over
   TCP, respectively.  The present specification introduces two new URI schemes, namely "coap+tcp" and "coaps+tcp".  The rules from Section 6 of [RFC7252]
   apply "coaps+tcp" URI schemes can
   thus be compared to these two new the "http" and "https" URI schemes.

   [RFC7252], Section 8 (Multicast CoAP), does not apply to

   The syntax of the "coap" and "coaps" URI schemes defined is specified in the present specification.

   Resources made available via one
   Section 6 of [RFC7252] and the present document re-uses their
   semantics for "coap+tcp" and "coaps+tcp", respectively, with the
   exception that TCP, or "coaps+tcp" TLS over TCP is used as a transport protocol.

   IANA is requested to add these new URI schemes have no shared identity to the registry
   established with [RFC7595].

8.4.1.  coap+ws

   This document requests the other registration of the Uniform Resource
   Identifier (URI) scheme or "coap+ws".  The registration request complies
   with [RFC4395].

   URL scheme name.
      coap+ws

   Status.
      Permanent

   URI scheme syntax.
      Defined in Section N of [RFCthis]

   URI scheme semantics.
      The "coap+ws" URI scheme provides a way to identify resources that
      are potentially accessible over the
   "coap" or "coaps" scheme, even if their resource identifiers indicate Constrained Application
      Protocol (CoAP) using the same authority (the same host listening WebSocket protocol.

   Encoding considerations.
      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.

   Applications/protocols that use this URI scheme name.
      The scheme is used by CoAP endpoints to access CoAP resources
      using the same port). WebSocket protocol.

   Interoperability considerations.
      None.

   Security Considerations.

      See Section N of [RFCthis]

   Contact.
      IETF chair <chair@ietf.org>

   Author/Change controller.
      IESG <iesg@ietf.org>

   References.
      [RFCthis]

8.4.2.  coap+wss

   This document requests the registration of the Uniform Resource
   Identifier (URI) scheme "coap+wss".  The
   schemes constitute distinct namespaces and, in combination registration request
   complies with the
   authority, are considered to be distinct origin servers.

6.1.  coap+tcp [RFC4395].

   URL scheme name.
      coap+wss

   Status.
      Permanent

   URI scheme

   coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] path-abempty
                  [ "?" query ]

   The semantics defined syntax.
      Defined in [RFC7252], Section 6.1, apply to this N of [RFCthis]

   URI
   scheme, with the following changes:

   o scheme semantics.
      The port subcomponent indicates the TCP port at which "coap+ws" URI scheme provides a way to identify resources that
      are potentially accessible over the CoAP
      server is located.  (If it is empty or not given, then Constrained Application
      Protocol (CoAP) using the default
      port 5683 is assumed, as WebSocket protocol secured with UDP.)

6.2.  coaps+tcp
      Transport Layer Security (TLS).

   Encoding considerations.
      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.

   Applications/protocols that use this URI scheme

   coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] path-abempty
                   [ "?" query ] name.
      The semantics defined in [RFC7252], scheme is used by CoAP endpoints to access CoAP resources
      using the WebSocket protocol secured with TLS.

   Interoperability considerations.
      None.

   Security Considerations.
      See Section 6.2, apply N of [RFCthis]

   Contact.

      IETF chair <chair@ietf.org>

   Author/Change controller.
      IESG <iesg@ietf.org>

   References.
      [RFCthis]

8.5.  Well-Known URI Suffix Registration

   IANA is requested to this register the 'coap' well-known URI
   scheme, in the "Well-
   Known URIs" registry.  This registration request complies with
   [RFC5785]:

   URI Suffix.
      coap

   Change controller.
      IETF

   Specification document(s).
      [RFCthis]

   Related information.
      None.

8.6.  ALPN Protocol ID

   IANA is requested to assign the following changes:

   o  The port subcomponent indicates the TCP port at which value in the TLS
      server for registry
   "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created
   by [RFC7301]:

   Protocol.
      CoAP

   Identification Sequence.
      0x63 0x6f 0x61 0x70 ("coap")

   Reference.
      [RFCthis]

8.7.  WebSocket Subprotocol Registration

   IANA is requested to register the WebSocket CoAP server is located.  If it is empty or not
      given, then subprotocol under
   the default port 443 is assumed (this is different
      from "WebSocket Subprotocol Name Registry":

   Subprotocol Identifier.
      coap

   Subprotocol Common Name.
      Constrained Application Protocol (CoAP)

   Subprotocol Definition.
      [RFCthis]

9.  References

9.1.  Normative References

   [I-D.ietf-dice-profile]
              Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the default port
              Internet of Things", draft-ietf-dice-profile-17 (work in
              progress), October 2015.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for "coaps", i.e., CoAP over DTLS over UDP).

   o  When CoAP is exchanged over TLS port 443 then use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", RFC 4395,
              DOI 10.17487/RFC4395, February 2006,
              <http://www.rfc-editor.org/info/rfc4395>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
              RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, DOI
              10.17487/RFC5785, April 2010,
              <http://www.rfc-editor.org/info/rfc5785>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, DOI 10.17487/RFC6455, December 2011,
              <http://www.rfc-editor.org/info/rfc6455>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
              RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <http://www.rfc-editor.org/info/rfc7301>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35, RFC
              7595, DOI 10.17487/RFC7595, June 2015,
              <http://www.rfc-editor.org/info/rfc7595>.

   [RFC7641]  Hartke, K., "Observing Resources in the "TLS Constrained
              Application
      Layer Protocol Negotiation Extension" [RFC7301] MUST be used to
      allow demultiplexing at the server-side unless out-of-band
      information ensures that (CoAP)", RFC 7641, DOI 10.17487/
              RFC7641, September 2015,
              <http://www.rfc-editor.org/info/rfc7641>.

9.2.  Informative References

   [HomeGateway]
              Eggert, L., "An experimental study of home gateway
              characteristics", Proceedings of the client only interacts with a server
      that is able to demultiplex CoAP messages over port 443.  This
      would, for example, be true for many IoT deployments where clients
      are pre-configured to only ever talk with specific servers.
      [[alwaysalpn: Shouldn't we simply always require ALPN?  The
      protocol should not be defined in such a way that it depends 10th annual
              conference on
      some undefined pre-configuration mechanism. --cabo]]

7.  Security Considerations

   This document defines how to convey Internet measurement, 2010.

   [I-D.becker-core-coap-sms-gprs]
              Becker, M., Li, K., Kuladinithi, K., and T. Poetsch,
              "Transport of CoAP over TCP SMS", draft-becker-core-coap-sms-
              gprs-05 (work in progress), August 2014.

   [I-D.ietf-core-block]
              Bormann, C. and TLS.  It does
   not introduce new vulnerabilities beyond those described already Z. Shelby, "Block-wise transfers in
   the CoAP specification.  CoAP [RFC7252] makes use of DTLS 1.2 CoAP",
              draft-ietf-core-block-20 (work in progress), April 2016.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
              10.17487/RFC0768, August 1980,
              <http://www.rfc-editor.org/info/rfc768>.

   [RFC5234]  Crocker, D., Ed. and
   this specification consequently uses TLS 1.2 [RFC5246].  CoAP MUST
   NOT be used with older versions of TLS.  Guidelines P. Overell, "Augmented BNF for use of cipher
   suites Syntax
              Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
              RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and TLS extensions can be found in [I-D.ietf-dice-profile].

8.  IANA Considerations

8.1. S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and Port Number Registration

   IANA is requested to assign the port number 5683
              Transport Protocol Port Number Registry", BCP 165, RFC
              6335, DOI 10.17487/RFC6335, August 2011,
              <http://www.rfc-editor.org/info/rfc6335>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, DOI
              10.17487/RFC6454, December 2011,
              <http://www.rfc-editor.org/info/rfc6454>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and the service name
   "coap+tcp", in accordance with [RFC6335].

   Service Name.
      coap+tcp

   Transport Protocol.
      tcp

   Assignee.
      IESG <iesg@ietf.org>

   Contact.
      IETF Chair <chair@ietf.org>

   Description.
      Constrained Application Routing", RFC
              7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

Appendix A.  Negotiating Protocol (CoAP)

   Reference.
      [RFCthis]

   Port Number.
      5683

   Similarly, IANA Versions

   CoAP is requested to assign the service name "coaps+tcp", defined in accordance [RFC7252] with [RFC6335].  However, no separate port a version number of 1.  At this
   time, there is
   used for "coaps" over TCP; instead, no known reason to support version numbers different
   from 1.

   In contrast to the ALPN protocol ID defined in
   Section 8.3 is used over port 443.

   Service Name.
      coaps+tcp

   Transport Protocol.
      tcp

   Assignee.
      IESG <iesg@ietf.org>

   Contact.
      IETF Chair <chair@ietf.org>

   Description.
      Constrained Application Protocol (CoAP)

   Reference.
      [RFC7301], [RFCthis]

   Port Number.
      443 (see also Section 8.3 of [RFCthis]})

8.2.  URI Schemes

   This document registers two new URI schemes, namely "coap+tcp" and
   "coaps+tcp", message layer for UDP and DTLS, the use of CoAP over TCP
   message format does not include a version number.  If version
   negotiation needs to be addressed in the future, then Capability and for
   Settings have been specifically designed to enable such a potential
   feature.

Appendix B.  CoAP over TLS over
   TCP, respectively.  The "coap+tcp" and "coaps+tcp" URI schemes can
   thus be compared WebSocket Examples

   This section gives examples for the first two configurations
   discussed in Section 3.

   An example of the process followed by a CoAP client to retrieve the "http" and "https" URI schemes.

   The syntax
   representation of a resource identified by a "coap+ws" URI might be
   as follows.  Figure 19 below illustrates the "coap" WebSocket and "coaps" URI schemes is specified CoAP
   messages exchanged in
   Section 6 of [RFC7252] and detail.

   1.  The CoAP client obtains the present document re-uses their
   semantics URI <coap+ws://example.org/sensors/
       temperature?u=Cel>, for "coap+tcp" and "coaps+tcp", respectively, with the
   exception that TCP, or TLS over TCP is used as example, from a resource representation
       that it retrieved previously.

   2.  It establishes a transport protocol.

   IANA is requested WebSocket connection to add these new the endpoint URI schemes to
       composed of the registry
   established authority "example.org" and the well-known path
       "/.well-known/coap", <ws://example.org/.well-known/coap>.

   3.  It sends a single-frame, masked, binary message containing a CoAP
       request.  The request indicates the target resource with [RFC7595].

8.3.  ALPN Protocol ID

   IANA is requested to assign the following value in Uri-
       Path ("sensors", "temperature") and Uri-Query ("u=Cel") options.

   4.  It waits for the registry
   "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created
   by [RFC7301]:

   Protocol:
      CoAP

   Identification Sequence:
      0x63 0x6f 0x61 0x70 ("coap")

   Reference:
      [RFCthis]

9.  Acknowledgements

   We would like server to thank Stephen Berard, Geoffrey Cristallo, Olivier
   Delaby, Michael Koster, Matthias Kovatsch, Szymon Sasin, Andrew
   Summers, and Zach Shelby for their feedback.

10.  References

10.1.  Normative References

   [I-D.ietf-dice-profile]
              Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles return a response.

   5.  The CoAP client uses the connection for further requests, or the
              Internet
       connection is closed.

      CoAP        CoAP
     Client      Server
   (WebSocket  (WebSocket
     Client)     Server)

        |          |
        |          |
        +=========>|  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)
        |          |

    Figure 19: A CoAP client retrieves the representation of Things", draft-ietf-dice-profile-17 (work in
              progress), October 2015.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for a resource
                       identified by a "coap+ws" URI

   Figure 20 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 RFCs 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 Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <http://www.rfc-editor.org/info/rfc7301>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines the CoAP server and Registration Procedures for returning the response over the
   WebSocket connection to the client.

     CoAP        CoAP       CoAP
    Client      Proxy      Server
  (WebSocket  (WebSocket    (UDP
    Client)     Server)   Endpoint)

       |          |          |
       +--------->|          |  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"                   |
       |          |          |    +------------------------------------+
       |          |          |

    Figure 20: A CoAP client retrieves the representation of a resource
      identified by a "coap" URI Schemes", BCP 35, via a WebSockets-enabled CoAP proxy

Appendix C.  Change Log

   The RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <http://www.rfc-editor.org/info/rfc7595>.

10.2.  Informative References

   [HomeGateway]
              Eggert, L., "An experimental study of home gateway
              characteristics", Proceedings of the 10th annual
              conference on Internet measurement, 2010.

   [I-D.bormann-core-block-bert]
              Bormann, C., "Block-wise transfers in CoAP: Extension for
              Reliable Transport (BERT)", draft-bormann-core-block-
              bert-00 (work in progress), November 2015.

   [I-D.bormann-core-cocoa]
              Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
              "CoAP Simple Congestion Control/Advanced", Editor is requested to remove this section at publication.

C.1.  Since draft-core-coap-tcp-tls-02

   Merged draft-savolainen-core-coap-websockets-07 Merged draft-bormann-
              core-cocoa-03 (work in progress), October 2015.

   [I-D.ietf-core-block]
              Bormann, C. and Z.
   core-block-bert-01 Merged draft-bormann-core-coap-sig-02

Acknowledgements

   We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier
   Delaby, Christian Groves, Nadir Javed, Michael Koster, Matthias
   Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Zach Shelby, "Block-wise transfers in CoAP",
              draft-ietf-core-block-19 (work in progress), March 2016.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <http://www.rfc-editor.org/info/rfc768>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M.,
   Andrew Summers, Julien Vermillard, and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures Gengyu Wei for the Management their feedback.

Contributors

   Valik Solorzano Barboza
   Zebra Technologies
   820 W. Jackson Blvd. Suite 700
   Chicago 60607
   United States of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <http://www.rfc-editor.org/info/rfc6335>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>. America

   Phone: +1-847-634-6700
   Email: vsolorzanobarboza@zebra.com

   Teemu Savolainen
   Nokia Technologies
   Hatanpaan valtatie 30
   Tampere FI-33100
   Finland

   Email: teemu.savolainen@nokia.com

Authors' Addresses

   Carsten Bormann (editor)
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org
   Simon Lemay
   Zebra Technologies
   820 W. Jackson Blvd. Suite 700
   Chicago  60607
   United States of America

   Phone: +1-847-634-6700
   Email: slemay@zebra.com

   Valik Solorzano Barboza
   Zebra Technologies
   820 W. Jackson Blvd. suite 700
   Chicago  60607
   United States of America

   Phone: +1-847-634-6700
   Email: vsolorzanobarboza@zebra.com

   Hannes Tschofenig
   ARM Ltd.
   110 Fulbourn Rd
   Cambridge  CB1 9NJ
   Great Britain

   Email: Hannes.tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

   Klaus Hartke
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63905
   Email: hartke@tzi.org

   Bilhanan Silverajan
   Tampere University of Technology
   Korkeakoulunkatu 10
   Tampere  FI-33720
   Finland

   Email: bilhanan.silverajan@tut.fi

   Brian Raymor (editor)
   Microsoft
   One Microsoft Way
   Redmond  98052
   United States of America

   Email: brian.raymor@microsoft.com