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

Versions: (draft-hartke-coap-observe) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 7641

CoRE Working Group                                             K. Hartke
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                               Z. Shelby
Expires: September 16, 2011                                    Sensinode
                                                          March 15, 2011


                      Observing Resources in CoAP
                       draft-ietf-core-observe-02

Abstract

   CoAP is a RESTful application protocol for constrained nodes and
   networks.  The state of a resource on a CoAP server can change over
   time.  This specification provides a simple extension for CoAP that
   gives clients the ability to observe such changes.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 16, 2011.

Copyright Notice

   Copyright (c) 2011 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
   (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 Simplified BSD License.



Hartke & Shelby        Expires September 16, 2011               [Page 1]


Internet-Draft         Observing Resources in CoAP            March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Observation Relationships  . . . . . . . . . . . . . . . . . .  5
     3.1.  Establishment  . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Maintenance  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Termination  . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Notifications  . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Strategies . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Retransmission . . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  Reordering . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Caching  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Observe Option . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Interactions with other CoAP features  . . . . . . . . . . . . 11
     6.1.  Request Methods  . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Block-wise Transfers . . . . . . . . . . . . . . . . . . . 11
     6.3.  Resource Discovery . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 15
     A.1.  Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Appendix B.  Changelog . . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19























Hartke & Shelby        Expires September 16, 2011               [Page 2]


Internet-Draft         Observing Resources in CoAP            March 2011


1.  Introduction

   CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained
   Nodes/Networks.  It is intended to provide RESTful services [REST]
   not unlike HTTP [RFC2616], while reducing the complexity of
   implementation as well as the size of packets exchanged in order to
   make these services useful in a highly constrained network of
   themselves highly constrained nodes.

   The state of a resource on a CoAP server can change over time.  We
   want to give CoAP clients the ability to observe this change.
   However, existing approaches from the HTTP world, such as repeated
   polling or long-polls, generate significant complexity and/or
   overhead and thus are less applicable in the constrained CoAP world.
   Instead, a much simpler mechanism is provided to solve the basic
   problem of resource observation.  Note that there is no intention for
   this mechanism to solve the full set of problems that the existing
   HTTP solutions solve, or to replace publish/subscribe networks that
   solve a much more general problem [RFC5989].

   This specification describes an architecture and a protocol design
   that realizes the well-known subject/observer design pattern within
   the REST-based environment of CoAP.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Where arithmetic is explained, this document uses the notation
   familiar from the programming language C, except that the operator
   "^" stands for exponentiation.


2.  Overview

   In the subject/observer design pattern, an object, called the
   subject, maintains a list of interested parties, called observers,
   and notifies them automatically when a predefined condition, event or
   state change occurs.  The subject provides a way for observers to
   register themselves with the subject.  This pattern supports a clean
   separation between components, such as data storage and user
   interface.









Hartke & Shelby        Expires September 16, 2011               [Page 3]


Internet-Draft         Observing Resources in CoAP            March 2011


   Observer           Subject
      |                  |
      |     Register     |
      +----------------->|
      |                  |
      |   Notification   |
      |<-----------------+
      |                  |
      |   Notification   |
      |<-----------------+
      |                  |
      |   Notification   |
      |<-----------------+
      |                  |

                 Figure 1: Subject/Observer Design Pattern

   The design pattern is realized in CoAP as follows:

   Subject:  In the context of CoAP, the subject is a resource located
      at some CoAP server.  The state of the resource may change over
      time, ranging from infrequent updates to continuous state
      transformations.

   Observer:  The observer is a CoAP client that is interested in the
      current state of the resource at any given time.

   Observation Relationship:  A client registers itself with a resource
      by sending a modified GET request to the server.  The request
      causes the server to establish an observation relationship between
      the client and the resource.  The response to the GET request
      supplies the client with a representation of the current resource
      state.

   Notification:  Whenever the state of a resource changes, the server
      notifies each client that has an observation relationship to that
      resource.  The notification is an additional response to the GET
      request; it supplies the client with a representation of the new
      resource state.  The response echoes the token specified in the
      request, so the client can easily correlate notifications.

   Figure 2 shows an example of a CoAP client establishing an
   observation relationship to a resource on a CoAP server and being
   notified, once upon registration and then whenever the state of the
   resource changes.  The request to establish an observation
   relationship and all notifications are identified by the new Observe
   Option defined in this document.




Hartke & Shelby        Expires September 16, 2011               [Page 4]


Internet-Draft         Observing Resources in CoAP            March 2011


   Client              Server
      |                  |
      | GET /temperature |
      |  Observe: 0      |  (establish observation relationship)
      |    Token: 0x4a   |
      +----------------->|
      |                  |
      |   2.05 Content   |
      |  Observe: 12     |  (initial notification of current state)
      |    Token: 0x4a   |
      |  Payload: 22.9 C |
      |<-----------------+
      |                  |
      |   2.05 Content   |
      |  Observe: 44     |  (notification upon state change)
      |    Token: 0x4a   |
      |  Payload: 22.8 C |
      |<-----------------+
      |                  |
      |   2.05 Content   |
      |  Observe: 60     |  (notification upon state change)
      |    Token: 0x4a   |
      |  Payload: 23.1 C |
      |<-----------------+
      |                  |

                  Figure 2: Observing a Resource in CoAP


3.  Observation Relationships

3.1.  Establishment

   A client registers itself with a resource by performing a GET request
   that includes an Observe Option.  (See Section 5 for the option
   definition.)  When a server receives such a request, it services the
   request like a GET request without this option and, if the resulting
   response indicates success, establishes an observation relationship
   between the client and the target resource.

   The token specified by the client in the GET request will be echoed
   by the server in the initial response and in all notifications sent
   to the client as part of the observation relationship.  The server
   will also include an Observe Option in each response/notification to
   indicate that the observation relationship was successfully
   established.  (See Section 4 for the details of notifications.)

   A server that is unable or unwilling to establish an observation



Hartke & Shelby        Expires September 16, 2011               [Page 5]


Internet-Draft         Observing Resources in CoAP            March 2011


   relationship between a client and a resource MUST silently ignore the
   Observe Option and process the GET request as usual.  The resulting
   response will not include an Observe Option, implying that no
   observation relationship was established.

3.2.  Maintenance

   A client MAY refresh an observation relationship at any time.  (For
   example, when it didn't receive a notification for some time, it is
   not clear whether the resource never changed or the server rebooted
   and lost its state -- this is similar to the keep-alive problem of
   transport protocols, see e.g. the discussion in [RFC1122].)  However,
   it is RECOMMENDED that the client does not refresh the relationship
   for the time specified in the Max-Age Option of the most recent
   notification received, including the initial response.

   A client refreshes an observation relationship simply by repeating
   the GET request with the Observe Option.  When a server receives such
   a repeated request (i.e. a GET request from a client for which an
   observation relationship already exists), it MUST NOT establish a
   second relationship but replace or update the existing one.  If a GET
   request does not include an Observe Option, the server MUST end any
   relationship that may exist between the client and the target
   resource.

   The exact rules for determining if two requests relate to the same
   observation relationship are as follows:

   o  The request URI of the two requests MUST match.

   o  The sources of the two requests MUST match.  How this is
      determined depends on the security mode used (see Section 10 of
      [I-D.ietf-core-coap]): With NoSec, the IP address and port number
      of the request sources must match.  With other security modes, in
      addition to the IP address and UDP port number matching, the
      requests must have the same security context.

   o  The Message IDs and any Token Options in the two requests MUST NOT
      be taken into account.

3.3.  Termination

   The observation relationship between a client and a resource ends
   when one of the following conditions occurs:

   o  The server sends a notification response with an error response
      code (4.xx or 5.xx).




Hartke & Shelby        Expires September 16, 2011               [Page 6]


Internet-Draft         Observing Resources in CoAP            March 2011


   o  The client rejects a confirmable notification with a RST message.

   o  The last attempt of transmitting a confirmable notification to the
      client times out.  (In this case, the server MAY also end all
      other observation relationships that the client has.)

   A client MAY terminate an observation relationship by performing one
   of the following actions:

   o  The client rejects a confirmable notification with a RST message.

   o  The client performs a GET request on the resource without an
      Observe Option.


4.  Notifications

   When an observation relationship is established between a client and
   a resource, the client is notified of resource state changes by
   additional responses sent in reply to the GET request to the client.
   Each such notification response MUST include an Observe Option and
   echo the token specified by the client in the request.  The order in
   which observers are notified about a state change is not defined; the
   server is free to use any method to determine the order.

   A notification SHOULD have a 2.05 (Content) or 2.03 (Valid) response
   code.  However, in the event that the state of a resource is changed
   in a way that would cause a basic GET request to return an error (for
   example, when the resource is deleted), the server SHOULD notify the
   client by sending a notification with an appropriate error code and
   MUST end the observation relationship.

   The representation format (i.e. the media type) used in any
   notification resulting from an observation relationship MUST be the
   same format used in the initial response to the GET request.  If the
   server is unable to continue sending notifications in this format, it
   SHOULD send a 5.00 (Internal Server Error) notification response and
   MUST end the observation relationship.

   A notification can be sent confirmable or non-confirmable.  A server
   can employ different strategies for notifying a client; see
   Section 4.1 below.  The objective is that the state observed by the
   client eventually becomes consistent with the actual state of the
   resource.

   If a client does not recognize the token in a confirmable
   notification, it MUST NOT acknowledge the message and SHOULD reject
   the message with a RST message (in which case the server MUST end the



Hartke & Shelby        Expires September 16, 2011               [Page 7]


Internet-Draft         Observing Resources in CoAP            March 2011


   observation).  Otherwise, the client MUST acknowledge the message
   with an ACK message as usual.  See Section 4.2 for details on the
   retransmission of confirmable messages.

   Note that notifications may arrive in a different order than sent by
   the server due to network latency.  If a notification arrives before
   the initial response to a request, the client can take the
   notification as initial response in place of the actual initial
   response.  The client must be prepared to receive notifications after
   an error notification or after the client has requested the server to
   end the observation relationship.  See Section 4.3 for further
   details on message reordering.

   Notifications MAY be cached by CoAP end-points under the same
   conditions as with all responses.  This is detailed in Section 4.4.

4.1.  Strategies

   The objective when notifying clients of state changes is that the
   state observed by the client eventually becomes consistent with the
   actual state of the resource.  This allows the server some liberties
   in how it sends notifications, as long as it works towards this
   objective.

   A notification can be sent confirmable or non-confirmable.  The
   message type used is typically application-dependent and MAY be
   determined by the server for each notification individually.  For
   example, for resources that change in a somewhat predictable or
   regular fashion, notifications can be sent in non-confirmable
   messages.  For resources that change infrequently, notifications can
   be sent in confirmable messages.  The server can combine these two
   approaches depending on the frequency of state changes and the
   importance of individual notifications.

   A server MAY choose to omit notifying a client of a state change if
   it knows that it will send another notification soon (e.g., when the
   state is changing frequently or maybe even continuously).  Similarly,
   it MAY choose to notify a client about the same state change more
   than once.  For example, when state changes occur in bursts, the
   server can omit some notifications, send others in non-confirmable
   messages, and make sure that the client observes the latest state
   change by repeating the last notification in a confirmable message
   when the burst is over.

4.2.  Retransmission

   According to the core CoAP protocol, confirmable messages are
   retransmitted in exponentially increasing intervals for a certain



Hartke & Shelby        Expires September 16, 2011               [Page 8]


Internet-Draft         Observing Resources in CoAP            March 2011


   number of attempts until they are acknowledged by the client.  In the
   context of observing a resource, it is undesirable to continue
   transmitting the representation of a resource state when the state
   changed in the meantime.  There are many reasons why a client might
   not acknowledge a confirmable message, ranging from short
   interruptions in the network to a permanent failure of the client.

   When a server is retransmitting a confirmable message with a
   notification, is waiting for an acknowledgement, and wants to notify
   the client of a state change using a new confirmable message, it MUST
   stop retransmitting the old notification and MUST attempt to transmit
   the new notification with the number of attempts remaining from the
   old notification.  When the last attempt to retransmit a confirmable
   message with a notification for a resource times out, the observation
   relationship is ended.

4.3.  Reordering

   Messages with notifications can arrive in a different order than they
   were sent.  Since the objective is eventual consistency, a client can
   safely discard a notification that arrives later than a newer
   notification.

   For this purpose, the server keeps a single 16-bit unsigned integer
   variable.  The variable is incremented approximately every second,
   wrapping around every 2^16 seconds (roughly 18.2 hours).  The server
   MUST include the current value of the variable as the value of the
   Observe Option each time it sends a notification.  The server MUST
   NOT send two notifications with the same value of the variable that
   pertain to the same resource to the same client.

   A client MAY discard a notification as outdated (not fresh) under the
   following condition:

      (V1 - V2) % (2^16) < (2^15)    and    T2 < (T1 + (2^14))

   where T1 is a client-local timestamp of the latest valid notification
   received for this resource (in seconds), T2 a client-local timestamp
   of the current notification, V1 the value of the Observe Option of
   the latest valid notification received, and V2 the value of the
   Observe Option of the current notification.  The first condition
   essentially verifies that V2 > V1 holds in 16-bit sequence number
   arithmetic [RFC1982].  The second condition checks that the time
   expired between the two incoming messages is not so large that the
   sequence number might have wrapped around and the first check is
   therefore invalid (but is not needed any more, because reordering is
   not expected to occur on the order of 2^14 seconds).  Note that the
   constants of 2^14 and 2^15 are non-critical, as is the even speed of



Hartke & Shelby        Expires September 16, 2011               [Page 9]


Internet-Draft         Observing Resources in CoAP            March 2011


   the clocks involved; e.g., the second check can be implemented by
   marking a response as fresh on reception and downgrading all
   responses periodically every, say, 2^13 seconds; once it has been
   downgraded twice, it no longer participates in freshness checks.

4.4.  Caching

   As notifications are just additional responses to a GET request, the
   same rules on caching apply as to all responses: CoAP end-points MAY
   cache the responses and thereby reduce the response time and network
   bandwidth consumption.  Both the freshness model and the validation
   model are supported.

   When a response is fresh in the cache, GET requests can be satisfied
   without contacting the origin server.  This is particularly useful
   when the cache is located at an CoAP intermediary such as a proxy or
   reverse proxy.  (Note that the freshness of the stored response is
   determined by its Max-Age Option, not the existence of an observation
   relationship.  So a request can cause the end-point to refresh cache
   and observation relationship even while having an relationship.)

   When an end-point has one or more responses stored, it can use the
   ETag Option to give the origin server an opportunity to select a
   stored response to be used.  The end-point SHOULD add an ETag Option
   specifying the entity-tag of each stored response that is applicable.
   It MUST keep those responses in the cache until it terminates the
   observation relationship or sends a GET request with a new set of
   entity-tags.  When the observed resource changes its state and the
   origin server is about to send a 2.05 (Content) notification, then,
   whenever that notification has an entity-tag in the set of entity-
   tags specified by the client, it sends a 2.03 (Valid) response with
   an appropriate ETag Option instead.  The server MUST NOT assume that
   the recipient has any response stored other than those identified by
   the entity-tags in the most recent request.


5.  Observe Option

         +-----+----------+---------+--------+--------+---------+
         | No. | C/E      | Name    | Format | Length | Default |
         +-----+----------+---------+--------+--------+---------+
         |  10 | Elective | Observe | uint   | 0-2 B  | (none)  |
         +-----+----------+---------+--------+--------+---------+

                           Table 1: New Options

   The Observe Option, when present, modifies the GET method so it does
   not only retrieve a representation of the current state of the



Hartke & Shelby        Expires September 16, 2011              [Page 10]


Internet-Draft         Observing Resources in CoAP            March 2011


   resource identified by the request URI once, but also lets the server
   notify the client of changes to the resource state.

   In a response, the Observe Option indicates that an observation
   relationship has been established.  The option's value is a sequence
   number that can be used for reordering detection (see Section 4.3).
   The value is encoded as a variable-length unsigned integer (see
   Appendix A of [I-D.ietf-core-coap]).

   Since the Observe Option is elective, a GET request that includes the
   Observe Option will automatically fall back to a basic GET request if
   the server does not support observations.


6.  Interactions with other CoAP features

6.1.  Request Methods

   If a client has an observation relationship with a resource and
   performs a POST, PUT or DELETE request on that resource, the request
   MUST NOT affect the observation relationship.  However, since such a
   request can affect the observed resource, it can cause the server to
   send a notification with a resource state representation or end the
   observation relationship with an error notification (e.g., when a
   DELETE request is successful and an observed resource no longer
   exists).

   Note that a client cannot perform a GET request on a resource to
   retrieve a representation of the current resource state without
   affecting an existing observation relationship to that resource: the
   client is already notified by the server with a fresh representation
   whenever the state changes.  If the client wants to make sure that is
   has a fresh representation and wants to continue being notified, it
   should refresh the observation relationship (see Section 3.2).  If
   the client wants to make sure it has a fresh representation and does
   not want to continue being notified, it should perform a GET request
   without an Observe Option (see Section 3.3).

6.2.  Block-wise Transfers

   Resources that are the subject of an observation relationship may be
   larger than can be comfortably processed or transferred in one CoAP
   message.  CoAP provides a block-wise transfer mechanism to address
   this problem [I-D.ietf-core-block].  The following rules apply to the
   combination of block-wise transfers with notifications:

   o  As with basic GET transfers, the client can indicate its desired
      block size in a Block option in the GET request.  If the server



Hartke & Shelby        Expires September 16, 2011              [Page 11]


Internet-Draft         Observing Resources in CoAP            March 2011


      supports block-wise transfers, it SHOULD take note of the block
      size not just for the initial response but also for further
      notifications in this observation relationship.

   o  Notification responses can make use of the Block option.  The
      client SHOULD use the Observe option value from the last block.
      All blocks in a notification response SHOULD also carry an ETag
      option to ensure they are reassembled correctly.

6.3.  Resource Discovery

   Clients can discover resources that are interesting to observe using
   CoRE Resource Discovery [I-D.ietf-core-link-format].  Links with the
   "obs" attribute indicate resources that MUST support the mechanism in
   this document and are RECOMMENDED to change their state at least once
   in a while.

   The "obs" attribute is used as a flag, and thus it has no value
   component.  The attribute MUST NOT appear more than once in a link.


7.  Security Considerations

   The security considerations of the base protocol [I-D.ietf-core-coap]
   apply.

   Note that the considerations about amplification attacks are somewhat
   amplified in an observation relationship.  In NoSec mode, a server
   MUST therefore strictly limit the number of messages generated from
   an observation relationship that it sends between receiving packets
   that confirm the actual interest of the recipient in the data; i.e.,
   any notifications sent in Non-Confirmable messages MUST be
   interspersed with Confirmable messages.  (An Attacker may still spoof
   the acknowledgements if the Confirmable messages are sufficiently
   predictable.)

   As with any protocol that creates state, attackers may attempt to
   exhaust the resources that the server has available for maintaining
   observation relationships.  Servers MAY want to access-control this
   creation of state.  As degraded behavior, the server can always fall
   back to a basic GET request (without an Observe option) if it is
   unwilling or unable to establish the observation relationship,
   including if resources for state are exhausted or nearing exhaustion.

   Intermediaries MUST be careful to ensure that notifications cannot be
   employed to create a loop.  A simple way to break any loops is to
   employ caches for forwarding notifications in intermediaries.




Hartke & Shelby        Expires September 16, 2011              [Page 12]


Internet-Draft         Observing Resources in CoAP            March 2011


8.  IANA Considerations

   The following entry is added to the CoAP Option Numbers registry:

                     +--------+---------+-----------+
                     | Number | Name    | Reference |
                     +--------+---------+-----------+
                     |     10 | Observe | [RFCXXXX] |
                     +--------+---------+-----------+

                     Table 2: New CoAP Option Numbers

   The following entry is added to the CoRE Link Format Attribute
   registry:

                           +------+-----------+
                           | Name | Reference |
                           +------+-----------+
                           | obs  | [RFCXXXX] |
                           +------+-----------+

                 Table 3: New CoRE Link Format Attributes


9.  Acknowledgements

   Carsten Bormann was an original author of this draft and is
   acknowledged for significant contribution to this document.

   Thanks to Daniele Alessandrelli, Peter Bigot, Angelo Castellani,
   Gilbert Clark, Esko Dijk, Brian Frank and Salvatore Loreto for
   helpful comments and discussions that have shaped the document.

   Klaus Hartke was funded by the Klaus Tschira Foundation.


10.  References

10.1.  Normative References

   [I-D.ietf-core-block]
              Shelby, Z. and C. Bormann, "Blockwise transfers in CoAP",
              draft-ietf-core-block-02 (work in progress), March 2011.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-05 (work in progress), March 2011.



Hartke & Shelby        Expires September 16, 2011              [Page 13]


Internet-Draft         Observing Resources in CoAP            March 2011


   [I-D.ietf-core-link-format]
              Shelby, Z., "CoRE Link Format",
              draft-ietf-core-link-format-03 (work in progress),
              March 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000, <http://
              www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 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.

   [RFC5989]  Roach, A., "A SIP Event Package for Subscribing to Changes
              to an HTTP Resource", RFC 5989, October 2010.

























Hartke & Shelby        Expires September 16, 2011              [Page 14]


Internet-Draft         Observing Resources in CoAP            March 2011


Appendix A.  Examples

   Client  Server
      |      |
      |      |
      +----->|     Header: GET (T=CON, Code=1, MID=0x1633)
      | GET  |      Token: 0x4a
      |      |        Uri: coap://sensor.example/temperature
      |      |    Observe: 0
      |      |
      |      |
      |<-----+     Header: 2.05 Content (T=ACK, Code=69, MID=0x1633)
      | 2.05 |      Token: 0x4a
      |      |    Observe: 27
      |      |    Payload: "22.9 C"
      |      |
      |      |
      |<-----+     Header: 2.05 Content (T=NON, Code=69, MID=0x7b50)
      | 2.05 |      Token: 0x4a
      |      |    Observe: 28
      |      |    Payload: "22.8 C"
      |      |
      |      |
      |<-----+     Header: 2.05 Content (T=NON, Code=69, MID=0x7b51)
      | 2.05 |      Token: 0x4a
      |      |    Observe: 29
      |      |    Payload: "22.5 C"
      |      |

      Figure 3: Simple observation with non-confirmable notifications





















Hartke & Shelby        Expires September 16, 2011              [Page 15]


Internet-Draft         Observing Resources in CoAP            March 2011


A.1.  Proxying

Client  Proxy  Server
   |      |      |
   |      |      |
   |      +----->|     Header: GET (T=CON, Code=1, MID=0x5fb8)
   |      | GET  |      Token: 0x1a
   |      |      |        Uri: coap://sensor.example/status
   |      |      |    Observe: 0
   |      |      |
   |      |      |
   |      |<-----+     Header: 2.05 Content (T=ACK, Code=69, MID=0x5fb8)
   |      | 2.05 |      Token: 0x1a
   |      |      |    Observe: 42
   |      |      |    Max-Age: 120 sec
   |      |      |    Payload: "ready"
   |      |      |
   |      |      |
   +----->|      |     Header: GET (T=CON, Code=1, MID=0x1633)
   | GET  |      |      Token: 0x9a
   |      |      |  Proxy-Uri: coap://sensor.example/status
   |      |      |
   |      |      |
   |<-----+      |     Header: 2.05 Content (T=ACK, Code=69, MID=0x1633)
   | 2.05 |      |      Token: 0x9a
   |      |      |    Max-Age: 113 sec
   |      |      |    Payload: "ready"
   |      |      |
   |      |      |
   |      |<-----+     Header: 2.05 Content (T=NON, Code=69, MID=0x5fc0)
   |      | 2.05 |      Token: 0x1a
   |      |      |    Observe: 1780
   |      |      |    Max-Age: 120 sec
   |      |      |    Payload: "busy"
   |      |      |
   |      |      |
   +----->|      |     Header: GET (T=CON, Code=1, MID=0x1634)
   | GET  |      |      Token: 0x9b
   |      |      |  Proxy-Uri: coap://sensor.example/status
   |      |      |
   |      |      |
   |<-----+      |     Header: 2.05 Content (T=ACK, Code=69, MID=0x1634)
   | 2.05 |      |      Token: 0x9b
   |      |      |    Max-Age: 89 sec
   |      |      |    Payload: "busy"
   |      |      |

    Figure 4: A proxy observes a resource to keep its cache up to date



Hartke & Shelby        Expires September 16, 2011              [Page 16]


Internet-Draft         Observing Resources in CoAP            March 2011


Client  Proxy  Server
   |      |      |
   |      |      |
   +----->|      |     Header: GET (T=CON, Code=1, MID=0x1633)
   | GET  |      |      Token: 0x6a
   |      |      |  Proxy-Uri: coap://sensor.example/status
   |      |      |    Observe: 0
   |      |      |
   |      |      |
   |<- - -+      |     Header: (T=ACK, Code=0, MID=0x1633)
   |      |      |
   |      |      |
   |      +----->|     Header: GET (T=CON, Code=1, MID=0xaf90)
   |      | GET  |      Token: 0xaa
   |      |      |        Uri: coap://sensor.example/status
   |      |      |    Observe: 0
   |      |      |
   |      |      |
   |      |<-----+     Header: 2.05 Content (T=ACK, Code=69, MID=0xaf90)
   |      | 2.05 |      Token: 0xaa
   |      |      |    Observe: 67
   |      |      |    Payload: "ready"
   |      |      |
   |      |      |
   |<-----+      |     Header: 2.05 Content (T=CON, Code=69, MID=0xaf94)
   | 2.05 |      |      Token: 0x6a
   |      |      |    Observe: 346
   |      |      |    Payload: "ready"
   |      |      |
   |      |      |
   +- - ->|      |     Header: (T=ACK, Code=0, MID=0xaf94)
   |      |      |
   |      |      |
   |      |<-----+     Header: 2.05 Content (T=CON, Code=69, MID=0x5a20)
   |      | 2.05 |      Token: 0xaa
   |      |      |    Observe: 1460
   |      |      |    Payload: "busy"
   |      |      |
   |      |      |
   |      +- - ->|     Header: (T=ACK, Code=0, MID=0x5a20)
   |      |      |
   |      |      |
   |<-----+      |     Header: 2.05 Content (T=CON, Code=69, MID=0xaf9b)
   | 2.05 |      |      Token: 0x6a
   |      |      |    Observe: 2011
   |      |      |    Payload: "busy"
   |      |      |
   |      |      |



Hartke & Shelby        Expires September 16, 2011              [Page 17]


Internet-Draft         Observing Resources in CoAP            March 2011


   +- - ->|      |     Header: (T=ACK, Code=0, MID=0xaf9b)
   |      |      |

          Figure 5: A client observes a resource through a proxy


Appendix B.  Changelog

   Changes from ietf-01 to ietf-02:

   o  Removed the requirement of periodic refreshing (#126).

   o  The new "Observe" Option replaces the "Lifetime" Option.

   o  New mechanism to detect message reordering.

   o  Changed 2.00 (OK) notifications to 2.05 (Content) notifications.

   Changes from ietf-00 to ietf-01:

   o  Changed terminology from "subscriptions" to "observation
      relationships" (#33).

   o  Changed the name of the option to "Lifetime".

   o  Clarified establishment of observation relationships.

   o  Clarified that an observation is only identified by the URI of the
      observed resource and the identity of the client (#66).

   o  Clarified rules for establishing observation relationships (#68).

   o  Clarified conditions under which an observation relationship is
      terminated.

   o  Added explanation on how clients can terminate an observation
      relationship before the lifetime ends (#34).

   o  Clarified that the overriding objective for notifications is
      eventual consistency of the actual and the observed state (#67).

   o  Specified how a server needs to deal with clients not
      acknowledging confirmable messages carrying notifications (#69).

   o  Added a mechanism to detect message reordering (#35).

   o  Added an explanation of how notifications can be cached,
      supporting both the freshness and the validation model (#39, #64).



Hartke & Shelby        Expires September 16, 2011              [Page 18]


Internet-Draft         Observing Resources in CoAP            March 2011


   o  Clarified that non-GET requests do not affect observation
      relationships, and that GET requests without "Lifetime" Option
      affecting relationships is by design (#65).

   o  Described interaction with block-wise transfers (#36).

   o  Added Resource Discovery section (#99).

   o  Added IANA Considerations.

   o  Added Security Considerations (#40).

   o  Added examples (#38).


Authors' Addresses

   Klaus Hartke
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63905
   Fax:   +49-421-218-7000
   Email: hartke@tzi.org


   Zach Shelby
   Sensinode
   Kidekuja 2
   Vuokatti  88600
   Finland

   Phone: +358407796297
   Email: zach@sensinode.com















Hartke & Shelby        Expires September 16, 2011              [Page 19]


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