[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 draft-ietf-core-stateless

CoRE Working Group                                             K. Hartke
Internet-Draft                                                  Ericsson
Updates: 7252, 8323 (if approved)                     September 10, 2018
Intended status: Standards Track
Expires: March 14, 2019


                 Extended Tokens and Stateless Clients
             in the Constrained Application Protocol (CoAP)
                     draft-hartke-core-stateless-00

Abstract

   This document provides considerations for alleviating CoAP clients
   and intermediaries of maintaining per-request state.  Additionally,
   it introduces a new, optional CoAP protocol extension for extended
   tokens.

   [[The present draft presents two alternative variants for extending
   CoAP with extended tokens.  Variant A makes use of the unused values
   in the TKL field of the CoAP header.  Variant B duplicates the
   functionality of the token field of the CoAP header in a new CoAP
   option, "Extended-Token".  The considerations for stateless clients
   making use of either variant are the same.]]

   This document updates RFCs 7252 and 8323 (if Variant A).

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 https://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 March 14, 2019.








Hartke                   Expires March 14, 2019                 [Page 1]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


Copyright Notice

   Copyright (c) 2018 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
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   4
   2.  (Variant A:) Extended Tokens  . . . . . . . . . . . . . . . .   4
     2.1.  Extended Token Length (TKL) Field . . . . . . . . . . . .   4
     2.2.  Discovering Support . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Extended-Token-Lengths Capability Option  . . . . . .   5
       2.2.2.  Trial and Error . . . . . . . . . . . . . . . . . . .   6
   3.  (Variant B:) Extended Tokens  . . . . . . . . . . . . . . . .   6
     3.1.  Extended-Token Option . . . . . . . . . . . . . . . . . .   6
     3.2.  Discovering Support . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Extended-Token-Option Capability Option . . . . . . .   7
       3.2.2.  Trial and Error . . . . . . . . . . . . . . . . . . .   8
   4.  Stateless Clients . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Intermediaries  . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Extended Tokens . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Message Transmission  . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  (Variant A:) IANA Considerations  . . . . . . . . . . . . . .  11
     6.1.  CoAP Signaling Option Number  . . . . . . . . . . . . . .  11
   7.  (Variant B:) IANA Considerations  . . . . . . . . . . . . . .  11
     7.1.  CoAP Option Number  . . . . . . . . . . . . . . . . . . .  11
     7.2.  CoAP Signaling Option Number  . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  (Variant A:) Updated Message Formats . . . . . . . .  13
     A.1.  CoAP over UDP . . . . . . . . . . . . . . . . . . . . . .  14
     A.2.  CoAP over TCP . . . . . . . . . . . . . . . . . . . . . .  15
     A.3.  CoAP over WebSockets  . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17




Hartke                   Expires March 14, 2019                 [Page 2]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful
   application-layer protocol for constrained environments [RFC7228].
   In CoAP, clients (or proxies in the client role) make requests to
   servers (or proxies in the server role), which are serving these
   requests by returning responses.

   While a request is outstanding, a client typically maintains some
   state that it requires for processing the response when it arrives.
   Identification of this state is done by means of a _token_ in CoAP,
   an opaque sequence of bytes chosen by the client and in the CoAP
   request.  The server returns it verbatim in any resulting CoAP
   response (Figure 1).

          +-----------------+     request with     +------------+
          |        |        |   state identifier   |            |
          |        |        |       as token       |            |
          |    .-<-+->------|--------------------->|------.     |
          |   _|_           |                      |      |     |
          |  /   \ stored   |                      |      |     |
          |  \___/ state    |                      |      |     |
          |    |            |                      |      |     |
          |    '->-+-<------|<---------------------|------'     |
          |        |        |     response with    |            |
          |        v        |   token echoed back  |            |
          +-----------------+                      +------------+
                Client                                 Server

            Figure 1: Token as an Identifier for Request State

   In some scenarios, it can be beneficial to reduce the amount of state
   stored at the client at the cost of increased message sizes.  Client
   implementations can accomplish this by serializing their state into
   the token and recovering the state from the token in the response
   when it comes back (Figure 2).















Hartke                   Expires March 14, 2019                 [Page 3]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


          +-----------------+     request with     +------------+
          |        |        |   serialized state   |            |
          |        |        |       as token       |            |
          |        +--------|=====================>|------.     |
          |                 |                      |      |     |
          |    look, no     |                      |      |     |
          |   state, ma!    |                      |      |     |
          |                 |                      |      |     |
          |        +--------|<=====================|------'     |
          |        |        |     response with    |            |
          |        v        |   token echoed back  |            |
          +-----------------+                      +------------+
                Client                                 Server

             Figure 2: Token as Serialization of Request State

   Section 4 of this document provides considerations for making clients
   "stateless" in this way, i.e., avoiding per-request state.  (They'll
   still need to maintain per-server state and other kinds of state,
   though, so they're not entirely stateless.)

   Serializing state into tokens is complicated by the fact that both
   CoAP over UDP [RFC7252] and CoAP over reliable transports [RFC8323]
   limit the maximum token length to 8 bytes.  To overcome this
   limitation, Section 2 (Variant A) / Section 3 (Variant B) of this
   document first introduces a CoAP protocol extension for extended
   tokens.

1.1.  Requirements Notation

   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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  (Variant A:) Extended Tokens

2.1.  Extended Token Length (TKL) Field

   The message formats defined for CoAP over UDP [RFC7252] and CoAP over
   TCP, TLS, and WebSockets [RFC8323] are updated with the following new
   definition of the TKL field:

   Token Length (TKL):  4-bit unsigned integer.  A value between 0 and
      12 inclusive indicates the length of the variable-length Token
      field in bytes.  Three values are reserved for special constructs:




Hartke                   Expires March 14, 2019                 [Page 4]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


      13:  An 8-bit unsigned integer precedes the Token field and
         indicates the length of the Token field minus 13.

      14:  A 16-bit unsigned integer in network byte order precedes the
         Token field and indicates the length of the Token field minus
         269.

      15:  Reserved.  This value MUST NOT be sent and MUST be processed
         as a message format error.

   All other fields retain their definitions.

   The updated message formats are illustrated in Appendix A.

2.2.  Discovering Support

   Extended token lengths require support from the server or, if there
   are intermediaries between the client and the origin server, the
   intermediary in the server role that the client is interacting with.

   Support can be discovered by a client (or intermediary in the client
   role) in one of two ways: If Capabilities and Settings Messages
   (CSMs) are available, such as in CoAP over TCP, then support can be
   discovered using the new Extended-Token-Lengths Capability Option
   defined in Section 2.2.1.  Otherwise, such as in CoAP over UDP,
   support can only be discovered by trial and error, which is described
   in Section 2.2.2.

2.2.1.  Extended-Token-Lengths Capability Option

   A sender can use the elective Extended-Token-Lengths Capability
   Option to indicate its support for the updated definition of the TKL
   field as specified above.

   +----+---+---+-------+--------------------+-------+--------+--------+
   |  # | C | R | Appli | Name               | Forma | Length | Base   |
   |    |   |   | es to |                    | t     |        | Value  |
   +----+---+---+-------+--------------------+-------+--------+--------+
   | TB |   |   | CSM   | Extended-Token-    | empty | 0      | (none) |
   |  D |   |   |       | Lengths            |       |        |        |
   +----+---+---+-------+--------------------+-------+--------+--------+

                         C=Critical, R=Repeatable

           Table 1: The Extended-Token-Lengths Capability Option






Hartke                   Expires March 14, 2019                 [Page 5]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


2.2.2.  Trial and Error

   A request with a TKL field value outside the range from 0 to 8 will
   be considered a message format error (Section 3 of RFC 7252) and be
   rejected by the next hop if that does not support extended token
   lengths.  A client can therefore determine support by sending a
   request with an extended token length and checking if the next hop
   rejects the message.

   For CoAP over UDP, the recipient rejects a malformed confirmable
   message by sending an Reset message and otherwise ignoring the
   message (Section 4.2 of RFC 7252).  In case of a non-confirmable
   message, the Reset message is optional (Section 4.3 of RFC 7252), so
   it is RECOMMENDED that the client uses a confirmable message.  As per
   RFC 7252, a Reset message does not contain a token and only echoes
   back the Message ID of the confirmable or non-confirmable message
   (Figure 3).

          +-----------------+   request message    +------------+
          |        |        |    with extended     |            |
          |        |        |     token length     |            |
          |    .-<-+->------|--------------------->|------.     |
          |   _|_           |                      |      |     |
          |  /   \ stored   |                      |      |     |
          |  \___/ state    |                      |      |     |
          |    |            |                      |      |     |
          |    '->-+-<------|<---------------------|------'     |
          |        |        |     reset message    |            |
          |        v        |   with only message  |            |
          +-----------------+    ID echoed back    +------------+
                Client                                 Server

    Figure 3: A Confirmable Request With an Extended Token is Rejected
         With a Reset Message if the Next Hop Does Not Support It

   For CoAP over TCP, TLS, and WebSockets, the recipient rejects a
   malformed message by sending an Abort message and shutting down the
   connection (Section 5.6 of RFC 8323).  There is no specific Abort
   message option indicating the reason defined for this case.

3.  (Variant B:) Extended Tokens

3.1.  Extended-Token Option

   The Extended-Token Option contains an extension of the token that can
   additionally be used for matching a response with a request.





Hartke                   Expires March 14, 2019                 [Page 6]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


   +-----+---+---+---+---+----------------+--------+---------+---------+
   |   # | C | U | N | R | Name           | Format | Length  | Default |
   +-----+---+---+---+---+----------------+--------+---------+---------+
   | TBD | x | x |   |   | Extended-Token | opaque | 0-65535 | (none)  |
   +-----+---+---+---+---+----------------+--------+---------+---------+

             C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

                    Table 2: The Extended-Token Option

   A client (or intermediary in the role of a client) can include the
   Extended-Token Option in a request with any client-generated value.
   A server (or intermediary in the role of a server) MUST echo the
   value without modification in an Extended-Token Option in any
   resulting response.

   It is entirely up to the client how it splits the token between the
   Token field in the message header and the Extended-Token Option.

3.2.  Discovering Support

   The Extended-Token Option requires support from the server or, if
   there are intermediaries between the client and the origin server,
   the intermediary in the server role that the client is interacting
   with.

   Support can be discovered by a client (or intermediary in the client
   role) in one of two ways: If Capabilities and Settings Messages
   (CSMs) are available, such as in CoAP over TCP, then support can be
   discovered using the new Extended-Token-Option Capability Option
   defined in Section 3.2.1.  Otherwise, such as in CoAP over UDP,
   support can only be discovered by trial and error, which is described
   in Section 3.2.2.

3.2.1.  Extended-Token-Option Capability Option

   A sender can use the elective Extended-Token-Option Capability Option
   to indicate its support for the Extended-Token Option specified
   above.












Hartke                   Expires March 14, 2019                 [Page 7]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


   +----+---+---+--------+-------------------+-------+--------+--------+
   |  # | C | R | Applie | Name              | Forma | Length | Base   |
   |    |   |   | s to   |                   | t     |        | Value  |
   +----+---+---+--------+-------------------+-------+--------+--------+
   | TB |   |   | CSM    | Extended-Token-   | empty | 0      | (none) |
   |  D |   |   |        | Option            |       |        |        |
   +----+---+---+--------+-------------------+-------+--------+--------+

                         C=Critical, R=Repeatable

           Table 3: The Extended-Token-Option Capability Option

3.2.2.  Trial and Error

   A request with a critical, unsafe-to-forward option such as the
   Extended-Token Option will cause the return of a 4.02 (Bad Option)
   response from the next hop if that does not support the option.  A
   client can therefore determine support by sending a request with an
   Extended-Token Option to next hop and checking if that returns such a
   response.  As per RFC 7252, the response will not contain an
   Extended-Token Option, so only the regular token can be used for
   matching the response to the request.

   Note that a 4.02 (Bad Option) response does not necessarily mean that
   the Extended-Token Option is unsupported if there is another
   unsupported critical option in the request.

          +-----------------+   request message    +------------+
          |        |        |    with Extended-    |            |
          |        |        |     Token option     |            |
          |    .-<-+->------|--------------------->|------.     |
          |   _|_           |                      |      |     |
          |  /   \ stored   |                      |      |     |
          |  \___/ state    |                      |      |     |
          |    |            |                      |      |     |
          |    '->-+-<------|<---------------------|------'     |
          |        |        |   4.02 (Bad Option)  |            |
          |        v        |   response without   |            |
          +-----------------+    Extended-Token    +------------+
                Client               Option            Server

    Figure 4: A Request With an Extended-Token Option Results in a 4.02
         (Bad Option) Response if the Next Hop Does Not Support It








Hartke                   Expires March 14, 2019                 [Page 8]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


4.  Stateless Clients

   A client can be alleviated of keeping request state by serializing
   the state into a sequence of bytes and sending this as the token in a
   request.  The server will return the token to the client verbatim in
   the response, so that the client can recover the state and process
   the response as if it had kept the state locally.

   The format of the serialized state is client implementation specific
   and opaque to any server implementation.  For security, the
   serialized state MUST be integrity protected, MUST include a
   freshness indicator (e.g., a sequence number or a timestamp), and MAY
   additionally be encrypted.  These requirement can be satisfied, for
   example, by using COSE [RFC8152] with a key only known to the client.

4.1.  Intermediaries

   Tokens are a hop-by-hop feature: If a client makes a request to an
   intermediary, that intermediary needs to store the client's token
   (along with the client's transport address) while it makes a request
   to the next hop towards the origin server and waits for the response.

   An intermediary can be alleviated of storing the client's token and
   transport address by serializing this information along the request
   state into its own token to the next hop.  When the next hop returns
   the response, the intermediary can recover the information from the
   token and satisfy the client's outstanding request.

   The downside of this approach is that the intermediary, without
   keeping request state, is unable to use a cacheable response to
   satisfy multiple outstanding requests, which degrades efficiency.
   It is also unable to aggregate requests when it acts on behalf of
   multiple clients observing [RFC7641] the same resource (which is
   REQUIRED by RFC 7641).

   When using blockwise transfers [RFC7959], servers might not be able
   to distinguish blocks originating from different clients once they
   have been forwarded by an intermediary.  To ensure that this does not
   lead inconsistent resource state, a stateless intermediary MUST
   include the Request-Tag Option [I-D.ietf-core-echo-request-tag] with
   a value that uniquely identifies the originating endpoint in the
   intermediary namespace.

4.2.  Extended Tokens

   A client or intermediary in the client role that depends on support
   for extended tokens from the next hop to avoid keeping request state
   MUST perform a discovery of support (Section 2.2/Section 3.2) before



Hartke                   Expires March 14, 2019                 [Page 9]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


   it can be stateless.  This discovery MUST be performed in a stateful
   way, i.e., keeping state for the request (Figure 5): If the client
   was stateless from the start and the next hop doesn't support
   extended tokens, then any error message couldn't be processed as the
   state would neither be present at the client nor echoed back in the
   error message.

          +-----------------+    dummy request     +------------+
          |        |        |    with extended     |            |
          |        |        |        token         |            |
          |    .-<-+->------|=====================>|------.     |
          |   _|_           |                      |      |     |
          |  /   \ stored   |                      |      |     |
          |  \___/ state    |                      |      |     |
          |    |            |                      |      |     |
          |    '->-+-<------|<=====================|------'     |
          |        |        |     response with    |            |
          |        |        |    extended token    |            |
          |        |        |      echoed back     |            |
          |        |        |                      |            |
          |        |        |                      |            |
          |        |        |     request with     |            |
          |        |        |   serialized state   |            |
          |        |        |       as token       |            |
          |        +--------|=====================>|------.     |
          |                 |                      |      |     |
          |    look, no     |                      |      |     |
          |   state, ma!    |                      |      |     |
          |                 |                      |      |     |
          |        +--------|<=====================|------'     |
          |        |        |     response with    |            |
          |        v        |   token echoed back  |            |
          +-----------------+                      +------------+
                Client                                 Server

     Figure 5: Depending on Extended Tokens for Being Stateless First
            Requires a Successful Stateful Discovery of Support

4.3.  Message Transmission

   In the case of CoAP over UDP [RFC7252], a client can use confirmable
   or non-confirmable messages for requests.  When using confirmable
   messages, it needs to keep message exchange state for performing
   retransmissions and for handling Acknowledgement and Reset messages.
   When using non-confirmable messages, it can keep no message exchange
   state.  However, in either case the client needs to keep congestion
   control state.  That is, it needs to maintain state for each node it
   communicates with and, e.g., enforce NSTART.



Hartke                   Expires March 14, 2019                [Page 10]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


   In accordance with RFC 7252, a client must always be prepared to
   receive a separate response or non-confirmable response in reply to a
   request, regardless of the message type it used for that request.  If
   a separate response contains a valid authentication tag and freshness
   indicator in the token, the client MUST process the message as
   specified in Section 4.2 of RFC 7252; otherwise, it SHOULD reject the
   response as specified in Section 4.2 of RFC 7252.

5.  Security Considerations

   TODO.

6.  (Variant A:) IANA Considerations

6.1.  CoAP Signaling Option Number

   The following entries are added to the "CoAP Signaling Option
   Numbers" registry within the "CoRE Parameters" registry.

   +------------+--------+------------------------+-------------------+
   | Applies to | Number | Name                   | Reference         |
   +------------+--------+------------------------+-------------------+
   | 7.01       |    TBD | Extended-Token-Lengths | [[this document]] |
   +------------+--------+------------------------+-------------------+

   [[The three lowest available option numbers with the properties
   specified in Table 1 are 6, 8, and 10 at the time of writing.]]

7.  (Variant B:) IANA Considerations

7.1.  CoAP Option Number

   The following entries are added to the "CoAP Option Numbers" registry
   within the "CoRE Parameters" registry.

              +--------+----------------+-------------------+
              | Number | Name           | Reference         |
              +--------+----------------+-------------------+
              |    TBD | Extended-Token | [[this document]] |
              +--------+----------------+-------------------+

   [[The three lowest available option numbers with the properties
   specified in Table 2 are 19, 31, and 43 at the time of writing.]]








Hartke                   Expires March 14, 2019                [Page 11]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


7.2.  CoAP Signaling Option Number

   The following entries are added to the "CoAP Signaling Option
   Numbers" registry within the "CoRE Parameters" registry.

    +------------+--------+-----------------------+-------------------+
    | Applies to | Number | Name                  | Reference         |
    +------------+--------+-----------------------+-------------------+
    | 7.01       |    TBD | Extended-Token-Option | [[this document]] |
    +------------+--------+-----------------------+-------------------+

   [[The three lowest available option numbers with the properties
   specified in Table 3 are 6, 8, and 10 at the time of writing.]]

8.  References

8.1.  Normative References

   [I-D.ietf-core-echo-request-tag]
              Amsuess, C., Mattsson, J., and G. Selander, "Echo and
              Request-Tag", draft-ietf-core-echo-request-tag-02 (work in
              progress), June 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.





Hartke                   Expires March 14, 2019                [Page 12]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/info/rfc8323>.

8.2.  Informative References

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

Appendix A.  (Variant A:) Updated Message Formats

   This appendix illustrates the CoAP message formats updated with the
   new definition of the TKL field (Section 2).






























Hartke                   Expires March 14, 2019                [Page 13]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


A.1.  CoAP over UDP

                   0   1   2   3   4   5   6   7
                 +-------+-------+---------------+
                 |       |       |               |
                 |  Ver  |   T   |      TKL      |   1 byte
                 |       |       |               |
                 +-------+-------+---------------+
                 |                               |
                 |             Code              |   1 byte
                 |                               |
                 +-------------------------------+
                 |                               |
                 |                               |
                 |                               |
                 +-         Message ID          -+   2 bytes
                 |                               |
                 |                               |
                 |                               |
                 +-------------------------------+
                 \                               \
                 /              TKL              /   0-2 bytes
                 \          (extended)           \
                 +-------------------------------+
                 \                               \
                 /             Token             /   0 or more bytes
                 \                               \
                 +-------------------------------+
                 \                               \
                 /                               /
                 \                               \
                 /            Options            /   0 or more bytes
                 \                               \
                 /                               /
                 \                               \
                 +---------------+---------------+
                 |               |               |
                 |      15       |       15      |   1 byte (if payload)
                 |               |               |
                 +---------------+---------------+
                 \                               \
                 /                               /
                 \                               \
                 /            Payload            /   0 or more bytes
                 \                               \
                 /                               /
                 \                               \
                 +-------------------------------+



Hartke                   Expires March 14, 2019                [Page 14]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


A.2.  CoAP over TCP

                   0   1   2   3   4   5   6   7
                 +---------------+---------------+
                 |               |               |
                 |      Len      |      TKL      |   1 byte
                 |               |               |
                 +---------------+---------------+
                 \                               \
                 /              Len              /   0-2 bytes
                 \          (extended)           \
                 +-------------------------------+
                 |                               |
                 |             Code              |   1 byte
                 |                               |
                 +-------------------------------+
                 \                               \
                 /              TKL              /   0-2 bytes
                 \          (extended)           \
                 +-------------------------------+
                 \                               \
                 /             Token             /   0 or more bytes
                 \                               \
                 +-------------------------------+
                 \                               \
                 /                               /
                 \                               \
                 /            Options            /   0 or more bytes
                 \                               \
                 /                               /
                 \                               \
                 +---------------+---------------+
                 |               |               |
                 |      15       |       15      |   1 byte (if payload)
                 |               |               |
                 +---------------+---------------+
                 \                               \
                 /                               /
                 \                               \
                 /            Payload            /   0 or more bytes
                 \                               \
                 /                               /
                 \                               \
                 +-------------------------------+







Hartke                   Expires March 14, 2019                [Page 15]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


A.3.  CoAP over WebSockets

                   0   1   2   3   4   5   6   7
                 +---------------+---------------+
                 |               |               |
                 |       0       |      TKL      |   1 byte
                 |               |               |
                 +---------------+---------------+
                 |                               |
                 |             Code              |   1 byte
                 |                               |
                 +-------------------------------+
                 \                               \
                 /              TKL              /   0-2 bytes
                 \          (extended)           \
                 +-------------------------------+
                 \                               \
                 /             Token             /   0 or more bytes
                 \                               \
                 +-------------------------------+
                 \                               \
                 /                               /
                 \                               \
                 /            Options            /   0 or more bytes
                 \                               \
                 /                               /
                 \                               \
                 +---------------+---------------+
                 |               |               |
                 |      15       |       15      |   1 byte (if payload)
                 |               |               |
                 +---------------+---------------+
                 \                               \
                 /                               /
                 \                               \
                 /            Payload            /   0 or more bytes
                 \                               \
                 /                               /
                 \                               \
                 +-------------------------------+











Hartke                   Expires March 14, 2019                [Page 16]


Internet-DraftExtended Tokens and Stateless Clients in CoASeptember 2018


Author's Address

   Klaus Hartke
   Ericsson
   Torshamnsgatan 23
   Stockholm  SE-16483
   Sweden

   Email: klaus.hartke@ericsson.com










































Hartke                   Expires March 14, 2019                [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/