Observing Resources in CoAP
draft-ietf-core-observe-05
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7641.
|
|
---|---|---|---|
Author | Klaus Hartke | ||
Last updated | 2012-07-05 (Latest revision 2012-03-12) | ||
Replaces | draft-hartke-coap-observe | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 7641 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Barry Leiba | ||
Send notices to | core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org |
draft-ietf-core-observe-05
quot;, Addison-Wesley, Reading, MA, USA, November 1994. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-11 (work in progress), January 2012. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, <http:// www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>. [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. [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, April 2011. Hartke Expires September 13, 2012 [Page 17] Internet-Draft Observing Resources in CoAP March 2012 Appendix A. Examples Observed CLIENT SERVER Actual t State | | State ____________ | | ____________ 1 | | 2 unknown | | 18.5 C 3 +----->| Header: GET 0x43011633 4 | GET | Token: 0x4a 5 | | Uri-Path: temperature 6 | | Observe: 0 7 | | 8 | | 9 ____________ |<-----+ Header: 2.05 0x63451633 10 | 2.05 | Token: 0x4a 11 18.5 C | | Observe: 9 12 | | Max-Age: 15 13 | | Payload: "18.5 C" 14 | | 15 | | ____________ 16 ____________ |<-----+ Header: 2.05 0x53457b50 17 | 2.05 | 19.2 C Token: 0x4a 18 19.2 C | | Observe: 16 29 | | Max-Age: 15 20 | | Payload: "19.2 C" 21 | | Figure 3: A client registers and receives a notification of the current state and upon a state change Hartke Expires September 13, 2012 [Page 18] Internet-Draft Observing Resources in CoAP March 2012 Observed CLIENT SERVER Actual t State | | State ____________ | | ____________ 22 | | 23 19.2 C | | 19.2 C 24 | | ____________ 25 | X----+ Header: 2.05 0x53457b51 26 | 2.05 | 19.7 C Token: 0x4a 27 | | Observe: 25 28 | | Max-Age: 15 29 | | Payload: "19.7 C" 30 | | 31 ____________ | | 32 +----->| Header: GET 0x43011633 33 19.2 C | GET | Token: 0xb2 34 (stale) | | Uri-Path: temperature 35 | | Observe: 0 36 | | 37 | | 38 ____________ |<-----+ Header: 2.05 0x54457b52 39 | 2.05 | Token: 0xb2 40 19.7 C | | Observe: 38 41 | | Max-Age: 15 42 | | ETag: 0x78797a7a79 43 | | Payload: "19.7 C" 44 | | Figure 4: The client re-registers after Max-Age ends Hartke Expires September 13, 2012 [Page 19] Internet-Draft Observing Resources in CoAP March 2012 Observed CLIENT SERVER Actual t State | | State ____________ | | ____________ 45 | | 46 19.7 C | | 19.7 C 47 | | 48 | | ____________ 49 | CRASH 50 | 51 | 52 | | 53 ____________ | | ____________ 54 +----->| Header: GET 0x44011634 55 19.7 C | GET | 20.0 C Token: 0xf9 56 (stale) | | Uri-Path: temperature 57 | | Observe: 0 58 | | ETag: 0x78797a7a79 59 | | 60 | | 61 ____________ |<-----+ Header: 2.05 0x63451634 62 | 2.05 | Token: 0xf9 63 20.0 C | | Observe: 61 64 | | Max-Age: 15 65 | | Payload: "20.0 C" 66 | | 67 | | ____________ 68 ____________ |<-----+ Header: 2.03 0x5443aa0c 69 | 2.03 | 19.7 C Token: 0xf9 70 19.7 C | | Observe: 68 71 | | ETag: 0x78797a7a79 72 | | Max-Age: 15 73 | | Figure 5: The client re-registers and gives the server the opportunity to select a stored response Hartke Expires September 13, 2012 [Page 20] Internet-Draft Observing Resources in CoAP March 2012 A.1. Proxying CLIENT PROXY SERVER | | | | +----->| Header: GET 0x44015fb8 | | GET | Token: 0x1a | | | Uri-Host: sensor.example | | | Uri-Path: status | | | Observe: 0 | | | | |<-----+ Header: 2.05 0x63455fb8 | | 2.05 | Token: 0x1a | | | Observe: 42 | | | Max-Age: 60 | | | Payload: "ready" | | | +----->| | Header: GET 0x42011633 | GET | | Token: 0x9a | | | Proxy-Uri: coap://sensor.example/status | | | |<-----+ | Header: 2.05 0x62451633 | 2.05 | | Token: 0x9a | | | Max-Age: 53 | | | Payload: "ready" | | | | |<-----+ Header: 2.05 0x534505fc0 | | 2.05 | Token: 0x1a | | | Observe: 135 | | | Max-Age: 60 | | | Payload: "busy" | | | +----->| | Header: GET 0x42011634 | GET | | Token: 0x9b | | | Proxy-Uri: coap://sensor.example/status | | | |<-----+ | Header: 2.05 0x62451634 | 2.05 | | Token: 0x9b | | | Max-Age: 49 | | | Payload: "busy" | | | Figure 6: A proxy observes a resource to keep its cache up to date Hartke Expires September 13, 2012 [Page 21] Internet-Draft Observing Resources in CoAP March 2012 CLIENT PROXY SERVER | | | +----->| | Header: GET 0x43011635 | GET | | Token: 0x6a | | | Proxy-Uri: coap://sensor.example/status | | | Observe: 0 | | | |<- - -+ | Header: 0x60001635 | | | | +----->| Header: GET 0x4401af90 | | GET | Token: 0xaa | | | Uri-Host: sensor.example | | | Uri-Path: status | | | Observe: 0 | | | | |<-----+ Header: 2.05 0x6345af90 | | 2.05 | Token: 0xaa | | | Observe: 67 | | | Max-Age: 60 | | | Payload: "ready" | | | |<-----+ | Header: 2.05 0x4345af94 | 2.05 | | Token: 0x6a | | | Observe: 17346 | | | Max-Age: 60 | | | Payload: "ready" | | | +- - ->| | Header: 0x6000af94 | | | | |<-----+ Header: 2.05 0x53455a20 | | 2.05 | Token: 0xaa | | | Observe: 157 | | | Max-Age: 60 | | | Payload: "busy" | | | |<-----+ | Header: 2.05 0x5345af9b | 2.05 | | Token: 0x6a | | | Observe: 17436 | | | Max-Age: 60 | | | Payload: "busy" | | | Figure 7: A client observes a resource through a proxy Hartke Expires September 13, 2012 [Page 22] Internet-Draft Observing Resources in CoAP March 2012 A.2. Block-wise Transfer CLIENT SERVER | | +----->| Header: GET 0x43011636 | GET | Token: 0xfb | | Uri-Path: status-icon | | Observe: 0 | | |<-----+ Header: 2.05 0x64451636 | 2.05 | Token: 0xfb | | Block2: 0/1/128 | | Observe: 62354 | | Max-Age: 60 | | Payload: [128 bytes] | | |<-----+ Header: 2.05 0x5445af9c | 2.05 | Token: 0xfb | | Block2: 1/0/128 | | Observe: 62354 | | Max-Age: 60 | | Payload: [27 bytes] | | |<-----+ Header: 2.05 0x5445af9d | 2.05 | Token: 0xfb | | Block2: 0/1/128 | | Observe: 62444 | | Max-Age: 60 | | Payload: [128 bytes] | | |<-----+ Header: 2.05 0x5445af9e | 2.05 | Token: 0xfb | | Block2: 1/0/128 | | Observe: 62444 | | Max-Age: 60 | | Payload: [27 bytes] | | Figure 8: A server sends two notifications of two blocks each Appendix B. Modeling Resources to Tailor Notifications A server may want to provide notifications that respond to very specific conditions on some state. This is best done by modeling the resources that the server exposes according to these needs. For example, for a CoAP server with an attached temperature sensor, Hartke Expires September 13, 2012 [Page 23] Internet-Draft Observing Resources in CoAP March 2012 o the server could, in the simplest form, expose a resource <coap://server/temperature> that changes its state every second to the current temperature measured by the sensor; o the server could, however, also expose a resource <coap://server/temperature/felt> that changes its state to "cold" when the temperature drops below a preconfigured threshold, and to "warm" when the temperature exceeds a second, higher threshold; o the server could expose a parameterized resource <coap://server/temperature/critical?above=45> that changes its state to the current temperature if the temperature exceeds the specified value, and changes its state to "OK" when the temperature drops below; or o the server could expose a parameterized resource <coap://server/ temperature?query=select+avg(temperature)+from+ Sensor.window:time(30sec)> that accepts expressions of arbitrary complexity and changes its state accordingly. In any case, the client is notified about the current state of the resource whenever the state of the appropriately modeled resource changes. By designing resources that change their state on certain conditions, it is possible to notify the client only when these conditions occur instead of continuously supplying it with information it doesn't need. With parametrized resources, this is not limited to conditions defined by the server, but can be extended to arbitrarily complex conditions defined by the client. Thus, the server designer can choose exactly the right level of complexity for the application envisioned and devices used, and is not constrained to a "one size fits all" mechanism built into the protocol. Appendix C. Changelog Changes from ietf-04 to ietf-05: o Recommended that a client does not re-register while a new notification from the server is still likely to arrive. This is to avoid that the request of the client and the last notification after max-age cross over each other (#174). o Relaxed requirements when sending RST in reply to non-confirmable notifications. o Added an implementation note about careless GETs (#184). Hartke Expires September 13, 2012 [Page 24] Internet-Draft Observing Resources in CoAP March 2012 o Updated examples. Changes from ietf-03 to ietf-04: o Removed the "Max-OFE" Option. o Allowed RST in reply to non-confirmable notifications. o Added a section on cancellation. o Updated examples. Changes from ietf-02 to ietf-03: o Separated client-side and server-side requirements. o Fixed uncertainty if client is still on the list of observers by introducing a liveliness model based on Max-Age and a new option called "Max-OFE" (#174). o Simplified the text on message reordering (#129). o Clarified requirements for intermediaries. o Clarified the combination of block-wise transfers with notifications (#172). o Updated examples to show how the state observed by the client becomes eventually consistent with the actual state on the server. o Added examples for parameterization of observable resource. 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 Introduced a 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). Hartke Expires September 13, 2012 [Page 25] Internet-Draft Observing Resources in CoAP March 2012 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). 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). Hartke Expires September 13, 2012 [Page 26] Internet-Draft Observing Resources in CoAP March 2012 Author's Address 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 Hartke Expires September 13, 2012 [Page 27]