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, . [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]