One document matched: draft-ietf-core-coap-04.xml
<?xml version="1.0" encoding="us-ascii"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC2046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3542 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3542.xml">
<!ENTITY RFC3602 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3602.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml">
<!ENTITY RFC4279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC5996 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY RFC4309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4309.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY RFC4395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC4835 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4835.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY RFC5952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY RFC6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY I-D.bormann-6lowpan-6lowapp-problem SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-6lowpan-6lowapp-problem.xml">
<!ENTITY I-D.shelby-6lowapp-encoding SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-6lowapp-encoding.xml">
<!ENTITY I-D.frank-6lowapp-chopan SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.frank-6lowapp-chopan.xml">
<!ENTITY I-D.gold-6lowapp-sensei SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gold-6lowapp-sensei-00.xml">
<!ENTITY I-D.martocci-6lowapp-building-applications SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-martocci-6lowapp-building-applications-00.xml">
<!ENTITY I-D.sturek-6lowapp-smartenergy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-sturek-6lowapp-smartenergy-00.xml">
<!ENTITY I-D.moritz-6lowapp-dpws-enhancements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-moritz-6lowapp-dpws-enhancements-00.xml">
<!ENTITY I-D.shelby-core-coap-req SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shelby-core-coap-req-01.xml">
<!ENTITY I-D.nottingham-http-link-header SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nottingham-http-link-header-09.xml">
<!ENTITY I-D.cheshire-dnsext-multicastdns SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-cheshire-dnsext-multicastdns-11.xml">
<!ENTITY I-D.cheshire-dnsext-dns-sd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-cheshire-dnsext-dns-sd-06.xml">
<!ENTITY I-D.eggert-core-congestion-control SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-eggert-core-congestion-control-00.xml">
<!ENTITY I-D.ietf-core-observe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-observe-00.xml">
<!ENTITY I-D.ietf-core-block SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-block-00.xml">
<!ENTITY I-D.ietf-core-link-format SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-link-format-02.xml">
<!ENTITY I-D.oflynn-core-bootstrapping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-oflynn-core-bootstrapping-02.xml">
<!ENTITY I-D.ietf-tsvwg-iana-ports SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-iana-ports-09.xml">
<!ENTITY I-D.mcgrew-tls-aes-ccm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-tls-aes-ccm-00.xml">
<!ENTITY I-D.mcgrew-tls-aes-ccm-ecc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcgrew-tls-aes-ccm-ecc-01.xml">
<!ENTITY I-D.ietf-tls-rfc4347-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4347-bis.xml">
<!ENTITY PORT "5683">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-core-coap-04" ipr="trust200902">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Constrained Application Protocol (CoAP)</title>
<author fullname="Zach Shelby" initials="Z" surname="Shelby">
<organization>Sensinode</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>Finland</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<author initials="K" surname="Hartke" fullname="Klaus Hartke">
<organization>Universitaet Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63905</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>hartke@tzi.org</email>
</address>
</author>
<author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization>Universitaet Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>
<author fullname="Brian Frank" initials="B" surname="Frank">
<organization>SkyFoundry</organization>
<address>
<postal>
<street></street>
<city>Richmond, VA</city>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>brian@skyfoundry.com</email>
</address>
</author>
<date year="2011" />
<area>Applications</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>CoAP</keyword>
<keyword>Constrained Application Protocol</keyword>
<keyword>REST</keyword>
<abstract>
<t>This document specifies the Constrained Application Protocol (CoAP),
a specialized web transfer protocol for use with constrained networks
and nodes for machine-to-machine applications such as smart energy and
building automation. These constrained nodes often have 8-bit
microcontrollers with small amounts of ROM and RAM, while networks such
as 6LoWPAN often have high packet error rates and a typical throughput
of 10s of kbit/s. CoAP provides a method/response interaction model
between application end-points, supports built-in resource discovery,
and includes key web concepts such as URIs and content-types. CoAP
easily translates to HTTP for integration with the web while meeting
specialized requirements such as multicast support, very low overhead
and simplicity for constrained environments.</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="introduction" title="Introduction">
<t>The use of web services on the Internet has become ubiquitous in most
applications, and depends on the fundamental Representational State
Transfer (REST) architecture of the web.</t>
<t>The Constrained RESTful Environments (CoRE) working group aims at
realizing the REST architecture in a suitable form for the most
constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM)
and networks (e.g. 6LoWPAN). Constrained networks like 6LoWPAN support
the expensive fragmentation of IPv6 packets into small link-layer
frames. One design goal of CoRE has been to keep message overhead small,
thus limiting the use of fragmentation.</t>
<t>One of the main goals of CoRE is to design a generic web protocol for
the special requirements of this constrained environment, especially
considering energy, building automation and other M2M applications. The
goal of CoAP is not to blindly compress HTTP <xref target="RFC2616"/>,
but rather to realize a
subset of REST common with HTTP but optimized for M2M applications.
Although CoRE could be used for compressing simple HTTP interfaces, it
more importantly also offers features for M2M such as built-in
discovery, multicast support and asynchronous message exchanges.</t>
<t>This document specifies the Constrained Application Protocol (CoAP),
which easily translates to HTTP for integration with the existing web
while meeting specialized requirements such as multicast support, very
low overhead and simplicity for constrained environments and M2M
applications.</t>
<section anchor="features" title="Features">
<t>CoAP has the following main features:
<list style="symbols">
<t>Constrained web protocol fulfilling M2M requirements.</t>
<t>A stateless HTTP mapping, allowing proxies to be built providing
access to CoAP resources via HTTP in a uniform way or for HTTP
simple interfaces to be realized alternatively over CoAP.</t>
<t>UDP binding with reliable unicast and best-effort multicast
support.</t>
<t>Asynchronous message exchanges.</t>
<t>Low header overhead and parsing complexity.</t>
<t>URI and Content-type support.</t>
<t>Simple proxy and caching capabilities.</t>
<t>Optional resource discovery.</t>
<!-- Zach: Something about security? -->
</list></t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<!-- Zach: Any other useful RFCs to be familiar with? -->
<t>This specification requires readers to be familiar with all the terms
and concepts that are discussed in <xref target="RFC2616"/>. In addition,
this specification defines the following terminology:
<list style="hanging">
<t hangText="Immediate Response"><vspace />
An Immediate Response is included right in a CoAP
Acknowledgement (ACK) message that is sent to acknowledge receipt of
the Request for this Response (<xref target="immediate"/>).</t>
<t hangText="Deferred Response"><vspace />
When a Confirmable message carrying a Request is
acknowledged with an empty message (e.g., because the server doesn't
have the answer right away), a Deferred Response is sent later in a
separate message exchange (<xref target="deferred"/>). </t>
<t hangText="Critical"><vspace />
An option that would need to be understood by the end-point
receiving the message in order to properly process the message (<xref
target="critical-elective"/>). Note that the implementation
of critical options is, as the name "Option" implies,
generally optional: unsupported critical options lead to
rejection of the message.
</t>
<t hangText="Elective"><vspace />
An option that is intended be ignored by an end-point that
does not understand it, which nonetheless still can correctly process
the message (<xref target="critical-elective"/>).
</t>
<t hangText="Resource Discovery"><vspace />
The process where a CoAP client queries a server for its list
of hosted resources (i.e., links, <xref target="discovery"/>).
</t>
<t hangText="Intermediary"><vspace />There are two common forms of
intermediary: proxy and reverse proxy. In some cases, a single
intermediary might act as an origin server, proxy, or reverse proxy,
switching behavior based on the nature of each request.</t>
<t hangText="Proxy"><vspace />A "proxy" is an end-point
selected by a client,
usually via local configuration rules, to perform requests on behalf
of the client, doing any necessary translations. Some translations
are minimal, such as for proxy requests for "coap" URIs, whereas
other requests might require translation to and from entirely
different application-layer protocols.</t>
<t hangText="Reverse Proxy"><vspace />A "reverse proxy" is
an end-point that
acts as a layer above some other server(s) and satisfies requests
on behalf of these, doing any necessary translations. Unlike a
proxy, a reverse proxy receives requests as if it was the origin
server for the target resource; the requesting client will
not be aware that it is communicating with a reverse proxy.</t>
<!-- Additional terminology may be added as found necessary
in the document -->
</list>
</t>
<t>In this specification, the term "byte" is used in its now customary
sense as a synonym for "octet".</t>
<t>In this specification, the operator "^"
stands for exponentiation.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="protocol" title="Constrained Application Protocol">
<t>The interaction model of CoAP is similar to the client/server model
of HTTP. However, machine-to-machine interactions typically result in
a CoAP implementation acting in both client and server roles (called
an end-point). A CoAP request is equivalent to that of HTTP, and is
sent by a client to request an action (using a method code) on a
resource (identified by a URI) on a server. The server then
sends a response
with a response code; this response may include a resource
representation.</t>
<t>Unlike HTTP, CoAP deals with these interchanges asynchronously over
a datagram-oriented transport such as UDP. This is done using a layer of messages
that supports optional reliability (with exponential back-off). CoAP defines
four types of messages: Confirmable, Non-Confirmable,
Acknowledgement, Reset; method codes and response codes included in
some of these messages make them carry requests or responses.
The basic exchanges of the four types of messages
are transparent to the request/response interactions.</t>
<t>One could think of CoAP as using a two-layer approach, a
CoAP messaging layer used to deal with UDP and the asynchronous nature
of the interactions, and the request/response interactions using
Method and Response codes (see <xref target="fig-layers"/>).</t>
<figure anchor="fig-layers" title="Abstract layering of CoAP">
<artwork><![CDATA[
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| UDP |
+----------------------+
]]></artwork>
</figure>
<section title="Messaging Model">
<t>The CoAP messaging model is based on the exchange of messages over UDP between
end-points.</t>
<t>CoAP uses a short fixed-length binary header
(4 bytes) that may be followed by compact binary options and a payload. This message
format is shared by requests and responses.
The CoAP message format is specified in <xref target="syntax"/>.
Each message contains a Message ID used to detect duplicates and for optional reliability.</t>
<t>Reliability is provided by marking a message as Confirmable (CON). A Confirmable message is
retransmitted using a default timeout and
exponential back-off between retransmissions, until the
recipient sends an Acknowledgement message (ACK)
with the same Message ID (for example, 0x7d34); see <xref
target="fig-reliable"/>.
When a recipient is not able to process a Confirmable
message, it replies with a Reset message (RST) instead
of an Acknowledgement (ACK). </t>
<figure anchor="fig-reliable" title="Reliable message delivery">
<artwork><![CDATA[
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
]]></artwork>
</figure>
<t>A message that does not require reliable delivery, for
example each single measurement out of a stream of sensor
data, can be sent as a Non-confirmable message (NON).
These are not acknowledged, but still have a Message ID for
duplicate detection (<xref target="fig-unreliable"/>).</t>
<figure anchor="fig-unreliable" title="Unreliable message delivery">
<artwork><![CDATA[
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
]]></artwork>
</figure>
<t>See <xref target="messages"/> for details of CoAP messages.</t>
<t>
As CoAP is based on UDP, it also supports the use of multicast IP destination addresses,
enabling multicast CoAP requests. <xref target="multicast"/> discusses the proper use
of CoAP messages with multicast addresses and precautions for avoiding response congestion.</t>
<t>Several security modes are defined for CoAP in <xref target="security"/> ranging
from no security to certificate based security. The use of IPsec along with a binding
to DTLS are specified for securing the protocol.</t>
</section>
<section title="Request/Response Model">
<t>CoAP request and response semantics are carried in CoAP messages, which include
either a method or response code, respectively. Optional (or default) request and response information,
such as the URI and payload content-type are carried as CoAP options. A Token Option
is used to match responses to requests independently from the
underlying messages (<xref target="response-matching"/>).</t>
<t>A request is carried in a Confirmable (CON) or
Non-confirmable (NON)
message, and if immediately available, the response to a
request carried in a Confirmable message is carried in the resulting
Acknowledgement (ACK) message. This is called an immediate CoAP response, detailed in
<xref target="immediate"/>. Two examples for a basic GET request with immediate response are shown
in <xref target="example-immediate"/>.</t>
<figure anchor="example-immediate"
title="Two GET requests with immediate responses, one successful, one not found">
<artwork><![CDATA[
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.00 OK | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
]]></artwork>
</figure>
<t>If the server is not able to respond immediately to a
request carried in a Confirmable message, it simply responds with an empty Acknowledgement
message so that the client can stop retransmitting the request. When the
response is ready, the server sends it in a new Confirmable
message (which then in turn needs to be
acknowledged by the client). This is called a deferred
response, as illustrated in <xref target="example-deferred"/> and
described in more detail in <xref target="deferred"/>.</t>
<figure anchor="example-deferred" title="A GET request with a deferred response">
<artwork><![CDATA[
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Time Passes ...
| |
| CON [0x23bb] |
| 2.00 OK |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
]]></artwork>
</figure>
<t>CoAP makes use of HTTP GET, PUT, POST and DELETE methods, with the semantics specified
in <xref target="methods"/>. URI support in a server is
simplified as the client already parses the URI and splits it into
host, port, path and query components, making use of default values for efficiency. Response
codes correspond to a small subset of HTTP response codes with
a few CoAP specific
codes added, as defined in <xref target="response-codes"/>.</t>
</section>
<section title="Intermediaries and Caching">
<t>The protocol supports the caching of responses in order to efficiently fulfill
requests. Simple caching is enabled using freshness and validity information carried with
CoAP responses. A cache could be located in an end-point or an intermediary. Caching
functionality is specified in <xref target="caching"/>.</t>
<t>Proxying is useful in constrained networks for several reasons, including network
traffic limiting, to improve performance, to access resource of sleeping devices or
for security reasons. The proxying of requests on behalf of another CoAP end-point is supported in
the protocol. The URI of the resource to request is included in the request, while
the destination IP address is set to the proxy. See <xref target="proxying"/> for more
information on proxy functionality. </t>
<t>As CoAP was designed according to the REST architecture and thus
exhibits functionality similar to that of the HTTP protocol,
it is quite
straightforward to map between HTTP-CoAP or CoAP-HTTP. Such a mapping may be used to
realize an HTTP REST interface using CoAP, or for converting between HTTP and CoAP. This
conversion can be
carried out by a proxy, which converts the method or response code, content-type
and options to the corresponding HTTP feature. <xref
target="http"/> provides more detail about HTTP
mapping. </t>
</section>
<section title="Resource Discovery">
<t>Resource discovery is important for machine-to-machine interactions, and is supported
using the CoRE Link Format <xref target="I-D.ietf-core-link-format"/> as discussed in
<xref target="discovery"/>.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="syntax" title="Message Syntax">
<t>CoAP is based on the exchange of short messages which, by default,
are transported over UDP (i.e. each CoAP message occupies the data
section of one UDP datagram). CoAP may be used with Datagram
Transport Layer Security (DTLS) (see <xref target="dtls"/>). It could
also be used over other transports such as TCP or SCTP, the specification
of which is out of this document's scope.</t>
<section anchor="message-format" title="Message Format">
<t>CoAP messages are encoded in a simple binary format. A message
consists of a fixed-sized CoAP Header followed by options in
Type-Length-Value (TLV) format and a payload. The number of options
is determined by the header. The payload is made up of the bytes
after the options, if any; its length is calculated from the datagram
length.</t>
<figure anchor="fig-message-format" title="Message Format">
<artwork><![CDATA[
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 | OC | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
The fields in the header are defined as follows:
<list style="hanging">
<t hangText="Version (Ver):">2-bit unsigned integer. Indicates the
CoAP version number. Implementations of this specification MUST set
this field to 1. Other values are reserved for future versions.</t>
<t hangText="Type (T):">2-bit unsigned integer. Indicates
if this message is of type Confirmable (0), Non-Confirmable (1),
Acknowledgement (2) or Reset (3). See <xref target="messages"/> for
the semantics of these message types.</t>
<t hangText="Option Count (OC):">4-bit unsigned integer. Indicates
the number of options after the header. If set to 0, there are no
options and the payload (if any) immediately follows the header.
The format of options is defined below.</t>
<t hangText="Code:">8-bit unsigned integer. Indicates if the message
carries a request (1-31) or a response (64-191), or is empty (0).
(All other code values are reserved.)
In case of a request, the Code field indicates the Request Method;
in case of a response a Response Code. Possible values are maintained
in the <xref target="coap-code-registry">CoAP Code Registry</xref>.
See <xref target="requests-responses"/> for the semantics of requests
and responses.</t>
<t hangText="Message ID:">16-bit unsigned integer. Used for the
detection of message duplication, and to match messages of type
Acknowledgement/Reset and messages of type Confirmable. See <xref
target="messages"/> for Message ID generation rules and how
messages are matched.</t>
</list>
</t>
<t>While specific link layers make it beneficial to keep CoAP messages
small enough to fit into their link layer packets (see
<xref target="introduction"/>), this is a matter of implementation
quality. The CoAP specification itself provides only an upper bound to
the message size. A CoAP message, appropriately encapsulated, SHOULD
fit within a single IP packet (i.e., avoid IP fragmentation)
and MUST fit within a single IP datagram. If the Path MTU is not known
for a destination, an MTU of 1280 bytes SHOULD be assumed; if
nothing is known about the size of the headers, good upper
bounds are 1152 bytes for the message size and 1024 bytes for
the payload size.</t>
</section>
<section anchor="option-format" title="Option Format">
<t>Options MUST appear in order of their Option Number (see <xref
target="option-numbers"/>). A delta encoding is used between
options, with the Option Number for each Option calculated as
the sum of its Option Delta field and the Option Number of the
preceding Option in the message, if any, or zero otherwise.
Multiple options with the same Option Number can be included
by using an Option Delta of zero.
Following the Option Delta, each option has a Length field which
specifies the length of the Option Value. The Length field can be
extended by one byte for options with values longer than 14 bytes.
The Option Value immediately follows the Length field.</t>
<figure anchor="fig-option-format" title="Option Format">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Option Delta | Length | for 0..14
+---+---+---+---+---+---+---+---+
| Option Value ...
+---+---+---+---+---+---+---+---+
for 15..270:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Option Delta | 1 1 1 1 | Length - 15 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Option Value ...
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
<t>The fields in an option are defined as follows:
<list style="hanging">
<t hangText="Option Delta:">4-bit unsigned integer.
Indicates the difference between the Option Number of this option
and the previous option (or zero for the first option). In other
words, the Option Number is calculated by simply summing the
Option Delta fields of this and previous options before it. The
Option Numbers 14, 28, 42, ... are reserved for no-op options
when they are sent with an empty value (they are ignored)
and can be used as "fenceposts" if
deltas larger than 15 would otherwise be required.</t>
<t hangText="Length:">Indicates the length of the Option Value.
Normally Length is a 4-bit unsigned integer allowing value lengths
of 0-14 bytes. When the Length field is set to 15, another byte is
added as an 8-bit unsigned integer whose value is added to
the 15, allowing option value lengths of 15-270 bytes.</t>
</list>
</t>
<t>The length and format of the Option Value depends on the respective
option, which MAY define variable length values. Options defined in
this document make use of the following formats for option values:
<list style="hanging" hangIndent="7">
<t hangText="uint:">A non-negative integer which is represented in
network byte order using a variable number of bytes (see <xref
target="integer"/>).</t>
<t hangText="string:">A Unicode string which is encoded using
<xref target="RFC3629">UTF-8</xref> in
<xref target="RFC5198">Net-Unicode form</xref>.</t>
<t hangText="opaque:">An opaque sequence of bytes.</t>
</list>
</t>
<t>Option Numbers are maintained in the <xref
target="option-number-registry">CoAP Option Number Registry</xref>.
See <xref target="options"/> for the semantics of the options defined
in this document.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="messages" title="Message Semantics">
<t>CoAP messages are exchanged asynchronously between CoAP end-points.
They are used to transport CoAP requests and responses, the semantics
of which are defined in <xref target="requests-responses"/>.</t>
<t>As CoAP is bound to non-reliable transports
such as UDP, CoAP messages may arrive out of
order, appear duplicated, or go missing without notice. For this
reason, CoAP implements a lightweight reliability mechanism, without
trying to re-create the full feature set of a transport like TCP.
It has the following features:
<list style="symbols">
<t>Simple stop-and-wait retransmission reliability with exponential
back-off for "confirmable" messages.</t>
<t>Duplicate detection for both "confirmable" and "non-confirmable"
messages.</t>
<t>Multicast support.</t>
</list>
</t>
<section anchor="reliable" title="Reliable Messages">
<t>The reliable transmission of a message is initiated by marking
the message as "confirmable" in the CoAP header. A recipient MUST
acknowledge such a message with an acknowledgement message (or, if
it lacks context to process the message properly, MUST reject it
with a reset message). The sender retransmits the confirmable
message at exponentially increasing intervals, until it receives
an acknowledgement (or reset message), or runs out of attempts.</t>
<t>Retransmission is controlled by two things that a CoAP end-point
MUST keep track of for each confirmable message it sends while waiting
for an acknowledgement (or reset): a timeout and a
retransmission counter. For a new
confirmable message, the initial timeout is set to RESPONSE_TIMEOUT
and the retransmission counter is set to 0. When the timeout is triggered
and the retransmission counter is less than MAX_RETRANSMIT, the message
is retransmitted, the retransmission counter is incremented, and the
timeout is doubled. If the retransmission counter reaches
MAX_RETRANSMIT on a timeout, or if the end-point receives a reset
message, then the attempt to transmit the message is cancelled and
the application process informed of failure. On the other hand, if
the end-point receives an acknowledgement message in time,
transmission is considered successful.</t>
<t>An acknowledgement or reset message is related to a confirmable
message by means of a Message ID. The Message ID is a 16-bit
unsigned integer that is generated by the sender of a confirmable
message and included in the CoAP header. The Message ID MUST be
echoed in the acknowledgement or reset message by the recipient.
A CoAP end-point generates Message IDs by keeping a single Message
ID variable, which is changed each time a new confirmable message
is sent regardless of the destination address or port. The initial
variable value SHOULD be randomized. The same Message ID MUST NOT
be re-used within the potential retransmission window, calculated as
RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1) plus the expected
maximum round trip time.</t> <!--TODO: TIME_WAIT2, see also 11-->
<t>A recipient MUST be prepared to receive the same confirmable message
(as indicated by the Message ID) multiple times, for example, when
its acknowledgement went missing or didn't reach the original sender
before the first timeout. As a general rule that may be
relaxed based on the specific semantics of a message, the
recipient SHOULD acknowledge each
duplicate copy of a confirmable message using the same
acknowledgement or reset message, but SHOULD process any
request or response in the message only once.</t>
</section>
<section anchor="unreliable" title="Unreliable Messages">
<t>As a more lightweight alternative, a message can be transmitted
less reliably by marking the message as "non-confirmable". A
non-confirmable message MUST NOT be acknowledged or be rejected by
the recipient. If a recipient lacks context to process the message
properly, the message MUST be silently ignored.</t>
<t>There is no way to detect if a non-confirmable message was received
or not at the CoAP-level. A sender MAY choose to transmit a
non-confirmable message multiple times which, for this purpose,
specifies a Message ID as well. The same rules for generating
the Message ID apply.</t>
<!-- TODO: Explain that this is a separate space (or not). -->
<t>A recipient MUST be prepared to receive the same non-confirmable
message (as indicated by the Message ID) multiple
times. As a general rule that may be
relaxed based on the specific semantics of a message, the
recipient SHOULD silently ignore any duplicated non-confirmable
message, and SHOULD process any request or response in the message
only once.</t>
</section>
<section anchor="message-types" title="Message Types">
<t>The different types of messages are summarized below. The type of
a message is specified by the T field of the CoAP header.</t>
<t>Separate from the message type, a message may carry a
request, a response, or be empty. This is
signalled by the Code field in the CoAP header and is relevant to
the request/response model. <!--TODO: was: transparent???-->
Possible values for the Code field are
maintained by the <xref target="coap-code-registry"> CoAP Code
Registry</xref>.</t>
<t>An empty message has the Code field set to 0. The OC field SHOULD
be set to 0 and no bytes SHOULD be present after the Message ID
field. <!--TODO: really? diagnostics! --> The OC field and any those
bytes MUST be ignored by any
recipient.</t>
<section anchor="confirmable" title="Confirmable (CON)">
<t>Some messages require an acknowledgement. These messages are
called "Confirmable". When no packets are lost, each confirmable
message elicits exactly one return message of type Acknowledgement
or type Reset.</t>
<t>A confirmable message always carries either a request or
response and MUST NOT be empty.</t>
</section>
<section anchor="non-confirmable" title="Non-Confirmable (NON)">
<t>Some other messages do not require an acknowledgement. This is
particularly true for messages that are repeated regularly for
application requirements, such as repeated readings from a sensor
where eventual arrival is sufficient.</t>
<t>A non-confirmable message always carries either a request or
response, as well, and MUST NOT be empty.</t>
</section>
<section anchor="acknowledgement" title="Acknowledgement (ACK)">
<t>An Acknowledgement message acknowledges that a specific confirmable
message (identified by its Message ID) arrived. It does not
indicate success or failure of any encapsulated request.</t>
<t>The acknowledgement message MUST echo the Message ID of the
confirmable message, and MUST carry a response or be empty (see
<xref target="immediate"/> and <xref target="deferred"/>).</t>
</section>
<!-- TODO: Do we want requests in acks? Zach: I would say no. -->
<section anchor="reset" title="Reset (RST)">
<t>A Reset message indicates that a specific confirmable message was
received, but some context is missing to properly process it. This
condition is usually caused when the receiving node has rebooted and
has forgotten some state that would be required to interpret the
message.</t>
<t>A reset message MUST echo the Message ID of the confirmable
message, and MUST be empty.</t> <!--TODO: diagnostic???-->
</section>
</section>
<section anchor="multicast" title="Multicast">
<t>CoAP supports sending messages to multicast destination addresses.
Such multicast messages MUST be Non-Confirmable. Mechanisms for avoiding
congestion from multicast requests are being considered in <xref
target="I-D.eggert-core-congestion-control"/>.</t>
</section>
<section anchor="congestion" title="Congestion Control">
<t>Basic congestion control for CoAP is provided by the
exponential back-off mechanism in <xref
target="reliable"/>.
Further congestion control optimizations are
being considered and tested for CoAP <xref
target="I-D.eggert-core-congestion-control"/>.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="requests-responses" title="Request/Response Semantics">
<t>CoAP operates under a similar request/response model as HTTP: a CoAP
end-point in the role of a "client" sends one or more CoAP requests to
a "server", which services the requests by sending CoAP responses.
Unlike HTTP, requests and responses are not sent over a previously
established connection, but exchanged asynchronously over CoAP
messages.</t>
<section anchor="request-semantics" title="Requests">
<t>A CoAP request consists of the method to be applied to the resource,
the identifier of the resource, a payload and Internet media type
(if any), and optional meta-data about the request.</t>
<t>CoAP supports the basic methods of GET, POST, PUT, DELETE, which
are easily mapped to HTTP. They have the same properties of safe (only
retrieval) and idempotent (you can invoke it multiple times with the
same effects) as HTTP (see Section 9.1 of <xref target="RFC2616"/>).
The GET method is safe, therefore it MUST NOT take any other action
on a resource other than retrieval. The GET, PUT and DELETE methods
MUST be performed in such a way that they are idempotent. POST is not
idempotent, because its effect is determined by the origin server and
dependent on the target resource; it usually results in a new resource
being created or the target resource being updated.</t>
<t>A request is initiated by setting the Code field in the CoAP header
of a confirmable or a non-confirmable message to a Method Code and
including request information.</t>
</section>
<section anchor="response-semantics" title="Responses">
<t>After receiving and interpreting a request, a server responds
with a CoAP response, which can be matched to the request by means
of a client-generated token.</t>
<t>A response is identified by the Code field in the CoAP
header being set
to a Response Code. Similar to the HTTP Status Code, the CoAP Response
Code indicates the result of the attempt to understand and satisfy the
request. These codes are fully defined in
<xref target="response-codes"/>. The Response Code numbers to be set
in the Code field of the CoAP header are maintained in the
<xref target="coap-code-registry-responses">CoAP Response Code
Registry</xref>.</t>
<figure title="Structure of a Response Code" anchor="response-code"><artwork><![CDATA[
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|class| detail |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The upper three bits of the 8-bit Response Code number define the
class of response. The lower five bits do not have any categorization
role; they give additional detail to the overall class (<xref
target="response-code"/>). There are 3 classes:
<list style="hanging">
<t hangText="2 - Success:">The request was successfully received,
understood, and accepted.</t>
<t hangText="4 - Client Error:">The request contains bad syntax or
cannot be fulfilled.</t>
<t hangText="5 - Server Error:">The server failed to fulfill an
apparently valid request.</t>
</list>
The response codes are designed to be extensible: Response Codes in
the Client Error and Server Error class that are unrecognized by an
end-point MUST be treated as being equivalent to the generic Response
Code of that class. However, there is no generic Response Code
indicating success, so a Response Code in the Success class that is
unrecognized by an end-point can only be used to determine that the
request was successful without any further details.</t>
<t>As a human readable notation for specifications and
protocol diagnostics, the numeric value of a response
code is indicated
by giving the upper three bits in decimal, followed by a
dot and then the lower five bits in a two-digit decimal. E.g., "Not
Found" is written as 4.04 -- indicating a value of hexadecimal
0x84 or decimal 132. In other words, the dot "." functions as
a short-cut for "*32+".</t>
<t>Responses can be sent in multiple ways, which are defined below.</t>
<section anchor="immediate" title="Immediate">
<t>In the most basic case, the response is carried directly in the
acknowledgement message that acknowledges the request (which
requires that
the request was carried in a confirmable message). This is called an
"immediate" response.</t>
<t>The response is returned in the acknowledgement message
independent of whether the response indicates success or failure.
In effect, the response is piggy-backed on the acknowledgement
message, so no separate message is required to both acknowledge
that the request was received and return the response.</t>
</section>
<section anchor="deferred" title="Deferred">
<t>It may not be possible to return an immediate response in all
cases. For example, a server might need longer to obtain the
representation of the resource requested than it can wait sending
back the acknowledgement message, without risking the client to
repeatedly retransmit the request message.</t>
<t>The server maybe initiates the attempt to obtain the resource representation
and times out an acknowledgement timer, or it immediately sends an
acknowledgement knowing in advance that there will be no immediate
response. The acknowledgement effectively is a promise
that the request will be acted upon.</t>
<t>When the server finally has obtained the resource representation,
it sends the response. To ensure that this message is not lost, it
is again sent as a confirmable message and answered by the client
with an acknowledgement, echoing the new Message ID chosen by
the server.</t>
<t>(Note that, as the underlying datagram transport may not be
sequence-preserving, the confirmable message carrying the
response may actually arrive before or after the
acknowledgement message for the request.)</t>
<t>For a deferred exchange, both the acknowledgement to the confirmable request and the
acknowledgement to the confirmable response MUST be an empty message,
i.e. one that carries neither a request nor a response.</t>
</section>
<section anchor="non-confirmable-responses" title="Non-Confirmable">
<t>If the request message is non-confirmable, then the response
SHOULD be returned in a non-confirmable message as well. However,
an end-point MUST be prepared to receive a non-confirmable response
(preceded or followed an empty acknowledgement message) in reply to a confirmable
request, or a confirmable response in reply to a non-confirmable
request.</t>
</section>
</section>
<section anchor="response-matching" title="Request/Response Matching">
<t>Regardless of how a response is sent, it is matched to the
request by means of a token that is included by the client in the
request. The token MUST be echoed by the server in any resulting
response without modification.</t>
<t>The exact rules for matching a response to a request are as
follows:
<list style="numbers">
<t>For requests sent in a unicast message, the source of the
response MUST match the destination of the
original request. How this is determined depends on the security
mode used (see <xref target="security"/>): With NoSec, the IP
address and port number of the request destination and response source must match.
With other security modes, in addition <!--TODO: really? -->
to the IP address and UDP
port matching, the request and response MUST have the same
security context.</t>
<t>In an immediate response, both the Message ID of the
confirmable request and the acknowledgement, and the token of the
response and original request MUST match. In a deferred response,
just the token of the response and original request MUST match.</t>
</list>
</t>
<t>The client SHOULD generate tokens in a way that tokens currently
in use are unique. An end-point receiving a token MUST treat it as
opaque and make no assumptions about its format. (Note that
there is a default value for the Token Option, so every
message carries a token, even if it is not explicitly
expressed in a CoAP option.)</t>
<t>In case a confirmable message carrying a response is unexpected (i.e. the client is
not waiting for a response with the specified address and/or token), the confirmable
response SHOULD be rejected with a reset message and MUST NOT be
acknowledged.</t> <!--TODO: This is the only place where
we break strict layering? -->
</section>
<section anchor="option-semantics" title="Options">
<t>Both requests and responses may include a list of one or more
options. For example, the URI in a request is transported in several
options, and meta-data that would be carried in an HTTP header in
HTTP is supplied as options as well.</t>
<t>CoAP defines a single set of options that are used in both requests
and responses:
<list style="symbols">
<t>Content-Type</t>
<t>Etag</t>
<t>Location-Path</t>
<t>Max-Age</t>
<t>Token</t>
<t>Uri-Host</t>
<t>Uri-Path</t>
<t>Uri-Port</t>
<t>Proxy-Uri</t>
<t>Uri-Query</t>
</list>
The semantics of these options along with their properties are defined
in <xref target="options"/>.</t>
<t>Not all options have meaning with all methods and response codes.
The possible options for methods and response codes are defined in
<xref target="methods"/> and <xref target="response-codes"/>
respectively. In case an option has no meaning, it SHOULD NOT be
included by the sender and MUST be ignored by the recipient.</t>
<!-- TODO: vs. critical? -->
<section anchor="critical-elective" title="Critical/Elective">
<t>Options fall into one of two classes: "critical" or "elective".
The difference between these is how an option unrecognized by an
end-point is handled:
<list style="symbols">
<t>Upon reception, unrecognized options of class "elective" MUST
be silently ignored.</t>
<t>Unrecognized options of class "critical" that occur in a
confirmable request MUST cause the return of a 4.02 (Bad
Option) response. This response SHOULD include a
human-readable error message describing the unrecognized
option(s) (see <xref target="payload-semantics"/>).</t>
<t>Unrecognized options of class "critical" that occur in a
confirmable response SHOULD cause the response to be rejected
with a reset message.</t> <!--TODO: DIAGNOSTICS -->
<t>Unrecognized options of class "critical" that occur in a
non-confirmable message MUST cause the message be silently
ignored.</t>
</list>
</t>
<t>Note that, whether critical or elective, an option is never
"mandatory" (it is always optional): These rules are defined in
order to enable implementations to reject options they do not
understand or implement.</t>
</section>
<section anchor="option-length" title="Length">
<t>Option values are defined to have a specific length, often in the form
of an upper and lower bound. If the length of an option value in a request
is outside the defined range, that option MUST be treated like an
unrecognized option (see <xref target="critical-elective"/>).</t>
</section>
<section anchor="option-defaults" title="Default Values">
<t>Options may be defined to have a default value. If the
value of option is intended to be this default value, the
option SHOULD NOT be included in the message.
If the option is not present, the default value MUST be assumed.</t>
<!-- In diesem Fall ist es nicht schlimm, wenn sie keine
Bedeutung hat. -->
</section>
<section anchor="repeated-options" title="Repeating Options">
<t>Each definition of an option specifies whether it is
defined to occur only at most once or whether it can occur
multiple times.
If a message includes an option with more instances than the
option is defined for,
the additional option instances MUST be treated like an unrecognized option
(see <xref target="critical-elective"/>).</t>
</section>
<section anchor="option-numbers" title="Option Numbers">
<t>Options are identified by an option number. Odd numbers indicate
a critical option, while even numbers indicate an elective option.
</t>
<t>The numbers 14, 28, 42, ... are reserved for "fenceposting", as
described in <xref target="option-format"/>.
As these option numbers are even, they stand for elective
options, and unless assigned a meaning, these MUST be
silently ignored.</t>
<t>The option numbers for the options defined in this document are
listed in the <xref target="option-number-registry">CoAP Option
Number Registry</xref>.</t>
</section>
</section>
<section anchor="payload-semantics" title="Payload">
<t>Both requests and responses may include payload, depending on the
method or response code respectively. Methods with payload are PUT and
POST, and the response codes with payload are 2.00 (OK) and the error
codes.</t>
<t>The payload of PUT, POST and 2.00 (OK) is typically a resource
representation. Its format is specified by the Internet media type
given by the Content-Type Option. A default value of "text/plain;
charset=utf-8" is assumed in the absence of this option.</t>
<t>A response with a code indicating a Client or Server Error SHOULD
include a brief human-readable diagnostic message as payload, explaining the
error situation. This diagnostic message MUST be encoded using
<xref target="RFC3629">UTF-8</xref>, more specifically using <xref
target="RFC5198">Net-Unicode form</xref>. The Content-Type Option has
no meaning and SHOULD NOT be included.</t>
<t>If a method or response code is not defined to have a payload,
then the sender SHOULD NOT include one, and the recipient MUST ignore
it.</t>
</section>
<section anchor="caching" title="Caching">
<t>CoAP nodes MAY cache responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests.</t>
<t>The goal of caching in CoAP is to reuse a prior response message
to satisfy a current request. In some cases, a stored response can
be reused without the need for a network request, reducing latency
and network round-trips; a "freshness" mechanism is used for this
purpose (see <xref target="freshness-model"/>).
Even when a new request is required, it is often possible to reuse
the payload of a prior response to satisfy the request, thereby
reducing network bandwidth usage; a "validation" mechanism is
used for this purpose (see <xref target="validation-model"/>).</t>
<!-- Response Cacheability -->
<t>Unlike HTTP, the cacheability of CoAP responses does not depend
on the request method, but the Response Code. The cacheability of
each Response Code is defined along the Response Code definitions
in <xref target="response-codes"/>. Response Codes that indicate
success and are unrecognized by an end-point MUST NOT be cached.</t>
<!-- Constructing Responses from Caches -->
<t>For a presented request, a CoAP node MUST NOT use a stored
response, unless:
<list style="symbols">
<t>the presented request method and that used to obtain the stored response
match,</t>
<t>all options match between those in the presented request
and those of the request
used to obtain the stored response (which includes the request
URI), except that there is no need for a match of the Token,
Max-Age, or Etag request option(s), and</t>
<t>the stored response is either fresh or successfully
validated as defined below.</t>
</list>
</t>
<section anchor="freshness-model" title="Freshness Model">
<t>When a response is "fresh" in the cache, it can be used to
satisfy subsequent requests without contacting the origin server,
thereby improving efficiency.</t>
<t>The mechanism for determining freshness is for an origin server
to provide an explicit expiration time in the future, using the
Max-Age Option (see <xref target="max-age"/>). The Max-Age Option
indicates that the response is to be considered not fresh after its
age is greater than the specified number of seconds.</t>
<t>As the Max-Age Option defaults to a value of 60, if it is
not present in a cacheable response,
then the response is considered not fresh after its age is greater
than 60 seconds. If an origin server wishes to prevent caching,
it MUST explicitly include a Max-Age Option with a value of zero
seconds.</t>
<t>In general, the origin server end-point is responsible for
determining the Max-Age value. However, in some cases a client
might need to influence freshness calculation. It can do this by
including the Max-Age Option in a request. While this option
value does not take part in the request matching, this indicates that
the client is requesting a response whose remaining lifetime
is no less than the specified time in seconds.</t>
</section>
<section anchor="validation-model" title="Validation Model">
<t>When an end-point has one or more stored responses for a GET
request, but cannot use any of them (e.g., because they are not
fresh), it can use the Etag Option in the GET request to give the
origin server an opportunity to both select a stored response to
be used, and to update its freshness. This process is known as
"validating" or "revalidating" the stored response.</t>
<t>When sending such a request, the client SHOULD add an Etag
Option specifying the entity-tag for each stored response that
is applicable.</t>
<t>A 2.03 (Valid) response
indicates the stored response identified by the entity-tag given
in the response's Etag Option can be reused, after updating its
freshness with the value of the Max-Age Option that is included with
the response (see <xref target="valid"/>).</t>
<t>Any other response code indicates that none of the stored
responses nominated in the request is suitable. Instead, the
response SHOULD be used to satisfy the request and MAY replace
the stored response.</t>
</section>
</section>
<section anchor="proxying" title="Proxying">
<t>CoAP distinguishes between requests to an origin server and a
request made through a proxy. A proxy is a CoAP end-point that can
be tasked by CoAP clients to perform requests on their behalf.
This may be useful, for example, when the request could otherwise
not be made, or
to service the response from a cache in order to reduce response
time and network bandwidth or energy consumption.</t>
<t>CoAP requests to a proxy are made as normal confirmable or
non-confirmable requests to the proxy end-point, but specify the
request URI in a different way: The request URI in a proxy request
is specified as a string in the Proxy-Uri Option (see <xref
target="proxy-uri"/>), while the request URI in a request to an origin
server is split into the Uri-Host, Uri-Port, Uri-Path and Uri-Query
Options (see <xref target="uri-options"/>).</t>
<t>When a proxy request is made to an end-point and the end-point is
unwilling or unable to act as proxy for the request URI, it MUST
return a 5.05 (Proxying Not Supported) response. If the authority
(host and port) is recognized as identifying the proxy end-point,
then the request MUST be treated as a local request.</t>
<t>Unless a proxy is configured to forward the proxy request
to another proxy,
it MUST translate the request as follows: The origin server's
IP address and port are determined by the authority component of the
request URI, and the request URI is decoded and split into the
Uri-Host, Uri-Port,
Uri-Path and Uri-Query Options.</t>
<t>All options present in a proxy request MUST be processed at
the proxy. Critical options in a request that are not recognized
by the proxy MUST lead to a 4.02 (Bad Option) response being
returned by the proxy. Elective options not recognized by the
proxy MUST NOT be forwarded to the origin server. Similarly,
critical options in a response that are not recognized by the
proxy server MUST lead to a 5.02 (Bad Gateway) response.
Again, elective options that are not recognized MUST NOT be forwarded.</t>
<t>If the proxy does not employ a cache, then it simply forwards the
translated request to the determined destination. Otherwise, if it
does not have a stored response that matches the translated request and
is considered fresh, then it needs to refresh its cache according
to <xref target="caching"/>.</t>
<t>If the request to the destination times out, then a 5.04 (Gateway
Timeout) response MUST be returned. If the request to the destination
returns an response that cannot be processed by the proxy,
then a 5.02 (Bad Gateway) response MUST be
returned. Otherwise, the proxy returns the response to the client.</t>
<t>If a response is generated out of a cache, it MUST be
generated with a max-age option that does not extend the max-age
originally set by the server, considering the time the
resource representation spent in the cache.
E.g., the Max-Age option could be adjusted by the proxy for each
response using the formula: proxy-max-age = original-max-age -
cache-age. For example if a request is made to a proxied resource that
was refreshed 20 seconds ago and had an original Max-Age of 60 seconds,
then that resource's proxied Max-Age is now 40 seconds.</t>
</section>
<section anchor="methods" title="Method Definitions">
<t>In this section each method is defined along with its behavior.
A request with an unrecognized or unsupported Method Code MUST generate
a 4.05 (Method Not Allowed) response.</t>
<!-- should be immediate or at least not deferred? -->
<section anchor="get" title="GET">
<t>The GET method retrieves a representation for the
information that currently corresponds to the resource
identified by the request URI. If the request includes an Etag
Option, the GET method requests that Etag be validated and that
the representation be transferred only if validation failed.
Upon success a 2.00 (OK) or 2.03 (Valid) response SHOULD be
sent.</t>
<t>The GET method is safe and idempotent. An
implementation MAY relax the requirement to answer all
retransmissions of a request with the same response (<xref
target="reliable"/>), obviating the need to maintain state
for Message IDs.
</t>
</section>
<section anchor="post" title="POST">
<t>The POST method requests that the representation enclosed in the
request be processed. The actual function performed by the POST
method is determined by the origin server and dependent on the
target resource. It usually results in a new resource being created
or the target resource being updated.</t>
<t>If a resource has been created on the server, a 2.01 (Created)
response that includes the URI of the new resource in a
sequence of one or more Location-Path Options
SHOULD be returned. If the POST succeeds but does not result
in a new resource being created on the server, a 2.04 (Changed)
response SHOULD be returned.</t>
<t>If the request passes through a cache that has one or more
stored responses for the request URI, those stored responses SHOULD
be marked as stale.</t>
<t>POST is neither safe nor idempotent and generally requires the full
deduplication support from the message layer.</t>
</section>
<section anchor="put" title="PUT">
<t>The PUT method requests that the resource identified by the
request URI be updated or created with the enclosed representation.
The representation format is specified by the media type given in
the Content-Type Option.</t>
<t>If a resource exists at the request URI the enclosed
representation SHOULD be considered a modified version of that
resource, and a 2.04 (Changed) response SHOULD be returned.
If no resource exists then the server MAY create a new resource
with that URI, resulting in a 2.01 (Created) response.
If the resource could not be created or modified, then an
appropriate error response code SHOULD be sent.</t>
<t>If the request passes through a cache that has one or more stored
responses for the request URI, those stored responses SHOULD be
marked as stale.</t>
<t>PUT is not safe, but idempotent. An implementation MAY
relax the message layer deduplication support and process duplicate
transmissions of the request as separate requests.</t>
</section>
<section anchor="delete" title="DELETE">
<t>The DELETE method requests that the resource identified by the
request URI be deleted. A 2.02 (Deleted) response SHOULD be
sent on success or in case the resource did not exist before the
request.</t> <!-- this is different from HTTP! -->
<t>If the request passes through a cache and the request URI
identifies one or more currently stored responses, those
entries SHOULD be treated as stale.</t>
<t>DELETE is not safe, but idempotent. An implementation MAY
relax the message layer deduplication support and process duplicate
transmissions of the request as separate requests.</t>
</section>
</section>
<section anchor="response-codes" title="Response Code Definitions">
<t>Each response code is described below, including any options
required in the response. Where appropriate, some of the codes will be specified
in regards to related response codes in HTTP <xref
target="RFC2616"/>; this does not mean that any such
relationship modifies the HTTP mapping specified in <xref target="http"/>.</t>
<section anchor="success" title="Success 2.xx">
<t>This class of status code indicates that the clients request
was successfully received, understood, and accepted.</t>
<section anchor="ok" title="2.00 OK">
<t>Like HTTP 200 "OK", but only used in response to GET requests.</t>
<t>The payload returned with the response is a representation
of the target resource. The representation format is specified
by the media type given in the Content-Type Option.</t>
<t>This response is cacheable: Caches can use the Max-Age Option
to determine freshness (see <xref target="freshness-model"/>)
and (if present) the Etag Option for validation (see <xref
target="validation-model"/>).</t>
</section>
<section anchor="created" title="2.01 Created">
<t>Like HTTP 201 "Created", but only used in response to POST and PUT
requests.</t>
<t>If the response includes the Location-Path Option, the value of
the option specifies the location at which the resource was
created. Otherwise, the resource was created at the request
URI. A cache SHOULD mark any stored response for the location
as not fresh.</t>
<t>This response is not cacheable.</t>
</section>
<section anchor="deleted" title="2.02 Deleted">
<t>Like HTTP 204 "No Content", but only used in response to DELETE
requests.</t>
<t>This response is not cacheable.</t>
</section>
<section anchor="valid" title="2.03 Valid">
<t>Related to HTTP 304 "Not Modified", but only used to
indicate that the response
identified by the entity-tag identified by the included Etag Option
is valid. Accordingly, the response MUST include
an Etag Option.</t>
<t>When a cache receives a 2.03 (Valid) response, it needs to update
the stored response with the value of the Max-Age Option included
in the response (see <xref target="validation-model"/>).</t>
</section>
<section anchor="changed" title="2.04 Changed">
<t>Like HTTP 204 "No Content", but only used in response to POST and PUT
requests.</t>
<t>This response is not cacheable.</t>
</section>
</section>
<section anchor="client-error" title="Client Error 4.xx">
<t>This class of response code is intended for cases in which the
client seems to have erred. These response codes are applicable to
any request method.</t>
<t>The server SHOULD include a brief human-readable message as payload,
as detailed in <xref target="payload-semantics"/>.</t>
<t>Responses of this class are cacheable: Caches can use the
Max-Age Option to determine freshness (see <xref
target="freshness-model"/>). They cannot be validated.</t>
<section anchor="bad-request" title="4.00 Bad Request">
<t>Like HTTP 400 "Bad Request".</t>
</section>
<section anchor="unauthorized" title="4.01 Unauthorized">
<t>The client is not authorized to perform the requested action.
The client SHOULD NOT repeat the request without
previously improving its
authentication status to the server. Which specific mechanism
can be used for this is outside
this document's scope; see also <xref target="security"/>.</t>
</section>
<section anchor="bad-option" title="4.02 Bad Option">
<t>The request could not be understood by the server due to one
or more unrecognized or malformed critical options. The client
SHOULD NOT repeat the request without modification.</t>
</section>
<section anchor="forbidden" title="4.03 Forbidden">
<t>Like HTTP 403 "Forbidden".</t>
</section>
<section anchor="not-found" title="4.04 Not Found">
<t>Like HTTP 404 "Not Found".</t>
</section>
<section anchor="method-not-allowed" title="4.05 Method Not Allowed">
<t>Like HTTP 405 "Method Not Allowed", but with no
parallel to the "Accept" header field.</t>
</section>
<section anchor="request-entity-too-large" title="4.13 Request Entity Too Large">
<t>Like HTTP 413 "Request Entity Too Large".</t>
</section>
<section anchor="unsupported-media-type" title="4.15 Unsupported Media Type">
<t>Like HTTP 415 "Unsupported Media Type".</t>
</section>
</section>
<section anchor="server-error" title="Server Error 5.xx">
<t>This class of response code indicates cases in which the server
is aware that it has erred or is incapable of performing the
request. These response codes are applicable to any request
method.</t>
<t>The server SHOULD include a human-readable message as payload,
as detailed in <xref target="payload-semantics"/>.</t>
<t>Responses of this class are cacheable: Caches can use the
Max-Age Option to determine freshness (see <xref
target="freshness-model"/>). They cannot be validated.</t>
<section anchor="internal-server-error" title="5.00 Internal Server Error">
<t>Like HTTP 500 "Internal Server Error".</t>
</section>
<section anchor="not-implemented" title="5.01 Not Implemented">
<t>Like HTTP 501 "Not Implemented".</t>
</section>
<section anchor="bad-gateway" title="5.02 Bad Gateway">
<t>Like HTTP 502 "Bad Gateway".</t>
</section>
<section anchor="service-unavailable" title="5.03 Service Unavailable">
<t>Like HTTP 503 "Service Unavailable", but using the Max-Age Option in place of the
"Retry-After" header field.</t>
</section>
<section anchor="gateway-timeout" title="5.04 Gateway Timeout">
<t>Like HTTP 504 "Gateway Timeout".</t>
</section>
<section anchor="proxying-not-supported" title="5.05 Proxying Not Supported">
<t>The server is unable or unwilling to act as a proxy for
the URI specified in the Proxy-Uri Option (see <xref
target="proxy-uri"/>).</t>
</section>
</section>
</section>
<section anchor="options" title="Option Definitions">
<t>The individual CoAP options are summarized in <xref
target="tab-options"/> and explained below.</t>
<texttable anchor="tab-options" title="Options">
<ttcol align="right">No.</ttcol>
<ttcol align="left">C/E</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Format</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="left">Default</ttcol>
<c>1</c> <c>C</c><c>Content-Type</c> <c>uint</c> <c>1-2 B</c> <c>0</c>
<c>2</c> <c>E</c><c>Max-Age</c> <c>uint</c> <c>0-4 B</c> <c>60</c>
<c>3</c> <c>C</c><c>Proxy-Uri</c> <c>string</c><c>1-270 B</c><c>(none)</c>
<c>4</c> <c>E</c><c>Etag</c> <c>opaque</c><c>1-4 B</c> <c>(none)</c>
<c>5</c> <c>C</c><c>Uri-Host</c> <c>string</c><c>1-270 B</c><c>(see below)</c>
<c>6</c> <c>E</c><c>Location-Path</c><c>string</c><c>1-270 B</c><c>(none)</c>
<c>7</c> <c>C</c><c>Uri-Port</c> <c>uint</c> <c>0-2 B</c> <c>(see below)</c>
<c>9</c> <c>C</c><c>Uri-Path</c> <c>string</c><c>1-270 B</c><c>(none)</c>
<c>11</c><c>C</c><c>Token</c> <c>opaque</c><c>1-8 B</c> <c>(empty)</c>
<c>15</c><c>C</c><c>Uri-Query</c> <c>string</c><c>1-270 B</c><c>(none)</c>
</texttable>
<section anchor="token" title="Token">
<t>The Token Option is used to match a response with a request.
Every request has a client-generated token which the server MUST
echo in any response.</t>
<t>A token is intended for use as a client-local identifier for
differentiating between concurrent requests. A client SHOULD
generate tokens in a way that tokens currently in use are unique.
An end-point receiving a token MUST treat it as opaque and make
no assumptions about its format.</t>
<t>A default value of a zero-length token is assumed in the absence
of the option.</t>
<t>This option is "critical". It MUST NOT occur more than once.</t>
</section>
<section anchor="uri-options" title="Uri-Host, Uri-Port, Uri-Path and Uri-Query">
<t>The Uri-Host, Uri-Port, Uri-Path and Uri-Query Options are used
to specify the target resource of a request to a CoAP origin server. The
options encode the different components of the request URI in a way
that no percent-encoding is visible in the option values
(except for Uri-Query) and that the full URI can be
reconstructed at any involved end-point. The syntax of CoAP URIs is
defined in <xref target="uri"/>.</t>
<t>The steps for parsing URIs into options is defined in
<xref target="uri-parsing"/>. These steps result in zero or more
Uri-Host, Uri-Port, Uri-Path and Uri-Query Options being included
in a request, where each option holds the following values:
<list style="symbols">
<t>the Uri-Host Option specifies the Internet host of the resource
being requested,</t>
<t>the Uri-Port Option specifies the port number of the resource,</t>
<t>each Uri-Path Option specifies one segment of the absolute path
to the resource, and</t>
<t>the Uri-Query Option specifies the query.</t>
</list>
Note: Fragments (<xref target="RFC3986"/>, Section 3.5) are not
part of the request URI and thus will not be transmitted in a CoAP
request.</t>
<t>The default value of the Uri-Host Option is the IP literal
representing the destination IP address of the request message.
Likewise, the default value of the Uri-Port Option is the
destination UDP port.</t>
<t>The Uri-Path Option can contain any character sequence. No
percent-encoding is performed. The value MUST NOT be "." or ".."
(as the request URI must be resolved before parsing it into
options).</t>
<t>The steps for constructing the request URI from the options are
defined in <xref target="uri-constructing"/>. Note that an
implementation does not necessarily have to construct the URI;
it can simply look up the target resource by looking at the
individual options.</t>
<t>Examples can be found in <xref target="uri-examples"/>.</t>
<t>All of the options are "critical". Uri-Host, Uri-Port and
Uri-Query MUST NOT occur more than once; Uri-Path MAY occur
one or more times.</t>
</section>
<section anchor="proxy-uri" title="Proxy-Uri">
<t>The Proxy-Uri Option is used to make a request to a proxy (see
<xref target="proxying"/>). The proxy is requested to forward the
request or service it from a valid cache, and return the
response.</t>
<t>The option value is an absolute-URI (<xref target="RFC3986"/>,
Section 4.3). In case the absolute-URI doesn't fit within a single
option, the Proxy-Uri Option MAY be included multiple times in a
request such that the concatenation of the values results in the
single absolute-URI.</t>
<t>All but the last instance of the Proxy-Uri Option MUST have a
value with a length of 270 bytes, and the last instance MUST NOT
be empty.</t>
<t>Note that the proxy MAY forward the request on to another proxy
or directly to the server specified by the absolute-URI.
In order to avoid request loops, a proxy MUST be able to recognize
all of its server names, including any aliases, local variations,
and the numeric IP addresses.</t>
<t>An end-point receiving a request with a Proxy-Uri Option that
is unable or unwilling to act as a proxy for the request MUST
cause the return of a 5.05 (Proxying Not Supported) response.</t>
<t>This option is "critical". It MAY occur one or more times and
MUST take precedence over any of the Uri-Host, Uri-Port, Uri-Path
or Uri-Query options (which MUST NOT be included at the same
time).</t>
</section>
<section anchor="content-type" title="Content-Type">
<t>The Content-Type Option indicates the representation format
of the message payload. The representation format is given as a
numeric media type identifier that is defined in the <xref
target="media-type-registry">CoAP Media Type registry</xref>.
A default value of 0 (meaning "text/plain; charset=utf-8") is
assumed in the absence of the option.</t>
<t>This option is "critical". It MUST NOT occur more than once.</t>
</section>
<section anchor="max-age" title="Max-Age">
<t>The Max-Age Option indicates the maximum time a response may be
cached before it MUST be considered not fresh (see <xref
target="freshness-model"/>).</t>
<t>When included in a request, the Max-Age Option indicates the
minimum value for the maximum age of a cached response the
client will accept. Note that the default value of 60
seconds for the Max-Age Option
does not apply in a request.</t>
<!-- TODO: Fix me -->
<t>The option value is an integer number of seconds between 0 and
2^32-1 inclusive (about 136.1 years). A default value of 60 seconds
is assumed in the absence of the option in a response.</t>
<t>This option is "elective". It MUST NOT occur more than once.</t>
</section>
<section anchor="etag" title="Etag">
<t>The Etag Option in a response provides the current value of the
entity-tag for the enclosed representation of the target
resource.</t>
<t>An entity-tag is intended for use as a resource-local identifier
for differentiating between representations of the same resource
that vary over time. It may be generated in any number of ways
including a version, checksum, hash or time. An end-point receiving
an entity-tag MUST treat it as opaque and make no assumptions about
its format.</t>
<t>A node that has one or more representations previously obtained
from the resource can specify the Etag Option in a request for
each stored response to determine if any of those representations
is current (see <xref target="validation-model"/>).</t>
<t>This option is "elective". It MUST NOT occur more than once in a
response, and MAY occur one or more times in a request.</t>
</section>
<section anchor="location-path" title="Location-Path">
<t>The collection of Location-Path Options indicates the location of a resource as
an absolute path URI; each Location-Path Option is similar
to a Uri-Path Option. The
Location-Path Option MAY be included in a response to indicate the
location of a new resource created with POST.</t>
<t>If a response with a Location-Path Option passes through a cache
and the implied URI identifies one or more currently stored
responses, those entries SHOULD be treated as stale.</t>
<t>This option is "elective". It MAY occur one or more times.</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="uri" title="CoAP URIs">
<t>CoAP uses the "coap" URI scheme for identifying CoAP resources and
providing a means of locating the resource. Resources are organized
hierarchically and governed by a potential CoAP origin server listening
for CoAP requests on a given UDP port. The CoAP server is identified via the
generic syntax's authority component, which includes a host identifier
and optional UDP port number, and the remainder of the URI is considered to be
identifying a resource which can be operated on by the methods available
through the CoAP protocol. CoAP URIs can thus be compared to the "http"
URI scheme.</t>
<section anchor="uri-syntax" title="URI Scheme Syntax">
<t>The syntax of the "coap" URI scheme is specified below in
Augmented Backus-Naur Form (ABNF) <xref target="RFC5234"/>.
The definitions of "host", "port", "path-abempty", and "query"
are adopted from <xref target="RFC3986"/>, as well as
"segment", "IP-literal", "IPv4address" and "reg-name" for the
following sections.</t>
<t><![CDATA[coap-URI = "coap:" "//" host [ ":" port ] path-abempty [ "?" query ]]]></t>
<!-- TODO: check this with an ABNF compiler -->
<t>If host is provided as an IP literal or IPv4 address, then the
CoAP server is located at that IP address.
If host is a registered name, then that name is considered an indirect
identifier and the end-point might use a name resolution service, such
as DNS,
<!-- TODO: can/should we wed ourselves to DNS? -->
to find the address of that host. The host MUST NOT be empty.
The port subcomponent indicates the UDP port at which the CoAP
server is located. If it is
empty or not given, then the default port
&PORT; is assumed.</t>
<t>The path identifies a resource within the scope of the host and
port. It consists of a sequence of path segments separated by a slash
("/") character. The query serves to further parametrize the resource,
often in the form of "key=value" pairs.</t>
<t>Application designers are encouraged to make use of short, but
descriptive URIs. As the environments that CoAP is used in
are usually constrained for bandwidth and energy, the
trade-off between these two qualities should lean towards the
shortness, without ignoring descriptiveness.</t>
</section>
<section anchor="uri-normalization" title="Normalization and Comparison Rules">
<t>Since the "coap" scheme conforms to the URI generic syntax, URIs
of this scheme are normalized and compared according to the algorithm
defined in <xref target="RFC3986"/>, Section 6.</t>
<t>If the port is equal to the default port &PORT;, the normal form
is to elide the port component. Likewise, an empty path component
is equivalent to an absolute path of "/", so the normal form is to
provide a path of "/" instead. The scheme and host are
case-insensitive and normally provided in lowercase;
IP-literals are in recommended form <xref target="RFC5952"/>; all other
components are compared in a case-sensitive manner. Characters
other than those in the "reserved" set are equivalent to their
percent-encoded octets (see <xref target="RFC3986"/>, Section
2.1): the normal form is to not encode them.</t>
<t>For example, the following three URIs are equivalent, and
cause the same options and option values to appear in the CoAP
messages:
<list style="empty">
<t><![CDATA[coap://example.com:]]>&PORT;<![CDATA[/~sensors/temp.xml]]></t>
<t><![CDATA[coap://EXAMPLE.com/%7Esensors/temp.xml]]></t>
<t><![CDATA[coap://EXAMPLE.com:/%7esensors/temp.xml]]></t>
</list>
</t>
</section>
<!-- The ugly /url/ stuff will be fixed by the RFC editor :-) -->
<section anchor="uri-parsing" title="Parsing URIs">
<t>The steps to parse a request's options from a string /url/ are as
follows. These steps either result in zero or more of the Uri-Host,
Uri-Port, Uri-Path and Uri-Query Options being included in the
request, or they fail.
<list style="numbers">
<t>If the /url/ string is not an absolute URI (<xref
target="RFC3986"/>), then fail this algorithm.</t>
<t>Resolve the /url/ string using the process of reference
resolution defined by <xref target="RFC3986"/>, with the URL
character encoding set to <xref target="RFC3629">UTF-8</xref>.
<vspace blankLines="1"/>
NOTE: It doesn't matter what it is resolved relative to, since
we already know it is an absolute URL at this point.</t>
<t>If /url/ does not have a <scheme> component whose value,
when converted to ASCII lowercase, is "coap", then fail this
algorithm.</t>
<t>If /url/ has a <fragment> component, then fail this
algorithm.</t>
<t>If the <host> component of /url/ does not represent the
request's destination IP address as an IP-literal or IPv4
address, include a Uri-Host Option and
let that option's value be the value of the <host> component
of /url/, converted to ASCII lowercase, and then converting
each percent-encoding ("%" followed by
two hexadecimal digits) to the corresponding byte.
.
<vspace blankLines="1"/>
NOTE: In the usual case where the request's destination IP
address is derived from the host part, this ensures that
Uri-Host Options are only used for host parts of the form
reg-name.</t>
<t>If /url/ has a <port> component, then let /port/ be
that component's value interpreted as a decimal integer;
otherwise, let /port/ be the default
port &PORT;.</t>
<t>If /port/ does not equal the request's destination UDP port,
include a Uri-Port Option and let that option's value be
/port/.</t>
<t>If the value of the <path> component of /url/ is empty or
consists of a single slash character (U+002F SOLIDUS "/"), then move
to the next step.<vspace blankLines="1"/>
Otherwise, for each segment in the <path> component,
include a Uri-Path Option and let that option's value be the
segment (not including the delimiting slash characters)
after converting each percent-encoding ("%" followed by
two hexadecimal digits) to the corresponding byte.</t>
<t>If /url/ has a <query> component, then include a
Uri-Query Option and let that option's value be the value
of the <query> component (not including the delimiting
question mark). (Note that, in contrast to the other
components, percent-encodings stay intact in the Uri-Query option.)</t>
</list></t>
<t>Note that these rules completely resolve any percent-encoding
except in a reg-name and in a query.
</t>
</section>
<section anchor="uri-constructing" title="Constructing URIs">
<t>The steps to construct a URI from a request's options are
as follows. These steps either result in a URI, or they fail.
In these steps, percent-encoding a character means replacing each of its
(UTF-8 encoded) bytes by a
"%" character followed by two hexadecimal digits representing the
byte, where the digits A-F are in upper case (as defined in <xref
target="RFC3986"/> Section 2.1; to reduce variability, the hexadecimal
notation in CoAP URIs MUST use uppercase letters).
<list style="numbers">
<t>Let /url/ be the string "coap://".</t>
<t>If the request includes a Uri-Host Option, let /host/ be
that option's value, where any non-ASCII characters are
replaced by their corresponding percent-encoding. If /host/ is not a valid
reg-name or IP-literal or IPv4address, fail the algorithm.
Otherwise, let /host/ be the IP-literal (making
use of the conventions of <xref target="RFC5952"/>)
or IPv4address
representing the request's destination IP address.</t>
<t>Append /host/ to /url/.</t>
<t>If the request includes a Uri-Port Option, let /port/ be
that option's value. Otherwise, let /port/ be the request's
destination UDP port.</t>
<t>If /port/ is not the default port &PORT;, then append a
single U+003A COLON character (:) followed by the decimal
representation of /port/ to /url/.</t>
<t>Let /resource name/ be the empty string. For each Uri-Path
Option in the request, append a single character U+002F SOLIDUS
(/) followed by the option's value to /resource name/, after
converting any character that is not either in the
"unreserved" set, "sub-delims"
set, a U+003A COLON character (:) or U+0040 COMMERCIAL AT (@),
to its percent-encoded form.</t>
<t>If /resource name/ is the empty string, set it to a single
character U+002F SOLIDUS (/).</t>
<t>Append /resource name/ to /url/.</t>
<t>If the request includes a Uri-Query Option, append a single
U+003F QUESTION MARK character (?) to /url/, followed by the
option's value.</t>
<t>Return /url/.</t>
</list></t>
<t>Note that these steps have been designed to lead to a URI
in normal form (see <xref target="uri-normalization"/>).
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="addressing" title="Finding and Addressing CoAP End-Points">
<section anchor="discovery" title="Resource Discovery">
<t>The discovery of resources offered by a CoAP end-point is extremely
important in machine-to-machine applications where there are no humans
in the loop and static interfaces result in fragility. A CoAP end-point
SHOULD support the CoRE Link Format of discoverable resources as
described in <xref target="I-D.ietf-core-link-format"/>. </t>
</section>
<section anchor="default-port" title="Default Port">
<t>The CoAP default port number &PORT; MUST be supported by a
server for resource discovery
and SHOULD be supported for providing access to other resources. In
addition other end-points may be hosted in the dynamic port space.</t>
<t>When a CoAP server is hosted by a 6LoWPAN node, it SHOULD also
support a port in the 61616-61631 compressed UDP port space defined
in <xref target="RFC4944"/>.</t>
</section>
<section anchor="multiplexing" title="Multiplexing DTLS and CoAP">
<t>The CoAP encoding has been chosen to enable demultiplexing of two
kinds of packets that arrive on a single UDP port:</t>
<t><list style='symbols'>
<t>CoAP messages directly sent within UDP</t>
<t>DTLS 1.1 or 1.2 messages (which might contain CoAP messages) on UDP</t>
</list></t>
<t>Possibly less importantly, a distinction can also be made between
these two and:</t>
<t><list style='symbols'>
<t>STUN messages on UDP</t>
</list></t>
<t>This demultiplexing is possible because DTLS 1.1 or 1.2 UDP
payloads begin with a byte out of:</t>
<figure anchor="tls-contenttype" title="TLS ContentType"
><artwork><![CDATA[
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
]]></artwork></figure>
<t>i.e. 0x14 to 0x17 hex <xref target="RFC4347"/>.
In a CoAP message, such an initial byte would be decoded as a CoAP
version 0, which is not in use.</t>
<section anchor="multiplexing-future" title="Future-Proofing the Multiplexing">
<t>To maintain this property, future versions of CoAP will not use
version number 0.
Note that future versions of DTLS might theoretically start to use
"ContentType" values that fall into the range of 64 to 127; CoAP
implementations would then not be able to reliably multiplex
these new kinds of DTLS datagrams with CoAP datagrams on the same
UDP port. To maintain transparency for this case, an initial
byte of 0x11 (17 decimal) is inserted on transmission and
discarded upon reception; the rest of the
datagram is interpreted as the DTLS message. 0x11 MUST NOT be
followed by 0x14 to 0x17 hex, i.e. the DTLS messages defined by
DTLS 1.1 and 1.2 are always sent unescaped. Datagrams starting with
0x11 and then 0x14 to 0x17 MUST be discarded.</t>
<t>Similarly, STUN messages begin with 00mmmmmc binary (MSBs) <xref target="RFC5389"/>
and so far happen to use an encoding for mmmmmc that also enables this
initial byte to be distinguished from valid DTLS messages. Again,
future versions of CoAP will need to avoid using version number
0. STUN messages are most likely to begin with 0x00 and 0x01.
All other STUN messages MUST be escaped with a an initial 0x10
byte (16 decimal). 0x10 MUST NOT be followed by 0x00 or 0x01
hex, i.e. the more likely STUN messages are always sent unescaped.</t>
<t>Note that the escaping rules defined in this section are
insurance for the future; they need no additional code in
implementations that do not implement STUN or DTLS or implement
only the versions current at the time of writing. For easy
reference, <xref target="initial-byte"/> summarizes the rules
upon reception.
</t>
<texttable title="Interpretation of initial byte when multiplexing" anchor="initial-byte">
<ttcol align='left'>initial byte</ttcol>
<ttcol align='left'>disposition</ttcol>
<ttcol align='left'>interpretation</ttcol>
<c>0x00 or 0x01</c>
<c>keep</c>
<c>STUN</c>
<c>0x10</c>
<c>remove</c>
<c>STUN</c>
<c>0x11</c>
<c>remove</c>
<c>DTLS</c>
<c>0x14 to 0x17</c>
<c>keep</c>
<c>DTLS</c>
<c>0x40 to 0x7F</c>
<c>keep</c>
<c>CoAP</c>
<c>all others</c>
<c> </c>
<c>(invalid)</c>
</texttable>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="http" title="HTTP Mapping">
<t>CoAP supports a limited subset of HTTP functionality, and thus a
mapping to HTTP is straightforward. There might be several reasons
for mapping between CoAP and HTTP, for example when designing a web
interface for use over either protocol or when realizing a CoAP-HTTP
proxy. Likewise, CoAP could equally be mapped to other protocols such
as XMPP <xref target="RFC3920"/> or SIP <xref target="RFC3264"/>, the
definition of these mappings is out of scope of this specification.</t>
<t>This section discusses two ways of mapping:
<list style="hanging">
<t hangText="CoAP-HTTP Mapping:">Enables CoAP clients to access
resources on HTTP servers through an intermediary.
This is initiated by including the Proxy-Uri Option with an "http"
URI in a CoAP request to a CoAP-HTTP proxy, or by sending a CoAP
request to a reverse proxy that maps CoAP to HTTP.</t>
<t hangText="HTTP-CoAP Mapping:">Enables HTTP clients to access
resources on CoAP servers through an intermediary.
This is initiated by specifying a "coap" URI in the Request-Line
of an HTTP request to an HTTP-CoAP proxy, or by sending an HTTP
request to a reverse proxy that maps HTTP to CoAP.</t>
</list>
</t>
<t>Either way, only the Request/Response model of CoAP is mapped to
HTTP. The underlying model of confirmable or non-confirmable messages,
etc., is invisible and MUST have no effect on a proxy function.</t>
<section anchor="coap-http" title="CoAP-HTTP Mapping">
<t>The mapping of CoAP to HTTP is a relatively straightforward conversion of
the CoAP method or response code, content-type and options to the
corresponding HTTP feature. The payload is carried in an equivalent
way by both protocols.</t>
<t>In a similar manner to CoAP-CoAP proxying, the CoAP-HTTP proxy
MAY perform caching of HTTP responses. If no caching is performed,
a CoAP GET request that specifies an entity-tag in an Etag Option
SHOULD be mapped to a conditional HTTP request that includes the
entity-tag in the "If-None-Match" request-header field. If the
entity-tag matches the entity-tag of the representation, the HTTP
server responds with an HTTP 304 (Not Modified) response which
SHOULD be mapped to a CoAP 2.03 (Valid) response with the Etag Option
reflecting the response's "Etag" response-header field.
The mapping of max-age is straightforward.</t>
<t>HTTP entity-tags consist of characters in a subset of
the US-ASCII character set, which can be carried directly in
a CoAP Etag Option. Weak entity-tags are not supported by
this mapping.
However, an entity-tag may not fit within the CoAP Etag Option.
In this case, the proxy MAY map the entity-tag to a
shorter unique byte sequence and keep state, or MAY silently ignore the
"Etag" response-header when mapping an HTTP response to CoAP (so
the CoAP client will never send a CoAP GET request with an Etag
Option).</t>
<t>Provisional responses (HTTP Status Codes 1xx), and responses
indicating that further action needs to be taken (HTTP Status
Codes 3xx), SHOULD cause the proxy to complete the
request, e.g., by following the redirects. If the proxy
is unable to complete the request, it SHOULD respond with
a CoAP 5.02 (Bad Gateway) error.</t>
<t>HTTP responses are mapped to CoAP responses as follows:</t>
<texttable anchor="tab-coap-http" title="CoAP-HTTP Mapping">
<ttcol align="left">HTTP Status Code</ttcol>
<ttcol align="left">CoAP Response Code</ttcol>
<ttcol align="left">Notes</ttcol>
<c>100 Continue </c><c> </c><c>2</c>
<c>101 Switching Protocols </c><c> </c><c>2</c>
<c>200 OK </c><c> </c><c>3</c>
<c>201 Created </c><c>2.01 Created </c><c> </c>
<c>202 Accepted </c><c> </c><c>4</c>
<c>203 Non-Authoritative Information </c><c> </c><c>4</c>
<c>204 No Content </c><c> </c><c>6</c>
<c>205 Reset Content </c><c> </c><c>4</c>
<c>206 Partial Content </c><c> </c><c>2</c>
<c>300 Multiple Choices </c><c> </c><c>2</c>
<c>301 Moved Permanently </c><c> </c><c>2</c>
<c>302 Found </c><c> </c><c>2</c>
<c>303 See Other </c><c> </c><c>2</c>
<c>304 Not Modified </c><c>2.03 Valid </c><c>7</c>
<c>305 Use Proxy </c><c> </c><c>2</c>
<c>306 (Unused) </c><c>5.02 Bad Gateway </c><c>1</c>
<c>307 Temporary Redirect </c><c> </c><c>2</c>
<c>400 Bad Request </c><c>4.00 Bad Request </c><c> </c>
<c>401 Unauthorized </c><c>4.01 Unauthorized </c><c>5</c>
<c>402 Payment Required </c><c>4.00 Bad Request </c><c>1</c>
<c>403 Forbidden </c><c>4.03 Forbidden </c><c> </c>
<c>404 Not Found </c><c>4.04 Not Found </c><c> </c>
<c>405 Method Not Allowed </c><c>4.05 Method Not Allowed </c><c>8</c>
<c>406 Not Acceptable </c><c>4.00 Bad Request </c><c>1</c>
<c>407 Proxy Authentication Required </c><c>4.00 Bad Request </c><c>1</c>
<c>408 Request Timeout </c><c>4.00 Bad Request </c><c>1</c>
<c>409 Conflict </c><c>4.00 Bad Request </c><c>1</c>
<c>410 Gone </c><c>4.00 Bad Request </c><c>1</c>
<c>411 Length Required </c><c>4.00 Bad Request </c><c>1</c>
<c>412 Precondition Failed </c><c>4.00 Bad Request </c><c>1</c>
<c>413 Request Entity Too Large </c><c>4.13 Request Entity Too Large</c><c> </c>
<c>414 URI Too Long </c><c>4.00 Bad Request </c><c>1</c>
<c>415 Unsupported Media Type </c><c>4.15 Unsupported Media Type </c><c> </c>
<c>416 Requested Range Not Satisfiable</c><c>4.00 Bad Request </c><c>1</c>
<c>417 Expectation Failed </c><c>4.00 Bad Request </c><c>1</c>
<c>500 Internal Server Error </c><c>5.00 Internal Server Error </c><c> </c>
<c>501 Not Implemented </c><c>5.01 Not Implemented </c><c> </c>
<c>502 Bad Gateway </c><c>5.02 Bad Gateway </c><c> </c>
<c>503 Service Unavailable </c><c>5.03 Service Unavailable </c><c>9</c>
<c>504 Gateway Timeout </c><c>5.04 Gateway Timeout </c><c> </c>
<c>505 HTTP Version Not Supported </c><c> </c><c>2</c>
</texttable>
<t>Notes:
<list style="numbers">
<t>There is no equivalent CoAP response.</t>
<t>The proxy should perform the action implied by the
response code (e.g., by following redirects); i.e. this
response is never forwarded to the CoAP client. If the
proxy is unable or unwilling to perform this function, the
CoAP response code 5.02 (Bad Gateway) can be returned.</t>
<t>The CoAP response code depends on the request method. For a GET
request, the response code SHOULD be 2.00 (OK). For a POST, PUT or
DELETE request, the mapping is only partial: response
entities are ignored, and the response code depends on the
method as defined in <xref target="methods"/>.</t>
<t>(The mapping for these rarely-used status codes is not
defined in this specification.)</t>
<t>The HTTP "WWW-Authenticate" response-header field has no
equivalent option in CoAP and is either processed by the
proxy by performing an additional request or silently dropped.</t>
<t>The CoAP response code depends on the request method. For a POST
or PUT request, the response code SHOULD be 2.04 (Changed); for a
DELETE request, 2.02 (Deleted).</t>
<t>Since a CoAP request with Etag Option is mapped to a conditional
HTTP GET request with a "If-None-Match" request-header field, any
HTTP 304 (Not Modified) response will confirm that the Etag
is valid.
Except for the max-age directive of the Cache-Control header
field, any additional headers in the HTTP Not Modified
response are not carried through to the CoAP client, though.</t>
<t>The HTTP "Accept" response-header field has no equivalent option
in CoAP and is silently dropped.</t>
<t>The HTTP "Retry-After" response-header field has no equivalent
option in CoAP, although it may be used to find a value for the
Max-Age Option.</t>
</list>
</t>
</section>
<section anchor="http-coap" title="HTTP-CoAP Mapping">
<t>The mapping of HTTP to CoAP requires checking for methods,
response codes and options that are not supported by CoAP. A
proxy SHOULD attempt to map options, response codes and
content-types to a suitable alternative if possible. Otherwise
the unsupported feature SHOULD be silently dropped if possible,
or an appropriate error code generated otherwise.</t>
<t>Mapping MAY include performing payload conversion (e.g., from EXI
to XML), the definition of which is out of this document's scope.</t>
<t>Only those Conditional HTTP requests can be mapped to CoAP requests
that have method GET and include a "If-None-Match" request-header
field. The "If-Match", "If-Modified-Since" and "If-Unmodified-Since"
request-header fields are not supported on the CoAP side, but
could be implemented locally by a caching proxy. A HTTP-CoAP
proxy SHOULD map
Etags generated by a CoAP server to HTTP-friendly Etags by using
<xref target="RFC4648">Base64</xref>.</t>
<t>A proxy SHOULD respond with a HTTP 502 (Bad Gateway) error to
HTTP requests which can not be successfully mapped to CoAP.</t>
<t>A proxy SHOULD employ a cache to limit traffic on the constrained
network.</t>
<t>CoAP responses are mapped to HTTP responses as follows:</t>
<texttable anchor="tab-http-coap" title="HTTP-CoAP Mapping">
<ttcol align="left">CoAP Response Code</ttcol>
<ttcol align="left">HTTP Status Code</ttcol>
<ttcol align="left">Notes</ttcol>
<c>2.00 OK </c><c>200 OK </c><c> </c>
<c>2.01 Created </c><c>201 Created </c><c> </c>
<c>2.02 Deleted </c><c>204 No Content </c><c> </c>
<c>2.03 Valid </c><c>304 Not Modified </c><c>1</c>
<c>2.04 Changed </c><c>204 No Content </c><c> </c>
<c>4.00 Bad Request </c><c>400 Bad Request </c><c> </c>
<c>4.01 Unauthorized </c><c>400 Bad Request </c><c>2</c>
<c>4.02 Bad Option </c><c>400 Bad Request </c><c> </c>
<c>4.03 Forbidden </c><c>403 Forbidden </c><c> </c>
<c>4.04 Not Found </c><c>404 Not Found </c><c> </c>
<c>4.05 Method Not Allowed </c><c>405 Method Not Allowed </c><c>3</c>
<c>4.13 Request Entity Too Large</c><c>413 Request Entity Too Large</c><c> </c>
<c>4.15 Unsupported Media Type </c><c>415 Unsupported Media Type </c><c> </c>
<c>5.00 Internal Server Error </c><c>500 Internal Server Error </c><c> </c>
<c>5.01 Not Implemented </c><c>501 Not Implemented </c><c> </c>
<c>5.02 Bad Gateway </c><c>502 Bad Gateway </c><c> </c>
<c>5.03 Service Unavailable </c><c>503 Service Unavailable </c><c>4</c>
<c>5.04 Gateway Timeout </c><c>504 Gateway Timeout </c><c> </c>
<c>5.05 Proxying Not Supported </c><c>502 Bad Gateway </c><c> </c>
</texttable>
<t>Notes:
<list style="numbers">
<t>A CoAP 2.03 (Valid) response only (1) confirms that the request Etag
is valid and (2) provides a new Max-Age value. HTTP 304 (Not Modified)
also updates some header fields of a stored response.
A non-caching proxy may not have enough
information to fill in the required values in the HTTP 304 (Not
Modified) response, so it may not be advisable to provoke
the 2.03 (Valid) response by forwarding an Etag. A caching
proxy will fill the information out of the cache.</t>
<t>There is no equivalent HTTP status code.</t>
<t>CoAP does not provide enough information to compute a
value for the required "Allow" response-header field. If
this violation of <xref target="RFC2616"/> cannot be tolerated, the
proxy should instead send a 4.00 (Bad Request) response.</t>
<t>The value of the "Retry-After" response-header field is the
value of the Max-Age Option.</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="constants" title="Protocol Constants">
<t>This section defines the relevant protocol constants defined in this
document: <list style="hanging">
<t hangText="RESPONSE_TIMEOUT">2 seconds</t>
<t hangText="MAX_RETRANSMIT">4</t>
</list></t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="security" title="Security Considerations">
<t>This section describes mechanisms that can be used to secure CoAP and
analyzes the possible threats to the protocol and its limitations.
Security bootstrapping (authenticating nodes and setting up keys) in constrained environments is
considered in <xref target="I-D.oflynn-core-bootstrapping"/>.</t>
<t>During the bootstrap and enrollment phases, a CoAP device is provided
with the security information that it needs, including keying
materials. How this is done is out
of scope for this specification but a couple of ways of doing this are
described in <xref target="I-D.oflynn-core-bootstrapping"/>. At
the end of the enrollment and bootstrap, the device will be in one of
four security modes with the following information for the given
mode:</t>
<t><list style="hanging">
<t hangText="NoSec:">There is no protocol level security.</t>
<t hangText="SharedKey:">There is one shared key between all the
nodes that this CoAP nodes needs to communicate with.</t>
<t hangText="MultiKey:">There is a list of shared keys and each key
includes a list of which nodes it can be used to communicate with.
At the extreme there may be one key for each node this CoAP node needs to communicate with.</t>
<t hangText="Certificate:">The device has an asymmetric key pair
with a X.509 <xref target="RFC5280"/> certificate that binds it
to its Authority Name and is signed by a some common trust root. The
device also has a list or root trust anchors that can be used for
validating a certificate. There may be an optional shared key that
all the nodes that communicate have access too.</t>
</list>
The Authority Name in the certificate is the name that would be
used in the Authority part of a CoAP URI. It is worth noting that
this would typically not be either an IP address or DNS name but would
instead be a long term unique identifier for the device such as the
EUI-64 <xref target="EUI64"/>. The discovery process used in the system would build up the
mapping between IP addresses of the given devices and the Authority Name
for each device. Some devices could have more than one Authority and
would need more than a single certificate.</t>
<t>In the "NoSec" mode, the system simply sends the packets over normal
UDP over IP. The system is secured only by keeping attackers
from being able to send or receive packets from the network with the
CoAP nodes; see <xref target="cross-protocol-attacks"/> for an additional
complication with this approach.
The other three security modes can be achieved with IPsec or
DTLS. The result is a security association that can be used to
authenticate (within the limits of the security model) and,
based on this authentication,
authorize the communication partner. CoAP itself does not
provide protocol primitives for authentication or authorization;
where this is required, it can either be provided by
communication security (i.e., IPsec or DTLS) or by object
security (within the payload). Devices that require
authorization for certain operations are expected to require one
of these two forms of security. Necessarily, where an
intermediary is involved, communication security only works when
that intermediary is part of the trust relationships; CoAP does
not provide a way to forward different levels of authorization
that clients may have with an intermediary to further
intermediaries or origin servers -- it therefore may be required
to perform all authorization at the first intermediary.</t>
<section anchor="ipsec" title="Securing CoAP with IPsec">
<!-- Use of IPsec with multicast...
TODO - talk about the 3 modes with IPsec and IKE, and HIP
TODO - explain how the identity of each device is proven to the remote side
TODO - consider use of IPsec with multicast requests
-->
<t>One mechanism to secure CoAP in constrained environments is the
IPsec Encapsulating Security Payload (ESP) <xref
target="RFC4303"/>. Using IPsec ESP with the appropriate
configuration, it is possible for many constrained devices to support
encryption with built-in link-layer encryption hardware. For example,
some IEEE 802.15.4 radio chips are compatible with AES-CBC (with
128-bit keys) <xref target="RFC3602"/> as defined for use with
IPsec in <xref target="RFC4835"/>. Alternatively,
particularly on more common IEEE 802.15.4 hardware that supports AES
encryption but not decryption, and to avoid the need for padding, nodes
could directly use the more widely supported AES-CCM as
defined for use with IPsec in
<xref target="RFC4309"/>, if the security considerations in
section 9 of that specification can be fulfilled.
Necessarily for AES-CCM, but much preferably also for AES-CBC,
static keying should be avoided and the initial keying
material be derived into transient session keys, e.g. using a
low-overhead mode of IKEv2 <xref target="RFC5996"/>; such a
protocol for managing keys and sequence numbers is
also the only way to achieve anti-replay capabilities.
However, no
recommendation can be made at this point on how to manage
group keys (i.e., for multicast) in a constrained environment.
Once any initial setup is completed, IPsec ESP adds a limited
per-packet overhead of approximately 10 bytes, not including
initialization vectors,
integrity check values and padding required by the cipher suite.
</t>
<t>
When using IPsec to secure
CoAP, both authentication and confidentiality SHOULD be applied as
recommended in <xref target="RFC4303"/>. The use of IPsec
between CoAP end-points is transparent to the application layer and
does not require special consideration for a CoAP implementation. </t>
<t>IPsec may not be appropriate for all environments. For example,
IPsec support is not available for many embedded IP stacks and even in
full PC operating systems or on back-end web servers, application
developers may not have sufficient access to configure or enable IPsec
or to add a security gateway to the infrastructure. Problems with
firewalls and NATs may furthermore limit the use of IPsec.</t>
</section>
<section anchor="dtls" title="Securing CoAP with DTLS">
<!-- TODO: Does DTLS require a separate port? -->
<!-- TODO: Can we tell the difference between CoAP, STUN and DTLS? -->
<t>Just as HTTP may be secured using Transport Layer Security (TLS)
over TCP, CoAP may be secured using Datagram TLS (DTLS) <xref
target="RFC4347"/> over UDP. This section gives a quick
overview of how to
secure CoAP with DTLS, along with the minimal configurations
appropriate for constrained environments. DTLS is in practice TLS with
added features to deal with the unreliable nature of the UDP
transport.</t>
<t>In some constrained nodes (limited flash and/or RAM) and networks
(limited bandwidth or high scalability requirements), and
depending on the specific cipher suites in use, DTLS may not be
applicable. Some of DTLS' cipher suites can add significant
implementation complexity as well as some initial handshake
overhead needed when setting up the security association.
Once the initial handshake is completed, DTLS adds a limited
per-datagram overhead of approximately 13 bytes, not including
any initialization vectors (which are generally implicitly derived
with DTLS), integrity check values (e.g., 8 bytes with the proposed
TLS_PSK_WITH_AES_128_CCM_8 <xref target="I-D.mcgrew-tls-aes-ccm"/>) and padding
required by the cipher suite.
Whether and which mode of using
DTLS is applicable for a CoAP-based application should be
carefully weighed
considering the specific cipher suites that may be applicable,
and whether the session
maintenance makes it compatible with application flows and sufficient
resources are available on the constrained nodes and for the added
network overhead.
DTLS is not applicable to group keying (multicast
communication); however, it may be a component in a future
group key management protocol.</t>
<t>Devices SHOULD support the Server Name Indication (SNI) to indicate
their Authority Name in the SNI HostName field as defined in Section 3
of <xref target="RFC6066"/>. This is needed so that when a host that
acts as a virtual server for multiple Authorities receives a new DTLS
connection, it knows which keys to use for the DTLS session.</t>
<t>DTLS connections with certificates are set up using mutual
authentication so they can remain up and be reused for future
message exchanges in either direction. Devices can close a DTLS connection
when they need to recover resources but in general they should keep
the connection up for as long as possible. Closing the DTLS connection
after every CoAP message exchange is very inefficient.</t>
<!-- TODO: explain how a client can find out the right
authentication realm (i.e., which client certificate/identity to send,
and also whether DTLS security is desired at all) from a CoAP
URI.
-->
<section title="SharedKey & MultiKey Modes">
<t>When forming a connection to a new node, the system selects an
appropriate key based on which nodes it is trying to reach then forms
a DTLS session using a PSK (Pre-Shared Key) mode of DTLS.
Implementations SHOULD support the mandatory to implement cipher suite
TLS_PSK_WITH_AES_128_CBC_SHA as specified in <xref
target="RFC4279"/>; once TLS_PSK_WITH_AES_128_CCM_8 as
specified in <xref
target="I-D.mcgrew-tls-aes-ccm"/> (or related cipher suites
specified in <xref
target="I-D.mcgrew-tls-aes-ccm-ecc"/>) in conjunction with
<xref target="I-D.ietf-tls-rfc4347-bis"/>
becomes available, this may
be easier to implement on certain contemporary chipsets.</t>
<t>The security considerations of <xref target="RFC4279"/>
(Section 7) apply. In particular, applications should
carefully weigh whether they need Perfect Forward Secrecy
(PFS) or not and select an appropriate cipher suite (7.1).
The entropy of the PSK must be sufficient to mitigate against
brute-force and (where the PSK is not chosen randomly but by a
human) dictionary attacks (7.2). The cleartext communication
of client identities may leak data or compromise privacy (7.3).
</t>
</section>
<section title="Certificate Mode">
<t>As with IPsec, DTLS should be configured with a cipher suite
compatible with any possible hardware engine on the node, for example
AES-CBC in the case of IEEE 802.15.4. Implementations SHOULD support
the mandatory to implement cipher suite TLS_RSA_WITH_AES_128_CBC_SHA
as specified in <xref target="RFC5246"/>.</t>
<t>When a new connection is formed, the certificate from the remote
device needs to be verified. If the CoAP node has a source of absolute
time, then the node SHOULD check the validity dates are of the
certificate are within range. The certificate MUST also be signed by
an appropriate chain of trust. If the certificate contains a
SubjectAltName, then the Authority Name MUST match at least one of the
authority names of any CoAP URI found in a URI type fields in the
SubjectAltName set. If there is no SubjectAltName in the certificate,
then the Authoritative Name must match the CN found in the certificate
using the matching rules defined in <xref target="RFC2818"/>
with the exception that certificates with wildcards are not
allowed.</t>
<t>If the system has a shared key in addition to the certificate, then
a cipher suite that includes the shared key such as
TLS_RSA_PSK_WITH_AES_128_CBC_SHA SHOULD be used. </t>
</section>
</section>
<section title="Threat analysis and protocol limitations">
<t>This section is meant to inform protocol and application developers
about the security limitations of CoAP as described in this document.
As CoAP realizes a subset of the features in HTTP/1.1, the security
considerations in Section 15 of <xref target="RFC2616"/> are
also pertinent to CoAP. This section concentrates on describing
limitations specific to CoAP and CoRE.</t>
<section title="Protocol Parsing, Processing URIs">
<t>A network-facing application can exhibit vulnerabilities
in its processing logic for incoming packets.
Complex parsers are well-known as a likely source of such
vulnerabilities, such as the ability to remotely crash a node, or
even remotely execute arbitrary code on it.
CoAP attempts to narrow the opportunities for introducing
such vulnerabilities by reducing parser complexity, by giving the
entire range of encodable values a meaning where possible, and by
aggressively reducing complexity that is often caused by unnecessary
choice between multiple representations that mean the same.
Much of the URI processing has been moved to the clients,
further reducing the opportunities for introducing
vulnerabilities into the servers.
Even so, the URI processing code in CoAP implementations
is likely to be a large source of remaining
vulnerabilities and should be implemented with special care.
The most complex parser remaining could be the one for the
link-format, although this also has been designed with a goal of
reduced implementation complexity <xref
target="I-D.ietf-core-link-format"/>.
(See also section
15.2 of <xref target="RFC2616"/>.)</t>
</section>
<section title="Proxying and Caching">
<t>
As mentioned in 15.2 of <xref target="RFC2616"/>, which
see, proxies are by their very nature men-in-the-middle,
breaking any IPsec or DTLS protection that a direct CoAP
message exchange might have. They are therefore interesting
targets for breaking confidentiality or integrity of CoAP
message exchanges. As noted in <xref target="RFC2616"/>, they
are also interesting targets for breaking availability.
</t>
<t>
The threat to confidentiality and integrity of request/response
data is amplified where proxies also cache. Note that
CoAP does not define any of the cache-suppressing
Cache-Control options that HTTP/1.1 provides to better
protect sensitive data.
</t>
<t>
Finally, a proxy that fans out deferred responses to
multiple original requesters may provide additional
amplification (see below).
</t>
</section>
<!--
<section title="Attacks on MIDs">
<t>TODO. CoAP implementations should be tested against the
reception of unexpected message IDs (MIDs).</t>
</section>
-->
<section anchor="amplification" title="Risk of amplification">
<t>
CoAP servers generally reply to a request packet with a
response packet. This response packet may be
significantly larger than the request packet.
An attacker might use CoAP nodes to turn a small attack
packet into a larger attack packet, an approach known as
amplification.
There is therefore a danger that CoAP nodes could become
implicated in denial of service (DoS) attacks by using the
amplifying properties of the protocol: An attacker that
is attempting to overload a victim but is
limited in the amount of traffic it can generate, can use
amplification to generate a larger amount of traffic.
</t>
<t>
This is particularly a problem in nodes that enable NoSec
access and that are accessible from an attacker and can
access potential victims (e.g. on the general Internet),
as the UDP protocol provides no way to verify the source
address given in the request packet. An attacker need
only place the IP address of the victim in the source
address of a suitable request packet to generate a larger
packet directed at the victim.
</t>
<t>
As a mitigating factor, many constrained network will only
be able to generate a small amount of traffic, which may
make CoAP nodes less attractive for this attack. However,
the limited capacity of the constrained network makes the network
itself a likely victim of an amplification attack.
</t>
<t>
A CoAP server can reduce the amount of amplification it
provides to an attacker by using slicing/blocking modes of
CoAP <xref target="I-D.ietf-core-block"/> and offering large resource
representations only in relatively small slices. E.g., for
a 1000 byte resource, a 10-byte request might result in an
80-byte response (with a 64-byte block) instead of a
1016-byte response, considerably reducing the amplification
provided.
</t>
<t>
CoAP also supports the use of multicast IP addresses in
requests, an important requirement for M2M. Multicast CoAP
requests may be the source of accidental or deliberate
denial of service attacks, especially over constrained
networks. This specification attempts to reduce the
amplification effects of multicast requests by limiting
when a response is returned. To limit the possibility of
malicious use, CoAP servers SHOULD NOT accept multicast
requests that can not be authenticated. If possible a
CoAP server SHOULD limit the support for multicast
requests to specific resources where the feature is
required.
</t>
<t>
On some general purpose operating systems providing a
Posix-style API, it is not straightforward to find out
whether a packet received was addressed to a multicast
address. While many implementations will know whether they have
joined a multicast group,
this creates a problem for packets addressed to
multicast addresses of the form FF0x::1, which are
received by every IPv6 node.
Implementations SHOULD make use of modern APIs such
as IPV6_RECVPKTINFO <xref target="RFC3542"/>, if
available, to make this determination.
</t>
</section>
<section anchor="cross-protocol-attacks" title="Cross-Protocol Attacks">
<t>The ability to incite a CoAP end-point to send packets to a fake
source address can be used not only for amplification, but also for
cross-protocol attacks:</t>
<t><list style='symbols'>
<t>the attacker sends a message to a CoAP end point with a fake source address,</t>
<t>the CoAP end point replies with a message to the given source address,</t>
<t>the victim at the given source address receives a UDP packet that it
interprets according to the rules of a different protocol.</t>
</list></t>
<t>This may be used to circumvent firewall rules that prevent direct
communication from the attacker to the victim, but happen to allow
communication from the CoAP end-point (which may also host a valid
role in the other protocol) to the victim.</t>
<t>Also, CoAP end-points may be the victim of a cross-protocol attack
generated through an endpoint of another UDP-based protocol such as
DNS. In both cases, attacks are possible if the security properties of
the end-points rely on checking IP addresses (and firewalling off
direct attacks sent from outside using fake IP addresses). In
general, because of their lack of context, UDP-based protocols are
relatively easy targets for cross-protocol attacks.</t>
<t>Finally, CoAP URIs transported by other means could be used to incite
clients to send messages to end-points of other protocols.</t>
<t>One mitigation against cross-protocol attacks is strict checking of
the syntax of packets received, combined with sufficient
difference in syntax. As an example, it might help if it
were difficult to incite a DNS server to send a DNS response that
would pass the checks of a CoAP endpoint. Unfortunately, the first
two bytes of a DNS reply are an ID that can be chosen by the attacker,
which map into the interesting part of the CoAP header, and the next
two bytes are then interpreted as CoAP's Message ID (i.e., any
value is acceptable). The DNS count words may be interpreted as
multiple instances of a (non-existent, but elective) CoAP option 0.
The echoed query finally may be manufactured by the attacker to
achieve a desired effect on the CoAP endpoint; the response added by
the server (if any) might then just be interpreted as added payload.</t>
<figure title="DNS Header vs. CoAP Message" anchor="dns-header"><artwork><![CDATA[
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | T, OC, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE | message id
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork></figure>
<t>In general, for any pair of protocols, one of the protocols can very
well have been designed in a way that enables an attacker to cause the
generation of replies that look like messages of the other protocol.
It is often much harder to ensure or prove the absence of viable
attacks than to generate examples that may not yet completely enable
an attack but might be further developed by more creative minds.
Cross-protocol attacks can therefore only be completely mitigated if
end-points don't authorize actions desired by an attacker just based
on trusting the source IP address of a packet. Conversely, a NoSec
environment that completely relies on a firewall for CoAP security not
only needs to firewall off the CoAP end-points but also all other
end-points that might be incited to send UDP messages to CoAP
end-points using some other UDP-based protocol.</t>
<t>In addition to the considerations above, the security considerations
for DTLS with respect to cross-protocol attacks apply. E.g., if the
same DTLS security association ("connection") is used to carry data of
multiple protocols, DTLS no longer provides protection against
cross-protocol attacks between these protocols.</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="iana-considerations" title="IANA Considerations">
<!-- Based on RFC5226, RFC4395 and I-D.ietf-tsvwg-iana-ports-09. -->
<section anchor="coap-code-registry" title="CoAP Code Registry">
<t>This document defines a registry for the values of the Code field
in the CoAP header. The name of the registry is "CoAP Codes".</t>
<t>Values are as follows:
<list style="hanging" hangIndent="10">
<t hangText="0">Indicates an empty message (see <xref target="message-types"/>)</t>
<t hangText="1-31">Assigned by the "Method Codes" sub-registry
(see below)</t>
<t hangText="32-63">Reserved</t>
<t hangText="64-191">Assigned by the "Response Codes" sub-registry
(see below)</t>
<t hangText="192-255">Reserved</t>
</list>
</t>
<section anchor="coap-code-registry-methods" title="Method Codes">
<!-- Name of the sub-registry -->
<t>The name of the sub-registry is "CoAP Method Codes".</t>
<!-- Size, format and syntax of registry entries -->
<t>Each entry in the sub-registry must include the Method Code
in the range 1-31, the name of the method, and a reference to
the method's documentation.</t>
<!-- Initial assignments and reservations -->
<t>Initial entries in this sub-registry are as follows:</t>
<texttable anchor="tab-method-code-registry" title="CoAP Method Codes">
<ttcol align="right">Code</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c> 1</c><c>GET </c><c><xref target="get"/> </c>
<c> 2</c><c>POST </c><c><xref target="post"/> </c>
<c> 3</c><c>PUT </c><c><xref target="put"/> </c>
<c> 4</c><c>DELETE</c><c><xref target="delete"/></c>
</texttable>
<t>All other Method Codes are Unassigned.</t>
<!-- Review process -->
<t>The IANA policy for future additions to this registry is
"IETF Review" as described by <xref target="RFC5226"/>.</t>
</section>
<section anchor="coap-code-registry-responses" title="Response Codes">
<!-- Name of the sub-registry -->
<t>The name of the sub-registry is "CoAP Response Codes".</t>
<!-- Size, format and syntax of registry entries -->
<t>Each entry in the sub-registry must include the Response Code
in the range 64-191, a description of the Response Code, and a
reference to the Response Code's documentation.</t>
<!-- Initial assignments and reservations -->
<t>Initial entries in this sub-registry are as follows:</t>
<texttable anchor="tab-response-code-registry" title="CoAP Response Codes">
<ttcol align="right">Code</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<!-- Success 64-95 -->
<c> 64</c><c>2.00 OK </c><c><xref target="ok"/> </c>
<c> 65</c><c>2.01 Created </c><c><xref target="created"/> </c>
<c> 66</c><c>2.02 Deleted </c><c><xref target="deleted"/> </c>
<c> 67</c><c>2.03 Valid </c><c><xref target="valid"/> </c>
<c> 68</c><c>2.04 Changed </c><c><xref target="changed"/> </c>
<!-- Client Error 128-159 -->
<c>128</c><c>4.00 Bad Request </c><c><xref target="bad-request"/> </c>
<c>129</c><c>4.01 Unauthorized </c><c><xref target="unauthorized"/> </c>
<c>130</c><c>4.02 Bad Option </c><c><xref target="bad-option"/> </c>
<c>131</c><c>4.03 Forbidden </c><c><xref target="forbidden"/> </c>
<c>132</c><c>4.04 Not Found </c><c><xref target="not-found"/> </c>
<c>133</c><c>4.05 Method Not Allowed </c><c><xref target="method-not-allowed"/> </c>
<c>141</c><c>4.13 Request Entity Too Large</c><c><xref target="request-entity-too-large"/></c>
<c>143</c><c>4.15 Unsupported Media Type </c><c><xref target="unsupported-media-type"/> </c>
<!-- Server Error 160-191 -->
<c>160</c><c>5.00 Internal Server Error </c><c><xref target="internal-server-error"/> </c>
<c>161</c><c>5.01 Not Implemented </c><c><xref target="not-implemented"/> </c>
<c>162</c><c>5.02 Bad Gateway </c><c><xref target="bad-gateway"/> </c>
<c>163</c><c>5.03 Service Unavailable </c><c><xref target="service-unavailable"/> </c>
<c>164</c><c>5.04 Gateway Timeout </c><c><xref target="gateway-timeout"/> </c>
<c>165</c><c>5.05 Proxying Not Supported </c><c><xref target="proxying-not-supported"/> </c>
</texttable>
<t>The Response Codes 96-127 are Reserved for future use. All other
Response Codes are Unassigned.</t>
<!-- Review process -->
<t>The IANA policy for future additions to this registry is
"IETF Review" as described by <xref target="RFC5226"/>.</t>
</section>
</section>
<section anchor="option-number-registry" title="Option Number Registry">
<!-- Name of the registry -->
<t>This document defines a registry for the option numbers used in
CoAP options. The name of the registry is "CoAP Option Numbers".</t>
<!-- Size, format and syntax of registry entries -->
<t>Each entry in the registry must include the Option Number, the name
of the option and a a reference to the option's documentation.</t>
<!-- Initial assignments and reservations -->
<t>Initial entries in this registry are as follows:</t>
<texttable anchor="tab-option-registry" title="CoAP Option Numbers">
<ttcol align="right">Number</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c> 1</c><c>Content-Type </c><c><xref target="content-type"/> </c>
<c> 2</c><c>Max-Age </c><c><xref target="max-age"/> </c>
<c> 3</c><c>Proxy-Uri </c><c><xref target="proxy-uri"/> </c>
<c> 4</c><c>Etag </c><c><xref target="etag"/> </c>
<c> 5</c><c>Uri-Host </c><c><xref target="uri-options"/> </c>
<c> 6</c><c>Location-Path</c><c><xref target="location-path"/></c>
<c> 7</c><c>Uri-Port </c><c><xref target="uri-options"/> </c>
<c> 9</c><c>Uri-Path </c><c><xref target="uri-options"/> </c>
<c>11</c><c>Token </c><c><xref target="token"/> </c>
<c>15</c><c>Uri-Query </c><c><xref target="uri-options"/> </c>
</texttable>
<t>The Option Numbers 0 and 8 are Reserved for future use. The
Option Numbers 14, 28, 42, ... are Reserved for "fenceposting"
(see <xref target="option-format"/>). All other Option Numbers
are Unassigned.</t>
<!-- Review process -->
<t>The IANA policy for future additions to this registry is
"IETF Review" as described by <xref target="RFC5226"/>.</t>
</section>
<section anchor="media-type-registry" title="Media Type Registry">
<!-- Name of the registry -->
<t>Media types are identified by a string, such as "application/xml"
<xref target="RFC2046"/>. In order to minimize the overhead of
using these media types to indicate the format of payloads, this
document defines a registry for a subset of Internet media types to
be used in CoAP and assigns each a numeric identifier. The name of
the registry is "CoAP Media Types".</t>
<!-- Size, format and syntax of registry entries -->
<t>Each entry in the registry must include the media type registered
with IANA, the numeric identifier in the range 0-65535 to be used for
that media type in CoAP, and a reference to a document describing what
payload with that media types means semantically.</t>
<!-- Initial assignments and reservations -->
<t>Initial entries in this registry are as follows:</t>
<texttable anchor="tab-mediatype" title="CoAP Media Types">
<ttcol align="left">Media type</ttcol>
<ttcol align="right">Id.</ttcol>
<ttcol align="left">Reference</ttcol>
<!-- text 0-19 -->
<c>text/plain; charset=utf-8</c> <c> 0</c><c> </c>
<c>text/xml; charset=utf-8</c> <c> 1</c><c> </c>
<c>text/csv; charset=utf-8</c> <c> 2</c><c> </c>
<c>text/html; charset=utf-8</c> <c> 3</c><c> </c>
<!-- image, audio, video 20-39-->
<!-- application 40-200 -->
<c>application/link-format</c> <c>40</c><c><xref target="I-D.ietf-core-link-format"/></c>
<c>application/xml</c> <c>41</c><c> </c>
<c>application/octet-stream</c> <c>42</c><c> </c>
<c>application/rdf+xml</c> <c>43</c><c> </c>
<c>application/soap+xml</c> <c>44</c><c> </c>
<c>application/atom+xml</c> <c>45</c><c> </c>
<c>application/xmpp+xml</c> <c>46</c><c> </c>
<c>application/exi</c> <c>47</c><c><xref target="EXIMIME"/> </c>
<c>application/fastinfoset</c> <c>48</c><c> </c>
<c>application/soap+fastinfoset</c> <c>49</c><c> </c>
<c>application/json</c> <c>50</c><c> </c>
<c>application/x-obix-binary</c> <c>51</c><c><xref target="OBIX1.1"/> </c>
</texttable>
<t>The identifiers between 201 and 255 inclusive are reserved for
Private Use. The identifiers between 256 and 65535 inclusive are
Reserved for future use. All other identifiers are Unassigned.</t>
<!-- Review process -->
<t>Because the name space is so small, the IANA policy for future
additions to this registry is "Expert Review" as described by
<xref target="RFC5226"/>.</t>
<t>
In machine to machine applications, it is not expected that generic Internet
media types such as text/plain, application/xml or application/octet-stream
are useful for real applications. It is recommended that M2M applications making use of
CoAP will request new Internet media types from IANA indicating semantic
information about how to create or parse a payload. Correct examples from
<xref target="tab-mediatype"/> include application/link-format, application/atom+xml
and application/x-obix-binary. For example, a Smart Energy
application payload carried as XML would request a more specific type like
application/se+xml or application/se+exi.
</t>
</section>
<section anchor="uri-scheme-registration" title="URI Scheme Registration">
<t>This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap". The registration request complies with
<xref target="RFC4395"/>.
<list style="hanging">
<t hangText="URI scheme name."><vspace/>
coap</t>
<t hangText="Status."><vspace/>
Provisional.</t>
<t hangText="URI scheme syntax."><vspace/>
Defined in <xref target="uri-syntax"/>.</t>
<t hangText="URI scheme semantics."><vspace/>
The "coap" URI scheme provides a way to identify resources that are
potentially accessible over the Constrained Application Protocol
(CoAP). This scheme can thus be compared to the "http" URI scheme
<xref target="RFC2616"/>. See <xref target="uri"/> for the details
of operation.</t>
<t hangText="Encoding considerations."><vspace/>
The scheme encoding conforms to the encoding rules established for
URIs in <xref target="RFC3986"/>.</t>
<t hangText="Applications/protocols that use this URI scheme name.">
<vspace/>
The scheme is used by CoAP end-points to access CoAP resources.</t>
<t hangText="Interoperability considerations."><vspace/>
None.</t>
<t hangText="Security considerations."><vspace/>
See "Security considerations" section above.</t>
<t hangText="Contact."><vspace/>
Zach Shelby <zach@sensinode.com></t>
<t hangText="Author/Change controller."><vspace/>
Zach Shelby <zach@sensinode.com></t>
<t hangText="References."><vspace/>
This document.</t>
</list>
</t>
</section>
<section anchor="port-registration" title="Service Name and Port Number Registration">
<t>One of the functions of CoAP is resource discovery: A CoAP
client can ask a CoAP server about the resources offered by it
(see <xref target="discovery"/>). To enable resource discovery
just based on the knowledge of an IP address, the CoAP port for
resource discovery needs to be standardized.</t>
<t>This document requests the assignment of the port number &PORT;
and the service name "coap", in accordance with
<xref target="I-D.ietf-tsvwg-iana-ports"/>.</t>
<t>Besides unicast, CoAP can be used with both multicast and anycast.
<list style="hanging">
<t hangText="Service Name."><vspace/>
coap</t>
<t hangText="Transport Protocol."><vspace/>
UDP</t>
<t hangText="Assignee."><vspace/>
IETF <iesg@ietf.org></t>
<t hangText="Contact."><vspace/>
IESG <iesg@ietf.org></t>
<t hangText="Description."><vspace/>
Constrained Application Protocol (CoAP)</t>
<t hangText="Reference."><vspace/>
This document.</t>
<t hangText="Port Number."><vspace/>
&PORT;</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Acknowledgements">
<t>Special thanks to Peter Bigot and Cullen Jennings
for substantial contributions to the ideas and text in the document, along
with countless detailed reviews and discussions.</t>
<t>Thanks to Michael Stuber, Richard Kelsey, Guido
Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Alexey
Melnikov, Gilbert Clark, Salvatore Loreto, Petri Mutka, Szymon Sasin,
Robert Quattlebaum, Robert Cragie, Angelo Castellani, Tom Herbst, Ed
Beroset, Gilman Tolle, Robby Simpson, Colin O'Flynn, Eric Rescorla,
Matthieu Vial, Linyi Tian, Kerry Lynn, Dale Seed, Akbar Rahman and
David Ryan for helpful comments and discussions that have shaped the
document.</t>
<t>Some of the text has been
lifted from the working documents of the IETF httpbis working group.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2046;
&RFC2616;
&RFC2119;
&RFC4279;
&RFC4303;
&RFC5996;
&RFC4309;
&RFC2818;
&RFC3602;
&RFC3629;
&RFC3986;
&RFC4347;
&RFC4395;
&RFC4648;
&RFC4835;
&RFC5198;
&RFC5226;
&RFC5234;
&RFC5246;
&RFC5280;
&RFC5389;
&RFC5952;
&RFC6066;
</references>
<references title="Informative References">
&RFC3264;
&RFC3542;
&RFC3920;
&RFC4944;
&I-D.eggert-core-congestion-control;
&I-D.ietf-core-block;
&I-D.oflynn-core-bootstrapping;
&I-D.ietf-core-link-format;
<reference anchor="EUI64" target="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">
<front>
<title>GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY</title>
<author><organization/></author><date month='April' day='23' year='2010' />
</front>
</reference>
<reference anchor="EXIMIME" target="http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration">
<front>
<title>Efficient XML Interchange (EXI) Format 1.0</title>
<author><organization/></author><date month='December' day='08' year='2009' />
</front>
</reference>
<reference anchor="OBIX1.1" target="http://www.oasis-open.org/committees/download.php/38212/oBIX-1-1-spec-wd06.pdf">
<front>
<title>OBIX Version 1.1</title>
<author><organization/></author><date month='June' day='08' year='2010' />
</front>
</reference>
&I-D.mcgrew-tls-aes-ccm;
&I-D.mcgrew-tls-aes-ccm-ecc;
&I-D.ietf-tls-rfc4347-bis;
&I-D.ietf-tsvwg-iana-ports;
</references>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="integer" title="Integer Option Value Format">
<t>Options of type uint contain a non-negative integer that is represented
in network byte order using a variable number of bytes, as shown in
<xref target="fig-integer"/>.</t>
<figure anchor="fig-integer" title="Variable-length unsigned integer format">
<artwork><![CDATA[
Length = 0 (implies value of 0)
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
Length = 1 | 0-255 |
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length = 2 | 0-65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length = 3 is 24 bits, Length = 4 is 32 bits etc.
]]></artwork>
</figure>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="examples" title="Examples">
<t>This section gives a number of short examples with message flows
for GET requests. These examples demonstrate the basic operation, the
operation in the presence of retransmissions, and multicast.</t>
<t><xref target="fig-example-1"/> shows a basic GET
request causing an immediate response: The client sends a Confirmable
GET request for the resource coap://server/temperature to the server
with a Message ID of 0x7d34. The request includes one Uri-Path Option
(Delta 0 + 9 = 9, Length 11, Value "temperature"); the Token is
left at its default value (empty). This request is a total of 16
bytes long. A 2.00 (OK) response is returned in the Acknowledgement
message that acknowledges the Confirmable request, echoing both the
Message ID 0x7d34 and the (implicitly empty) Token value. The response
includes a Payload of "22.3 C" and is 10 bytes long.</t>
<figure anchor="fig-example-1" title="Confirmable request; Immediate response">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- CON [0x7d34] GET /temperature [] -------------------->|
| |
|<-------------------- ACK [0x7d34] 2.00 OK [] "22.3 C" ---+
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 2 | GET=1 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 1 | 2.00=64 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<xref target="fig-example-1a"/> shows a similar example, but with the
inclusion of an explicit Token option (Delta 9 + 2 = 11, Length 1,
Value 0x20) in the request and (Delta 11 + 0 = 11) in the response,
increasing the sizes to 18 and 12 bytes, respectively.
</t>
<figure anchor="fig-example-1a" title="Confirmable request; Immediate response">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- CON [0x7d34] GET /temperature [0x20] ---------------->|
| |
|<---------------- ACK [0x7d34] 2.00 OK [0x20] "22.3 C" ---+
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 2 | GET=1 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 1 | 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 1 | 2.00=64 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 1 | 0x20 | "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>In <xref target="fig-example-2"/>, the
Confirmable GET request is lost. After RESPONSE_TIMEOUT seconds,
the client retransmits the request, resulting in an immediate response
as in the previous example.</t>
<figure anchor="fig-example-2" title="Confirmable request (retransmitted); Immediate response">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- CON [0x7d35] GET /temperature [0x31] -----X |
| |
: TIMEOUT :
| |
+--- CON [0x7d35] GET /temperature [0x31] ---------------->|
| |
|<---------------- ACK [0x7d35] 2.00 OK [0x31] "22.3 C" ---+
| |
]]></artwork>
</figure>
<t>In <xref target="fig-example-3"/>, the first
Acknowledgement message from the server to the client is lost. After
RESPONSE_TIMEOUT seconds, the client retransmits the request.</t>
<figure anchor="fig-example-3" title="Confirmable request; Immediate response (retransmitted)">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- CON [0x7d36] GET /temperature [0x42] ---------------->|
| |
| X----- ACK [0x7d36] 2.00 OK [0x42] "22.3 C" ---+
| |
: TIMEOUT :
| |
+--- CON [0x7d36] GET /temperature [0x42] ---------------->|
| |
|<---------------- ACK [0x7d36] 2.00 OK [0x42] "22.3 C" ---+
| |
]]></artwork>
</figure>
<t>In <xref target="fig-example-4"/>, the server
acknowledges the Confirmable request and sends a 2.00 (OK) response
separately in a Confirmable message. Note that the Acknowledgement
message and the Confirmable response do not necessarily arrive in the same
order as they were sent. The client acknowledges the Confirmable
response.</t>
<figure anchor="fig-example-4" title="Confirmable request; Deferred response">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- CON [0x7d36] GET /temperature [0x53] ---------------->|
| |
|<---------------------------------------- ACK [0x7d36] ---+
| |
|<---------------- CON [0xad7b] 2.00 OK [0x53] "22.3 C" ---+
| |
+--- ACK [0xad7b] ---------------------------------------->|
| |
]]></artwork>
</figure>
<t><xref target="fig-example-5"/> shows an example
where the client loses its state (e.g., crashes and is rebooted) right after
sending a Confirmable request,
so the deferred response arriving some time later comes unexpected. In
this case, the client rejects the Confirmable response with a Reset
message. Note that the unexpected ACK is silently ignored.</t>
<figure anchor="fig-example-5" title="Confirmable request; Deferred response (unexpected)">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- CON [0x7d37] GET /temperature [0x64] ---------------->|
XXXXX |
|<---------------------------------------- ACK [0x7d37] ---+
| |
|<---------------- CON [0xad7c] 2.00 OK [0x64] "22.3 C" ---+
| |
+--- RST [0xad7c] ---------------------------------------->|
| |
]]></artwork>
</figure>
<t><xref target="fig-example-6"/> shows a basic GET
request where the request and the response are non-confirmable, so both may
be lost without notice.</t>
<figure anchor="fig-example-6" title="Non-confirmable request; Non-confirmable response">
<artwork><![CDATA[
CLIENT SERVER
| |
+--- NON [0x7d38] GET /temperature [0x75] ---------------->|
| |
|<---------------- NON [0xad7d] 2.00 OK [0x75] "22.3 C" ---+
| |
]]></artwork>
</figure>
<t>In <xref target="fig-example-7"/>, the client
sends a Non-confirmable GET request to a multicast address: all nodes
in link-local scope. There are 3 servers on the link: A, B and C.
Servers A and B have a matching resource, therefore they send back a
Non-confirmable 2.00 (OK) response. The response sent by B is lost.
C does not have matching response, therefore it sends a Non-confirmable
4.04 (Not Found) response.</t>
<figure anchor="fig-example-7" title="Non-confirmable request (multicast); Non-confirmable response">
<artwork><![CDATA[
CLIENT ff02::1 A B C
| | | | |
+--- NON [0x7d39] GET /temperature [0x86] ------->| | | |
| | | |
|<------------- NON [0x60b1] 2.00 OK [0x86] "22.3 C" ---+ | |
| | | |
| X----- NON [0x01a0] 2.00 OK [0x86] "20.9 C" ---+ |
| | | |
|<------------------ NON [0x952a] 4.04 Not Found [0x86] ------+
| | | |
]]></artwork>
</figure>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="uri-examples" title="URI Examples">
<t>The following examples demonstrate different sets of Uri options, and
the result after constructing an URI from them.
<list style="symbols">
<t>coap://[2001:db8::2:1]/
<list style="empty">
<t>Destination IP Address = [2001:db8::2:1]</t>
<t>Destination UDP Port = &PORT;</t>
</list>
</t>
<t>coap://example.net/
<list style="empty">
<t>Destination IP Address = [2001:db8::2:1]</t>
<t>Destination UDP Port = &PORT;</t>
<t>Uri-Host = "example.net"</t>
</list>
</t>
<t>coap://example.net/.well-known/core
<list style="empty">
<t>Destination IP Address = [2001:db8::2:1]</t>
<t>Destination UDP Port = &PORT;</t>
<t>Uri-Host = "example.net"</t>
<t>Uri-Path = ".well-known"</t>
<t>Uri-Path = "core"</t>
</list>
</t>
<t>coap://xn--18j4d.example/%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF
<list style="empty">
<t>Destination IP Address = [2001:db8::2:1]</t>
<t>Destination UDP Port = &PORT;</t>
<t>Uri-Host = "xn--18j4d.example"</t>
<t>Uri-Path = the string composed of the Unicode characters
U+3053 U+3093 U+306b U+3061 U+306f, usually represented in UTF-8 as
E38193E38293E381ABE381A1E381AF hexadecimal</t>
</list>
</t>
<t>coap://198.51.100.1:61616//%2F//?%2F%2F
<list style="empty">
<t>Destination IP Address = 198.51.100.1</t>
<t>Destination UDP Port = 61616</t>
<t>Uri-Path = ""</t>
<t>Uri-Path = "/"</t>
<t>Uri-Path = ""</t>
<t>Uri-Path = ""</t>
<t>Uri-Query = "%2F%2F"</t>
</list>
</t>
<t>coap://[2001:db8::2:1]/sensors/temp
<list style="empty">
<t>Destination IP Address = [::1]</t>
<t>Destination UDP Port = 61616</t>
<t>Uri-Host = "[2001:db8::2:1]"</t>
<t>Uri-Port = &PORT;</t>
<t>Uri-Path = "sensors"</t>
<t>Uri-Path = "temp"</t>
</list>
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Changelog">
<t>Changes from ietf-03 to ietf-04: <list>
<t>o Major document reorganization (#51, #63, #71, #81).</t>
<t>o Max-age length set to 0-4 bytes (#30).</t>
<t>o Added variable unsigned integer definition (#31).</t>
<t>o Clarification made on human readable error payloads (#50).</t>
<t>o Definition of POST improved (#52).</t>
<t>o Token length changed to 0-8 bytes (#53).</t>
<t>o Section added on multiplexing CoAP, DTLS and STUN (#56).</t>
<t>o Added cross-protocol attack considerations (#61).</t>
<t>o Used new Immediate/Deferred response definitions (#73).</t>
<t>o Improved request/response matching rules (#74).</t>
<t>o Removed unnecessary media types and added recommendations for their use in M2M (#76).</t>
<t>o Response codes changed to base 32 coding, new Y.XX naming (#77).</t>
<t>o References updated as per AD review (#79).</t>
<t>o IANA section completed (#80).</t>
<t>o Proxy-Uri option added to diambiguate between proxy and non-proxy requests (#82).</t>
<t>o Added text on critical options in cached states (#83).</t>
<t>o HTTP mapping sections improved (#88).</t>
<t>o Added text on reverse proxies (#72).</t>
<t>o Some security text on multicast added (#54).</t>
<t>o Trust model text added to introduction (#58, #60).</t>
<t>o AES-CCM vs. AES-CCB text added (#55).</t>
<t>o Text added about device capabilities (#59).</t>
<t>o DTLS section improvements (#87).</t>
<t>o Caching semantics aligned with RFC2616 (#78).</t>
<t>o Uri-Path option split into multiple path segments.</t>
<t>o MAX_RETRANSMIT changed to 4 to adjust for RESPONSE_TIME = 2.</t>
</list></t>
<t>Changes from ietf-02 to ietf-03: <list>
<t>o Token Option and related use in asynchronous requests added (#25). </t>
<t>o CoAP specific error codes added (#26).</t>
<t>o Erroring out on unknown critical options changed to a MUST (#27).</t>
<t>o Uri-Query option added. </t>
<t>o Terminology and definitions of URIs improved. </t>
<t>o Security section completed (#22).</t>
</list></t>
<t>Changes from ietf-01 to ietf-02: <list>
<t>o Sending an error on a critical option clarified (#18).</t>
<t>o Clarification on behavior of PUT and idempotent operations
(#19).</t>
<t>o Use of Uri-Authority clarified along with server processing
rules. Uri-Scheme option removed. (#20, #23)</t>
<t>o Resource discovery section removed to a separate CoRE Link
Format draft (#21)</t>
<t>o Initial security section outline added.</t>
</list></t>
<t>Changes from ietf-00 to ietf-01: <list>
<t>o New cleaner transaction message model and header (#5)</t>
<t>o Removed subscription while being designed (#1)</t>
<t>o Section 2 re-written (#3)</t>
<t>o Text added about use of short URIs (#4)</t>
<t>o Improved header option scheme (#5, #14)</t>
<t>o Date option removed whiled being designed (#6)</t>
<t>o New text for CoAP default port (#7)</t>
<t>o Completed proxying section (#8)</t>
<t>o Completed resource discovery section (#9)</t>
<t>o Completed HTTP mapping section (#10)</t>
<t>o Several new examples added (#11)</t>
<t>o URI split into 3 options (#12)</t>
<t>o MIME type defined for link-format (#13, #16)</t>
<t>o New text on maximum message size (#15)</t>
<t>o Location Option added</t>
</list></t>
<t>Changes from shelby-01 to ietf-00: <list>
<t>o Removed the TCP binding section, left open for the future.</t>
<t>o Fixed a bug in the example.</t>
<t>o Marked current Sub/Notify as (Experimental) while under WG
discussion.</t>
<t>o Fixed maximum datagram size to 1280 for both IPv4 and IPv6 (for
CoAP-CoAP proxying to work).</t>
<t>o Temporarily removed the Magic Byte header as TCP is no longer
included as a binding.</t>
<t>o Removed the Uri-code Option as different URI encoding schemes
are being discussed.</t>
<t>o Changed the rel= field to desc= for resource discovery.</t>
<t>o Changed the maximum message size to 1024 bytes to allow for
IP/UDP headers.</t>
<t>o Made the URI slash optimization and method impotence MUSTs</t>
<t>o Minor editing and bug fixing.</t>
</list></t>
<t>Changes from shelby-00 to shelby-01: <list>
<t>o Unified the message header and added a notify message type.</t>
<t>o Renamed methods with HTTP names and removed the NOTIFY
method.</t>
<t>o Added a number of options field to the header.</t>
<t>o Combines the Option Type and Length into an 8-bit field.</t>
<t>o Added the magic byte header.</t>
<t>o Added new Etag option.</t>
<t>o Added new Date option.</t>
<t>o Added new Subscription option.</t>
<t>o Completed the HTTP Code - CoAP Code mapping table appendix.</t>
<t>o Completed the Content-type Identifier appendix and tables.</t>
<t>o Added more simplifications for URI support.</t>
<t>o Initial subscription and discovery sections.</t>
<t>o A Flag requirements simplified.</t>
</list></t>
</section>
</back>
</rfc>
<!-- LocalWords: CoAP IP URIs CoRE datagram confirmable TLV DTLS
-->
<!-- LocalWords: MTU IPsec microcontrollers LoWPAN kbit RESTful IPv
-->
<!-- LocalWords: unicast ACK MID RST cacheable Etag IEEE AES CCM
-->
<!-- LocalWords: NATs TLS PSK requesters proxying proxied backoff
-->
<!-- LocalWords: subcomponent acknowledgement acknowledgements SCTP
-->
| PAFTECH AB 2003-2026 | 2026-04-22 22:23:44 |