One document matched: draft-shelby-core-coap-00.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 "reference.RFC.0792.xml">
<!ENTITY RFC2045 SYSTEM "reference.RFC.2045.xml">
<!ENTITY RFC2046 SYSTEM "reference.RFC.2046.xml">
<!ENTITY RFC2616 SYSTEM "reference.RFC.2616.xml">
<!ENTITY RFC3986 SYSTEM "reference.RFC.3986.xml">
<!ENTITY RFC4944 SYSTEM "reference.RFC.4944.xml">
<!ENTITY I-D.bormann-6lowpan-6lowapp-problem SYSTEM "reference.I-D.bormann-6lowpan-6lowapp-problem.xml">
<!ENTITY I-D.shelby-6lowapp-encoding SYSTEM "reference.I-D.shelby-6lowapp-encoding.xml">
<!ENTITY I-D.frank-6lowapp-chopan SYSTEM "reference.I-D.frank-6lowapp-chopan.xml">
<!ENTITY I-D.gold-6lowapp-sensei SYSTEM "reference.I-D.draft-gold-6lowapp-sensei-00.xml">
<!ENTITY I-D.martocci-6lowapp-building-applications SYSTEM "reference.I-D.draft-martocci-6lowapp-building-applications-00.xml">
<!ENTITY I-D.sturek-6lowapp-smartenergy SYSTEM "reference.I-D.draft-sturek-6lowapp-smartenergy-00.xml">
<!ENTITY I-D.moritz-6lowapp-dpws-enhancements SYSTEM "reference.I-D.draft-moritz-6lowapp-dpws-enhancements-00.xml">
<!ENTITY I-D.shelby-core-coap-req SYSTEM "reference.I-D.draft-shelby-core-coap-req.xml">
]>
<?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="info" ipr="pre5378Trust200902" docName="draft-shelby-core-coap-00">
<?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 initials="Z" surname="Shelby" fullname="Zach 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="B" surname="Frank" fullname="Brian Frank">
<organization>
Tridium, Inc
</organization>
<address>
<postal>
<street></street>
<city>Richmond, VA</city>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>brian.tridium@gmail.com</email>
</address>
</author>
<!--
<author initials="M" surname="Garrison Stuber" fullname="Michael Garrison Stuber">
<organization>
Itron
</organization>
<address>
<postal>
<street>2111 N. Molter Road</street>
<city>Liberty Lake, WA</city>
<code>99025</code>
<country>U.S.A.</country>
</postal>
<phone>+1.509.891.3441</phone>
<email>Michael.Stuber@itron.com</email>
</address>
</author>
<author initials="D" surname="Sturek" fullname="Don Sturek">
<organization>
Pacific Gas & Electric
</organization>
<address>
<postal>
<street>77 Beale Street</street>
<city>San Francisco, CA</city>
<code></code>
<country>USA</country>
</postal>
<phone>+1-619-504-3615</phone>
<email>d.sturek@att.net</email>
</address>
</author>
<author initials="R" surname="Kelsey" fullname="Richard Kelsey">
<organization>
Ember
</organization>
<address>
<postal>
<street>47 Farnsworth Street</street>
<city>Boston, MA</city>
<code>02210</code>
<country>U.S.A.</country>
</postal>
<phone>+1.617.951.1201</phone>
<email>richard.kelsey@ember.com</email>
</address>
</author>
-->
<date year="2010"/>
<area>Internet</area>
<workgroup>CoRE</workgroup>
<keyword>Requirements, CoAP</keyword>
<abstract>
<t>
This document specifies the Constrained Application Protocol (CoAP), a RESTful protocol for use with constrained networks and nodes. 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. The proposed 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). One of the main goals of CoRE is to design a generic RESTful protocol for the special requirements of this constrained environment, especially considering energy and building automation applications.
</t>
<t>
This document specifies the RESTful Constrained Application Protocol (CoAP) which 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. CoAP has the following main features:
<list style="symbols">
<t>RESTful protocol design minimizing the complexity of mapping with HTTP.</t>
<t>Low header overhead and parsing complexity.</t>
<t>URI and content-type support.</t>
<t>Support for the discovery of resources provided by known CoAP services.</t>
<t>Simple subscription for a resource, and resulting push notifications.</t>
<t>Simple caching based on max-age.</t>
</list>
</t>
<t>
The mapping of CoAP with HTTP is also definied, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='messages' title="Message Formats">
<t>
CoAP makes use of two message types, requests and responses, using a simple binary base header format. The base header may be followed by options in ICMP-style Type-Length-Value format. CoAP is by default bound to UDP and optionally to TCP as described in <xref target="binding"/>.
</t>
<t>
Any bytes after the headers in the packet are considered the message body if any. The length of the message body is implied by the datagram length. When bound to UDP the entire message MUST fit within in a single datagram. When used with 6LoWPAN <xref target="RFC4944"/>, messages SHOULD fit into a single 802.15.4 frame to minimize fragmentation.
</t>
<section anchor='base' title="Request header">
<t>
The CoAP request message is used to initiate a CoAP interaction using the methods listed in <xref target="tab-method"/>. This message is not restricted to a pull model, but may also be used to push data e.g. using the NOTIFY method.
</t>
<figure anchor='fig-req' title="Request header format">
<artwork>
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|O|A| Met |_______________| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Fields:">
<list style="hanging">
<t hangText="Source Address:">
The unicast address of the source.
</t>
<t hangText="Destination Address:">
The unicast address of the destination. A multicast address can be used with UDP.
</t>
</list>
</t>
<t hangText="Header Fields:">
<list style="hanging">
<t hangText="Ver:">
Version. 2-bit unsigned integer. Indicates the version of CoAP. Implementations of this specification MUST set this field to 0. The values 1-3 are reserved for future versions.
</t>
<t hangText="T:">
1-bit Message Type flag. Indicates if this message is a CoAP request (0) or a response (1) header. MUST be set to 0 in a request.
</t>
<t hangText="O:">
1-bit Option flag. Indicates if there are Option Headers following the base header. If set to 1 the byte following the base header is the first Option Type. If set to 0 the message body (if any) immediately follows the base header.
</t>
<t hangText="A:">
1-bit Acknowledgement flag. When set to 1, indicates that the destination MUST respond with a response message matching this request (see <xref target="udp"/>). When set to 0, the destination MAY send a response if appropriate.
</t>
<t hangText="Met:">
Method. 3-bit unsigned integer. Indicates the CoAP Method of the request according to <xref target="tab-method"/>. Methods are described in detail in <xref target="methods"/>
</t>
<t hangText="Transaction ID:">
16-bit unsigned integer. A unique Transaction ID assigned by the source and used to match responses. The Transaction ID MUST be incremented for each new request (regardless of the end-point) and MUST NOT be incremented when retransmitting a request.
</t>
<t hangText="_:">
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
</t>
</list>
</t>
</list>
</t>
<texttable anchor='tab-method' title="Method codes">
<ttcol align='left'>Method</ttcol>
<ttcol align='left'>Code</ttcol>
<c>CREATE</c>
<c>0x0</c>
<c>READ</c>
<c>0x1</c>
<c>UPDATE</c>
<c>0x2</c>
<c>DELETE</c>
<c>0x3</c>
<c>NOTIFY</c>
<c>0x4</c>
</texttable>
</section>
<section anchor='response' title="Response header">
<t>
The CoAP response message is sent in response to a CoAP request when appropriate. Responses include a Transaction ID corresponding to that of the request. A response MUST be sent when the A flag is set in a request, and MAY be sent in the case of a response code or message body. A CoAP response is never used to initiate a message exchange.
</t>
<figure anchor='fig-res' title="Response header format">
<artwork>
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|O|_______| Code | Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Fields:">
<list style="hanging">
<t hangText="Source Address:">
The unicast address of the responding interface.
</t>
<t hangText="Destination Address:">
The source address of the corresponding Request.
</t>
</list>
</t>
<t hangText="Header Fields:">
<list style="hanging">
<t hangText="Ver:">
Version. 2-bit unsigned integer. Indicates the version of CoAP. Implementations of this specification MUST set this field to 0. The values 1-3 are reserved for future versions.
</t>
<t hangText="T:">
1-bit Message Type flag. Indicates if this message is a CoAP Request (0) or a Response (1) header. MUST be set to 1 in a response.
</t>
<t hangText="O:">
1-bit Option flag. Indicates if there are Option Headers following the base header. If set to 1 the byte following the base header is the first Option Type. If set to 0 the message body (if any) immediately follows the base header.
</t>
<t hangText="_:">
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
</t>
<t hangText="Transaction ID:">
16-bit unsigned integer. A unique Transaction ID assigned by the source and used to match Responses. The Transaction ID MUST be incremented for each new Request and MUST NOT be incremented when retransmitting a Request.
</t>
<t hangText="Code:">
8-bit unsigned integer. CoAP response code as defined in <xref target="codes"/>.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor='options' title="Header options">
<t>
CoAP messages may also include one or more header options in TLV format. A reserved Option Type byte (0x0) is used to indicate the last option. To indicate that there are no options, a 0x0 byte immediately follows the header, which is followed by the message body (if any). Each option has the following format:
</t>
<t>
TODO: Encode Option Type and Option Len into a single byte.
</t>
<figure anchor='fig-opt' title="Header option format">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | Option Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t hangText="Option Fields:">
<list style="hanging">
<t hangText="Opion Type:">
8-bit unsigned integer. The type of the option as defined in <xref target="tab-options"/>. The value 0x0 is reserved to indicate no more options. An Option Type with 0x0 is immediately followed by the message body (if any).
</t>
<t hangText="Option Len">
8-bit unsigned integer. The length of the Option Value field in octets.
</t>
<t hangText="Option Value">
The value in the format defined for that option in <xref target="tab-options"/> with a length of Option Len octets.
</t>
</list>
</t>
<t>
The following options are defined in this document. Future options may be defined in other documents.
</t>
<!-- TODO: add a section explaining the use of each option header -->
<texttable anchor='tab-options' title="Option headers">
<ttcol align='left'>Option Type</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Data type</ttcol>
<ttcol align='left'>Description</ttcol>
<c>0x0</c>
<c>No-more-options</c>
<c>None</c>
<c>Indicates no more options</c>
<c>0x1</c>
<c>Content-type</c>
<c>16-bit unsigned integer (Len = 2)</c>
<c>The content-type of the message-body</c>
<c>0x2</c>
<c>Uri-string</c>
<c>String</c>
<c>The URI of the resource</c>
<c>0x3</c>
<c>Uri-code</c>
<c>8-bit unsigned integer (Len = 1)</c>
<c>The URI of the resource</c>
<c>0x4</c>
<c>Max-age</c>
<c>16-bit unsigned integer (Len = 2)</c>
<c>The maximum age of the resource for use in caching</c>
<!-- ZS: Etag may be an optional header if we find that useful -->
</texttable>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='protocol' title="Constrained Application Protocol">
<t>
This section defines CoAP and its processing.
</t>
<section anchor='methods' title="Methods">
<t>
CoAP supports the basic RESTful methods of CREATE, READ, UPDATE, DELETE (CRUD) which are easily mapped to HTTP methods. In addition, a push method called NOTIFY is defined. HTTP naming has been knowingly avoided, as these are overloaded with specific HTTP semantics. In this section each method is defined along with its behaviour.
</t>
<t>
As CoAP methods manipulate resources, they have the same properties of safe (only retrieval) and idempotent (N > 0 identical requests the same as a single request) as HTTP <xref target="RFC2616">Section 9.1</xref>. The READ method is safe, therefore it SHOULD NOT take any other action on a resource other than retrieval. The READ, UPDATE, DELETE and NOTIFY methods can be considered idempotent.
</t>
<section anchor='create' title="CREATE">
<t>
The CREATE method is used to request the server to create a new resource under the requested URI. If a resource has been created on the server, the response should be 201 (Created) incuding the URI of the new resource in the header and any possible status in the message body. If the CREATE does not result in a new resource being created on the server, either a 200 (OK) or 204 (No Content) are used as appropriate response codes.
</t>
<t>
Responses to this method are not cachable.
</t>
</section>
<section anchor='read' title="READ">
<t>
The READ method retrieves the information of the resource identified by the request URI. Upon success a 200 (OK) response SHOULD be sent if the message body includes a status or 204 (No Content) on success if there is no status included.
</t>
<t>
The response to a READ is cachable if it meets the requirements in <xref target="caching"/>.
</t>
</section>
<section anchor='update' title="UPDATE">
<t>
The UPDATE method requests that the resource identified by the request URI be updated with the enclosed message body. If a resource exists at that URI the message body SHOULD be considered a modified version of that resource. If no resource exists then the server MAY create a new resource with that URI, responding like the CREATE method (TBD if this behaviour of POST should be supported in CoAP).
</t>
<t>
Responses to this method are not cachable.
</t>
</section>
<section anchor='delete' title="DELETE">
<t>
The DELETE method requests that the resource identified by the request URI be deleted.
The response 200 (OK) SHOULD be sent on success if the message body includes a status, 202 (Accepted) if the action has not yet been taken, or 204 (No Content) on success if there is no status included.
</t>
<t>
Responses to this method are not cachable.
</t>
</section>
<section anchor='notify' title="NOTIFY">
<t>
The NOTIFY method allows for a push interaction and can be initiated by a server or client. NOTIFY requests that the message body it contains (if any) be accepted by the resource identified by the request URI. Typically this resource is a collector for incoming data generated by subscriptions as defined in <xref target="subscription"/> but NOTIFY may be used for other push uses unrelated to subscription. Upon success a 200 (OK) response SHOULD be sent if the message body includes a status or 204 (No Content) on success if there is no status included.
</t>
<t>
A NOTIFY request is cachable if it meets the requirements in <xref target="caching"/>.
</t>
</section>
</section>
<section anchor='codes' title="Response codes">
<t>
CoAP makes use of (a subset of) the HTTP status codes defined in <xref target="RFC2616"/> (Exact subset TBD). The HTTP status code is encoded into a single byte where the top 3-bits represent the 100s decimal digit, and the bottom 5-bits represent the last two decimal digits. Example of the encoding:
</t>
<figure anchor='fig-codes' title="Response code examples">
<artwork>
1xx -> 0x2X, b001x_xxxx
2xx -> 0x4X, b010x_xxxx
3xx -> 0x6X, b011x_xxxx
4xx -> 0x8X, b100x_xxxx
5xx -> 0xAX, b101x_xxxx
200 -> 0x40 // OK
404 -> 0x84 // Not Found
415 -> 0x4F // Unsupported Media Type
417 -> 0x51 // Expectation Failed
</artwork>
</figure>
</section>
<section anchor='uri' title="URIs">
<t>
The Universal Resource Locator (URI) <xref target="RFC3986"/> is an important feature of the REST architecture, the relative part of the URI indicates which resource is being manipulated. CoAP supports variable-length string URIs with the Uri-string Option Header.
Although URIs can be designed for compactness, this still often results in 10s of bytes of overhead. For this reason an alternative 8-bit integer code can be used identify a string URI using the Uri-code Option Header. URI codes mappings to URI strings are provided in the response to CoAP resource discovery as defined in <xref target="discovery"/>.
</t>
<t>
The encoding of the Uri-string Option Header value also needs to be considered, as this is becoming increasingly complex. All URI strings in CoAP MUST be in the US-ASCII encoding defined in <xref target="RFC3986"/>, as URI parsing is complex and may result in security problems on constrained devices. TBD if a stricter subset of the URI format should be defined.
</t>
<t>
The CoAP protocol is identified in URIs when needed with "coap://" (TODO: IANA considerations).
</t>
</section>
<section anchor='content-type' title="Content-type encoding">
<t>
In order to support hetergenous uses, it is important that CoAP is transparent to the use of different application payloads. In order for the application process receiving a packet to properly parse a payload, its content-type and encoding should be explicitly known from the header (as e.g. with HTTP). The use of typical binary encodings for XML is discussed in <xref target="I-D.shelby-6lowapp-encoding"/>, which includes recommendations for header indication. The draft recommends the indication of at least 10 Internet media types (MIME) <xref target="RFC2046"/> and 2 content transfer encodings.
</t>
<t>
It is obvious that string names of Internet media types <xref target="RFC2046"/> are not appropriate for use in the CoAP header. CoAP simply assign identifiers to a subset of common MIME and content transfer encoding types, which IANA should maintain (TODO: Discuss in IANA considerations section). A field of 16-bits is sufficient for encoding both media and content transfer encoding types. These 16-bit identifiers are included in the Content-type Option Header of messages to indicate the type and encoding of the message body.
</t>
<t>
TBD: For extending some types, magic numbers could also be used in the beginning of the payload (as defined in associated Internet media type RFCs). This is indicated by a Content-type value indicating "See magic numbers".
</t>
<t>
TODO: Content-type and content-encoding identifiers as an appendix.
</t>
</section>
<section anchor='processing' title="Message processing">
<t>
This section defines the message processing of incoming requests and responses and possible options.
</t>
<section anchor='processing-req' title="Request processing">
<t>
TODO
</t>
</section>
<section anchor='processing-res' title="Response processing">
<t>
TODO
</t>
</section>
<section anchor='processing-opt' title="Option processing">
<t>
TODO
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='binding' title="Transport Binding">
<t>
The CoAP protocol will operate by default over UDP. There may be optional functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. This section defines the binding of CoAP over UDP and TCP.
</t>
<section anchor='udp' title="UDP">
<t>
The goal of binding CoAP to UDP is to provide the bare minimum features for the protocol to operate over UDP, going nowhere near trying to re-create the full feature set of TCP. CoAP over UDP has the following features:
</t>
<t>
TODO: Full definition of the UDP binding.
<list style="symbols">
<t>Stop-and-wait reliability. The CoAP response message is used as an acknowledgement with retransmission support (details TBD). Not all requests require reliability, thus this is optional using the A flag in a request. Performance is not the key here and for more sophisticated reliability and flow control TCP could be used (when TBD). </t>
<t>The Transaction ID in CoAP message headers is used to match responses to open requests and is generated by the client (common counter across all requests).</t>
<t>Multicast support. Providing reliability with a multicast destination address would be very complex. Therefore the goal is to provide a non-reliable multicast service. In many cases there may not be a response to a multicast message. A multicast command might result in an action being taken at a device, but no response being sent. Therefore a multicast request may be answered with a unicast response, however without reliability (retransmission e.g.).</t>
</list>
</t>
</section>
<section anchor='tcp' title="TCP">
<t>
The CoAP protocol also may also make use of TCP for some features. As TCP provides a reliable stream this binding does not require anything special from the CoAP protcol design. The same basic messages could be applied over TCP without stop-and-wait. A transaction ID should still be used over TCP. The question is for which features, or in which configurations would TCP be recommended? The following have been identified so far:
<list style="symbols">
<t>Delivering a large chunk of data.</t>
<t>Delivering a continuous stream of data, for example streaming sensor readings for a long period.</t>
<t>TCP may also be useful for providing congestion control if CoAP is being applied across the wider Internet.</t>
</list>
</t>
</section>
<section anchor='port' title="Default Port">
<t>
CoAP has a default port of 61616 (TBD) which is within the compressed UDP port space defined in <xref target="RFC4944"/>. This default port is the same for UDP and TCP.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='caching' title="Caching">
<t>
The cachability of CoAP messages will be important, especially with the sleeping node configurations and power limitations typically found in constrained networks and nodes. What features of cachability are really required and how much energy are we willing to spend on it? Roughly 50% of the HTTP specifications are dedicated to sohpisticated caching. With CoAP we should look at the bare minimum caching feature possible for caching responses with intercept proxy caching.
</t>
<t>
The following two scenarios have been identified:
<list style="symbols">
<t>An intermediate CoAP proxy may cache resources and answer READ requests using a cached version. The resource may be cached from previous responses or notifications. This requires the Max-age Option Header. </t>
<t>An intermediate CoAP proxy may cache subscriptions to a sleeping node. This requires the Max-age Option Header.</t>
<t>An intermediate CoAP proxy may use notifications from a node to update a resource. This requires the Max-age Option Header.</t>
</list>
</t>
<section anchor='cache-control' title="Cache control">
<t>
Max-age approach is simplest based on timeouts. TBD if we also support an Etag style hash approach for detecting changes in a resource as well. See <xref target="I-D.frank-6lowapp-chopan"/>.
</t>
</section>
<section anchor='proxy-caching' title="Intercept proxy caching">
<t>
See <xref target="I-D.frank-6lowapp-chopan"/>.
</t>
</section>
<section anchor='cache-refreshing' title="Cache refreshing">
<t>
See <xref target="I-D.frank-6lowapp-chopan"/>.
</t>
</section>
<section anchor='sleeping' title="Sleeping nodes">
<t>
See <xref target="I-D.frank-6lowapp-chopan"/>.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='subscription' title="Subscription and Notification">
<t>
See <xref target="I-D.shelby-core-coap-req"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='discovery' title="Resource Discovery">
<t>
See <xref target="I-D.shelby-core-coap-req"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='http' title="HTTP Mapping">
<t>
See <xref target="I-D.shelby-core-coap-req"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='examples' title="Examples">
<t>
TODO
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Conclusions">
<t>
TODO
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<t>
TODO: Expand this section to a full security analysis, including how to use CoAP with various security options.
</t>
<t>
Some of the features considered in this document will need further security considerations during a protocol design. For example the use of string URLs may have entail security risks due to complex processing on limited microcontroller implementations.
</t>
<t>
The CoAP protocol will be designed for use with e.g. (D)TLS or object security. A protocol design should consider how integration with these security methods will be done, how to secure the CoAP header and other implications.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
TODO (See IANA comments in the document).
</t>
</section>
<!------------------------------------------------------>
<!-- SECTION: ACKNOWLEDGMENTS -->
<!------------------------------------------------------>
<section title="Acknowledgments">
<t>Thanks to Carsten Bormann, Don Sturek, Michael Stuber, Richard Kelsey, Cullen Jennings, Guido Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Gilbert Clark and Salvatore Loreto for helpful comments and discussions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2046;
&RFC2616;
&RFC3986;
&I-D.frank-6lowapp-chopan;
&I-D.shelby-6lowapp-encoding;
&I-D.shelby-core-coap-req;
</references>
<references title='Informative References'>
&RFC4944;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:00 |