Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
CoRE Working Group K. Hartke
Updates: 7252, 8323 (if approved) December 6, 2019
Intended status: Standards Track
Expires: June 8, 2020
Extended Tokens and Stateless Clients
in the Constrained Application Protocol (CoAP)
This document provides considerations for alleviating CoAP clients
and intermediaries of keeping per-request state. To facilitate this,
this document additionally introduces a new, optional CoAP protocol
extension for extended token lengths.
This document updates RFCs 7252 and 8323.
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 June 8, 2020.
Copyright (c) 2019 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
2. Extended Tokens
2.1. Extended Token Length (TKL) Field
2.2. Discovering Support
2.2.1. Extended-Token-Length Capability Option
3. Stateless Clients
3.1. Serializing Client State
3.2. Using Extended Tokens
3.3. Transmitting Messages
4. Stateless Intermediaries
4.1. Observing Resources
4.2. Block-Wise Transfers
4.3. Gateway Timeouts
5. Security Considerations
5.1. Extended Tokens
5.2. Stateless Clients and Intermediaries
6. IANA Considerations
6.1. CoAP Signaling Option Number
7.1. Normative References
7.2. Informative References
Appendix A. Updated Message Formats
A.1. CoAP over UDP
A.2. CoAP over TCP
A.3. CoAP over WebSockets
The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful
application-layer protocol for constrained environments [RFC7228].
In CoAP, clients (or intermediaries in the client role) make requests
to servers (or intermediaries in the server role), which satisfy the
requests by returning responses.
While a request is ongoing, a client typically needs to keep some
state that it requires for processing the response when that arrives.
Identification of this state is done in CoAP by means of a token, an
opaque sequence of bytes chosen by the client and included in the
CoAP request, and that is returned by the server verbatim in any
resulting CoAP response (Figure 1).
+-----------------+ request with +------------+
| | | state identifier | |
| | | as token | |
| .-<-+->------|--------------------->|------. |
| _|_ | | | |
| / \ stored | | | |
| \___/ state | | | |
| | | | | |
| '->-+-<------|<---------------------|------' |
| | | response with | |
| v | token echoed back | |
Figure 1: Token as an Identifier for Request State
In some scenarios, it can be beneficial to reduce the amount of state
that is stored at the client at the cost of increased message sizes.
A client can opt into this by serializing (parts of) its state into
the token itself and then recovering this state from the token in the
Show full document text