CoRE Z. Shelby
Internet-Draft Sensinode
Intended status: Informational B. Frank
Expires: September 2, 2010 Tridium, Inc
March 1, 2010
Constrained Application Protocol (CoAP)
draft-shelby-core-coap-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Shelby & Frank Expires September 2, 2010 [Page 1]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Shelby & Frank Expires September 2, 2010 [Page 2]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Request header . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Response header . . . . . . . . . . . . . . . . . . . . . 5
2.3. Header options . . . . . . . . . . . . . . . . . . . . . . 7
3. Constrained Application Protocol . . . . . . . . . . . . . . . 8
3.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. READ . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.5. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Response codes . . . . . . . . . . . . . . . . . . . . . . 9
3.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Content-type encoding . . . . . . . . . . . . . . . . . . 10
3.5. Message processing . . . . . . . . . . . . . . . . . . . . 11
3.5.1. Request processing . . . . . . . . . . . . . . . . . . 11
3.5.2. Response processing . . . . . . . . . . . . . . . . . 11
3.5.3. Option processing . . . . . . . . . . . . . . . . . . 11
4. Transport Binding . . . . . . . . . . . . . . . . . . . . . . 11
4.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Default Port . . . . . . . . . . . . . . . . . . . . . . . 12
5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Cache control . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Intercept proxy caching . . . . . . . . . . . . . . . . . 13
5.3. Cache refreshing . . . . . . . . . . . . . . . . . . . . . 13
5.4. Sleeping nodes . . . . . . . . . . . . . . . . . . . . . . 13
6. Subscription and Notification . . . . . . . . . . . . . . . . 13
7. Resource Discovery . . . . . . . . . . . . . . . . . . . . . . 13
8. HTTP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Shelby & Frank Expires September 2, 2010 [Page 3]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
1. Introduction
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.
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:
o RESTful protocol design minimizing the complexity of mapping with
HTTP.
o Low header overhead and parsing complexity.
o URI and content-type support.
o Support for the discovery of resources provided by known CoAP
services.
o Simple subscription for a resource, and resulting push
notifications.
o Simple caching based on max-age.
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.
2. Message Formats
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 Section 4.
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
Shelby & Frank Expires September 2, 2010 [Page 4]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
datagram length. When bound to UDP the entire message MUST fit
within in a single datagram. When used with 6LoWPAN [RFC4944],
messages SHOULD fit into a single 802.15.4 frame to minimize
fragmentation.
2.1. Request header
The CoAP request message is used to initiate a CoAP interaction using
the methods listed in Table 1. This message is not restricted to a
pull model, but may also be used to push data e.g. using the NOTIFY
method.
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Request header format
IP Fields:
Source Address: The unicast address of the source.
Destination Address: The unicast address of the destination. A
multicast address can be used with UDP.
Header Fields:
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: 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.
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.
Shelby & Frank Expires September 2, 2010 [Page 5]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
A: 1-bit Acknowledgement flag. When set to 1, indicates that the
destination MUST respond with a response message matching this
request (see Section 4.1). When set to 0, the destination MAY
send a response if appropriate.
Met: Method. 3-bit unsigned integer. Indicates the CoAP Method
of the request according to Table 1. Methods are described in
detail in Section 3.1
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.
_: This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
+--------+------+
| Method | Code |
+--------+------+
| CREATE | 0x0 |
| READ | 0x1 |
| UPDATE | 0x2 |
| DELETE | 0x3 |
| NOTIFY | 0x4 |
+--------+------+
Table 1: Method codes
2.2. Response header
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.
Shelby & Frank Expires September 2, 2010 [Page 6]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Response header format
IP Fields:
Source Address: The unicast address of the responding interface.
Destination Address: The source address of the corresponding
Request.
Header Fields:
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: 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.
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.
_: This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
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.
Code: 8-bit unsigned integer. CoAP response code as defined in
Section 3.2.
Shelby & Frank Expires September 2, 2010 [Page 7]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
2.3. Header options
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:
TODO: Encode Option Type and Option Len into a single byte.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Header option format
Opion Type: 8-bit unsigned integer. The type of the option as
defined in Table 2. The value 0x0 is reserved to indicate no more
options. An Option Type with 0x0 is immediately followed by the
message body (if any).
Option Len 8-bit unsigned integer. The length of the Option Value
field in octets.
Option Value The value in the format defined for that option in
Table 2 with a length of Option Len octets.
The following options are defined in this document. Future options
may be defined in other documents.
+--------+-----------------+-----------------+----------------------+
| Option | Name | Data type | Description |
| Type | | | |
+--------+-----------------+-----------------+----------------------+
| 0x0 | No-more-options | None | Indicates no more |
| | | | options |
| 0x1 | Content-type | 16-bit unsigned | The content-type of |
| | | integer (Len = | the message-body |
| | | 2) | |
| 0x2 | Uri-string | String | The URI of the |
| | | | resource |
| 0x3 | Uri-code | 8-bit unsigned | The URI of the |
| | | integer (Len = | resource |
| | | 1) | |
Shelby & Frank Expires September 2, 2010 [Page 8]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
| 0x4 | Max-age | 16-bit unsigned | The maximum age of |
| | | integer (Len = | the resource for use |
| | | 2) | in caching |
+--------+-----------------+-----------------+----------------------+
Table 2: Option headers
3. Constrained Application Protocol
This section defines CoAP and its processing.
3.1. Methods
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.
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 Section 9.1 [RFC2616]. 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.
3.1.1. CREATE
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.
Responses to this method are not cachable.
3.1.2. READ
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.
The response to a READ is cachable if it meets the requirements in
Shelby & Frank Expires September 2, 2010 [Page 9]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
Section 5.
3.1.3. UPDATE
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).
Responses to this method are not cachable.
3.1.4. DELETE
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.
Responses to this method are not cachable.
3.1.5. NOTIFY
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 Section 6 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.
A NOTIFY request is cachable if it meets the requirements in
Section 5.
3.2. Response codes
CoAP makes use of (a subset of) the HTTP status codes defined in
[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:
Shelby & Frank Expires September 2, 2010 [Page 10]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
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
Figure 4: Response code examples
3.3. URIs
The Universal Resource Locator (URI) [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 Section 7.
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
[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.
The CoAP protocol is identified in URIs when needed with "coap://"
(TODO: IANA considerations).
3.4. Content-type encoding
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 [I-D.shelby-6lowapp-encoding],
which includes recommendations for header indication. The draft
recommends the indication of at least 10 Internet media types (MIME)
[RFC2046] and 2 content transfer encodings.
It is obvious that string names of Internet media types [RFC2046] are
Shelby & Frank Expires September 2, 2010 [Page 11]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
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.
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".
TODO: Content-type and content-encoding identifiers as an appendix.
3.5. Message processing
This section defines the message processing of incoming requests and
responses and possible options.
3.5.1. Request processing
TODO
3.5.2. Response processing
TODO
3.5.3. Option processing
TODO
4. Transport Binding
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.
4.1. UDP
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:
TODO: Full definition of the UDP binding.
Shelby & Frank Expires September 2, 2010 [Page 12]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
o 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).
o 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).
o 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.).
4.2. TCP
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:
o Delivering a large chunk of data.
o Delivering a continuous stream of data, for example streaming
sensor readings for a long period.
o TCP may also be useful for providing congestion control if CoAP is
being applied across the wider Internet.
4.3. Default Port
CoAP has a default port of 61616 (TBD) which is within the compressed
UDP port space defined in [RFC4944]. This default port is the same
for UDP and TCP.
5. Caching
The cachability of CoAP messages will be important, especially with
Shelby & Frank Expires September 2, 2010 [Page 13]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
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.
The following two scenarios have been identified:
o 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.
o An intermediate CoAP proxy may cache subscriptions to a sleeping
node. This requires the Max-age Option Header.
o An intermediate CoAP proxy may use notifications from a node to
update a resource. This requires the Max-age Option Header.
5.1. Cache control
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 [I-D.frank-6lowapp-chopan].
5.2. Intercept proxy caching
See [I-D.frank-6lowapp-chopan].
5.3. Cache refreshing
See [I-D.frank-6lowapp-chopan].
5.4. Sleeping nodes
See [I-D.frank-6lowapp-chopan].
6. Subscription and Notification
See [I-D.shelby-core-coap-req].
7. Resource Discovery
See [I-D.shelby-core-coap-req].
Shelby & Frank Expires September 2, 2010 [Page 14]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
8. HTTP Mapping
See [I-D.shelby-core-coap-req].
9. Examples
TODO
10. Conclusions
TODO
11. Security Considerations
TODO: Expand this section to a full security analysis, including how
to use CoAP with various security options.
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.
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.
12. IANA Considerations
TODO (See IANA comments in the document).
13. Acknowledgments
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.
14. References
Shelby & Frank Expires September 2, 2010 [Page 15]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
14.1. Normative References
[I-D.frank-6lowapp-chopan]
Frank, B., "Chopan - Compressed HTTP Over PANs",
draft-frank-6lowapp-chopan-00 (work in progress),
September 2009.
[I-D.shelby-6lowapp-encoding]
Shelby, Z., Luimula, M., and D. Peintner, "Efficient XML
Encoding and 6LowApp", draft-shelby-6lowapp-encoding-00
(work in progress), October 2009.
[I-D.shelby-core-coap-req]
Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
Kelsey, "CoAP Requirements and Features",
draft-shelby-core-coap-req-00 (work in progress),
February 2010.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
14.2. Informative References
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
Authors' Addresses
Zach Shelby
Sensinode
Kidekuja 2
Vuokatti 88600
FINLAND
Phone: +358407796297
Email: zach@sensinode.com
Shelby & Frank Expires September 2, 2010 [Page 16]
Internet-Draft Constrained Application Protocol (CoAP) March 2010
Brian Frank
Tridium, Inc
Richmond, VA
USA
Phone:
Email: brian.tridium@gmail.com
Shelby & Frank Expires September 2, 2010 [Page 17]