[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-shelby-6lowapp-coap) 00 01 draft-ietf-core-coap

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]


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