idnits 2.17.1 draft-ietf-core-observe-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2011) is 4827 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 571, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-core-block-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-02 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Hartke 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track Z. Shelby 5 Expires: August 11, 2011 Sensinode 6 February 7, 2011 8 Observing Resources in CoAP 9 draft-ietf-core-observe-01 11 Abstract 13 CoAP is a RESTful application protocol for constrained nodes and 14 networks. The state of a resource on a CoAP server can change over 15 time. This specification provides a simple extension for CoAP that 16 gives clients the ability to observe such changes. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 11, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Observation Relationships . . . . . . . . . . . . . . . . . . 5 55 3.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Strategies . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. Retransmission . . . . . . . . . . . . . . . . . . . . . . 9 61 4.3. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Lifetime Option . . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Interactions with other CoAP features . . . . . . . . . . . . 11 65 6.1. Request Methods . . . . . . . . . . . . . . . . . . . . . 11 66 6.2. Block-wise Transfers . . . . . . . . . . . . . . . . . . . 11 67 6.3. Resource Discovery . . . . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 75 A.1. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained 82 Nodes/Networks. It is intended to provide RESTful services [REST] 83 not unlike HTTP [RFC2616], while reducing the complexity of 84 implementation as well as the size of packets exchanged in order to 85 make these services useful in a highly constrained network of 86 themselves highly constrained nodes. 88 The state of a resource on a CoAP server can change over time. We 89 want to give CoAP clients the ability to observe this change. 90 However, existing approaches from the HTTP world, such as repeated 91 polling or long-polls, generate significant complexity and/or 92 overhead and thus are less applicable in the constrained CoAP world. 93 Instead, a much simpler mechanism is provided to solve the basic 94 problem of resource observation. Note that there is no intention for 95 this mechanism to solve the full set of problems that the existing 96 HTTP solutions solve, or to replace publish/subscribe networks that 97 solve a much more general problem [RFC5989]. 99 This short specification describes an architecture and a protocol 100 design that realizes the well-known subject/observer design pattern 101 within the REST-based environment of CoAP. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Overview 109 In the subject/observer design pattern, an object, called the 110 subject, maintains a list of interested parties, called observers, 111 and notifies them automatically when a predefined condition, event or 112 state change occurs. The pattern supports a clean separation between 113 components, such as data storage and user interface. 115 The subject typically provides a method for observers to register 116 themselves with the subject (see Figure 1). The order in which 117 observers receive notifications is not defined; the subject is free 118 to use any method to determine the order. 120 Observer Subject 121 | | 122 | Register | 123 +----------------->| 124 | | 125 | Notification | 126 |<-----------------+ 127 | | 128 | Notification | 129 |<-----------------+ 130 | | 131 | Notification | 132 |<-----------------+ 133 | | 135 Figure 1: Subject/Observer Design Pattern 137 The design pattern is realized in CoAP as follows: 139 Subject: In the context of CoAP, the subject is a resource located 140 at some CoAP server. The state of the resource may change over 141 time, ranging from infrequent changes to continuous state updates. 143 Observer: The observer is a CoAP client that is interested in the 144 current state of the resource at any given time. 146 Observation Relationship: A client registers itself with a resource 147 by sending a modified GET request to the server hosting the 148 resource. The request causes the server to establish an 149 observation relationship between the client and the resource. The 150 response to the GET request supplies the client with a 151 representation of the current resource state. 153 Notification: Whenever the state of a resource changes, the server 154 notifies each client that has an observation relationship to the 155 resource. The notification is an additional response to the GET 156 request; it supplies the client with a representation of the new 157 resource state. The response echoes the token specified by the 158 client in the request, so the client can easily correlate 159 notifications. 161 Lifetime: For robustness, an observation relationship is 162 automatically ended after a negotiated duration of time. A client 163 needs to refresh the relationship before the lifetime ends if it 164 wants to be kept in the list of observers. The server includes 165 the remaining lifetime duration in each notification. 167 Figure 2 shows an example of a CoAP client establishing an 168 observation relationship with a resource on a CoAP server and then 169 being notified, once upon registration and then whenever the state of 170 the resource changes. 172 Client Server 173 | | 174 | GET /temperature | 175 | Lifetime: 60 sec | (establish observation relationship) 176 | Token: 0x4a | 177 +----------------->| 178 | | 179 | 2.00 OK "22.9 C" | 180 | Lifetime: 60 sec | (initial notification of current state) 181 | Token: 0x4a | 182 |<-----------------+ 183 | | 184 | 2.00 OK "22.8 C" | 185 | Lifetime: 44 sec | (notification upon state change) 186 | Token: 0x4a | 187 |<-----------------+ 188 | | 189 | 2.00 OK "23.1 C" | 190 | Lifetime: 12 sec | (notification upon state change) 191 | Token: 0x4a | 192 |<-----------------+ 193 | | 195 Figure 2: Observing a Resource in CoAP 197 3. Observation Relationships 199 3.1. Establishment 201 A client registers itself with a resource by sending a GET request 202 that includes a Lifetime Option. (See Section 5 for the option 203 definition.) When a server receives such a request, it satisfies the 204 request as with a basic GET request and, upon success, establishes an 205 observation relationship between the client and the target resource. 207 The Lifetime Option indicates the duration for which the server is 208 requested to maintain the observation relationship before it is 209 ended. The server MUST NOT establish the relationship with a 210 duration longer than requested, although it MAY choose to cut short 211 the remaining lifetime upon registration (or any time while the 212 relationship is established). The server MUST include the remaining 213 lifetime in each response sent in reply to the GET request, including 214 the initial response. 216 A server that is unable or unwilling to establish an observation 217 relationship between a client to a resource MUST silently ignore the 218 Lifetime Option and process the GET request as usual. The resulting 219 response will not include a Lifetime Option, implying that no 220 observation relationship was established. 222 The token specified by the client in the GET request will be echoed 223 by the server in the initial response and in all notifications sent 224 to the client during the lifetime of the observation relationship. 225 See Section 4 for the details on notifications. 227 3.2. Maintenance 229 For robustness, an observation relationship has to be maintained 230 through periodic refreshing. If the relationship is not refreshed, 231 it ends after the duration that is negotiated using the Lifetime 232 Option. A client refreshes an observation relationship by repeating 233 the original GET request shortly before the observation lifetime 234 ends. 236 When a server receives such a repeated request (i.e. a GET request 237 from a client for which an observation relationship already exists), 238 it MUST NOT establish a second relationship but replace or update the 239 existing one with the new duration. 241 The exact rules for determining if two requests request to establish 242 the same observation relationship are as follows: 244 o The request URI of the two requests MUST match. 246 o The sources of the two requests MUST match. How this is 247 determined depends on the security mode used (see Section 10 of 248 [I-D.ietf-core-coap]): With NoSec, the IP address and port number 249 of the request sources must match. With other security modes, in 250 addition to the IP address and UDP port number matching, the 251 requests must have the same security context. 253 o The Message IDs and any Token Options in the two requests MUST NOT 254 be taken into account. 256 A client MAY refresh an observation relationship at any time before 257 the lifetime ends, for example, when it didn't receive a notification 258 for some time. However, it is RECOMMENDED that the client does not 259 refresh the relationship for the time specified in the Max-Age Option 260 of the most recent notification received, including the initial 261 response. 263 3.3. Termination 265 The observation relationship between a client and a resource MUST be 266 ended when one of the following conditions occurs: 268 o The age of the observation relationship becomes greater than the 269 negotiated lifetime. 271 o The server sends a notification response with a non-success 272 response code (4.xx or 5.xx). 274 o The client rejects a confirmable notification with a RST message. 276 o The last attempt of transmitting a confirmable notification to the 277 client times out. 279 A client MAY terminate an observation relationship before its 280 lifetime ends. It can do so by performing one of the following 281 actions: 283 o The client rejects a confirmable notification with a RST message. 285 o The client refreshes the observation relationship with a value of 286 0 seconds, which will cause the server to end any observation 287 relationship immediately after returning the initial response. 289 4. Notifications 291 When an observation relationship is established between a client and 292 a resource, the client is notified of resource state changes by 293 additional responses sent in reply to the GET request to the client. 294 Each such notification response MUST echo the token specified in the 295 request and specify the remaining duration for which the server 296 maintains the observation relationship. The order in which observers 297 are notified about a state change is not defined; the server is free 298 to use any method to determine the order. 300 A notification SHOULD have a 2.00 (OK) or 2.03 (Valid) response code. 301 However, in the event the state of a resource is changed in a way 302 that would cause a basic GET request to return an error code (for 303 example, when the resource is deleted), the server SHOULD notify the 304 client with a notification with an appropriate error code and MUST 305 end the observation relationship. 307 The representation format (i.e. the media type) used in any 308 notification response during the lifetime of an observation relation 309 MUST be the same format used in the initial response to the GET 310 request. If the server is unable to continue sending notifications 311 in the same representation format, it SHOULD send a 5.00 (Internal 312 Server Error) notification response and MUST end the observation 313 relationship. 315 A notification may be confirmable or non-confirmable, and the server 316 can employ different strategies in how it notifies a client; see 317 Section 4.1 below. The objective is that the state observed by the 318 client eventually becomes consistent with the actual state of the 319 resource. 321 If a client does not recognize the token in a confirmable 322 notification, it SHOULD reject the message with a RST message (in 323 which case the server MUST end the observation). Otherwise, the 324 client MUST acknowledge the message with an ACK message as normal. 325 See Section 4.2 for details on the retransmission of confirmable 326 messages. 328 Note that notifications may arrive in a different order than sent by 329 the server due to network latency. A client must be prepared to 330 receive notifications before the initial response to a GET request, 331 after an error notification or after the client has requested the 332 server to end the observation relationship. See Section 4.3 for 333 further details on message reordering. 335 Notifications MAY be cached by CoAP end-points. This is detailed in 336 Section 4.4. 338 4.1. Strategies 340 The objective when notifying clients of state changes is that the 341 state observed by the client eventually becomes consistent with the 342 actual state of the resource. This allows the server some liberties 343 in how it sends notifications, as long as it works towards the 344 objective. 346 A notification may be sent confirmable or non-confirmable. The 347 message type used is typically application-dependent and MAY be 348 determined by the server for each notification individually. For 349 example, for resources that change in a somewhat predictable or 350 regular fashion, notifications can be sent in non-confirmable 351 messages. For resources that change infrequently, notifications can 352 be sent in confirmable messages. The server can combine these two 353 approaches depending on the frequency of state changes and the 354 importance of individual notifications. 356 A server MAY choose to omit notifying a client of a state change if 357 it knows that it will send another notification soon (e.g., when the 358 state is changing frequently or maybe even continuously). Similarly, 359 it MAY choose to notify a client about the same state change more 360 than once. For example, when state changes occur in bursts, the 361 server can omit some notifications, send the others in non- 362 confirmable messages, and make sure that the client observes the 363 latest state change by repeating the last notification in a 364 confirmable message. 366 4.2. Retransmission 368 According to the core CoAP protocol, confirmable messages are 369 retransmitted in exponentially increasing intervals for a certain 370 number of attempts until they are acknowledged by the client. In the 371 context of observing a resource, it is undesirable to continue 372 transmitting the representation of a resource state when the state 373 changed in the meantime. There are many reasons why a client might 374 not acknowledge a confirmable message, ranging from short 375 interruptions in the network to a permanent failure of the client. 377 When a server is retransmitting a confirmable message with a 378 notification, waiting for an acknowledgement, and wants to notify the 379 client of a state change using a new confirmable message, it MUST 380 stop retransmitting the old notification and MUST attempt to transmit 381 the new notification with the number of attempts remaining from the 382 old notification. When the last attempt to retransmit a confirmable 383 message with a notification for a resource times out, the observation 384 relationship is ended. 386 4.3. Reordering 388 Messages with notifications can arrive in a different order than they 389 were sent. Since the objective is eventual consistency, a client can 390 safely discard a notification that arrives later than a newer 391 notification. For this purpose, the remaining lifetime indicated by 392 notifications as a result of an observation request MUST be strictly 393 decreasing and the client SHOULD specify a token in a refresh request 394 that is different from the token in the previous request. 396 A client MAY discard a notification under the following conditions: 398 o The client receives a notification with a token other than that 399 specified in the most recent request. 401 o The client receives a notification with the right token but also 402 with an indicated remaining lifetime duration longer than the 403 duration specified in the previous notification. 405 4.4. Caching 407 As notifications are just additional responses to a GET request, the 408 same rules on caching apply as to basic responses: CoAP end-points 409 MAY cache the responses and thereby reduce the response time and 410 network bandwidth consumption. Both the freshness model and the 411 validation model are supported. 413 When a response is fresh in the cache, GET requests can be satisfied 414 without contacting the origin server. The observation mechanism 415 ensures that the cache has a fresh response for most of the duration 416 of the observation lifetime. This is particularly useful when the 417 cache is located at an CoAP intermediary such as a proxy or reverse 418 proxy. (Note that the freshness of the stored response is determined 419 by its Max-Age Option, not the existence of an observation 420 relationship. So a request can cause the end-point to refresh cache 421 and observation relationship even while having an relationship.) 423 When an end-point has one or more responses stored, it can use the 424 Etag Option to give the origin server an opportunity to select a 425 stored response to be used. The end-point SHOULD add an Etag Option 426 specifying the entity-tag of each stored response that is applicable. 427 It MUST keep those responses in the cache until the observation 428 lifetime ends, the relationship is terminated or a refresh request 429 with a new set of entity-tags is. When the observed resource changes 430 its state and the origin server is about to send a 2.00 (OK) 431 notification, then, whenever that notification has an entity-tag in 432 the set of entity-tags specified by the client, it sends a 2.03 433 (Valid) response with an appropriate Etag Option instead. The server 434 MUST NOT assume that the recipient has any response stored other than 435 those identified by the entity-tags in the most recent observation 436 request. 438 5. Lifetime Option 440 +-----+----------+----------+--------+--------+---------+ 441 | No. | C/E | Name | Format | Length | Default | 442 +-----+----------+----------+--------+--------+---------+ 443 | 10 | Elective | Lifetime | uint | 1-4 B | 0 | 444 +-----+----------+----------+--------+--------+---------+ 446 Table 1: Options 448 The Lifetime Option, when present, modifies the GET method so it does 449 not only retrieve a representation of the current state of the 450 resource identified by the request URI once, but also lets the server 451 notify the client of changes to the resource state for the duration 452 specified in the option. 454 In a response, the Lifetime Option indicates a lower bound (e.g., by 455 rounding down) for the remaining observation lifetime. (Note that 456 the server can always choose to cut short the observation lifetime 457 before it echoes this lifetime back in a response.) 459 The option's value is encoded as a variable-length unsigned integer 460 (see Appendix A of [I-D.ietf-core-coap]) that indicates a duration of 461 time measured in seconds. 463 Note that a Lifetime value of 0 is indicated by leaving out the 464 Lifetime option, which then defaults to 0. 466 Since the Lifetime Option is elective, a GET request that includes 467 the Lifetime Option will automatically fall back to a basic GET 468 request if the server does not support observations. 470 6. Interactions with other CoAP features 472 6.1. Request Methods 474 If a client has an observation relationship with a resource and 475 performs a POST, PUT or DELETE request on that resource, the request 476 MUST NOT affect the observation relationship. However, since such a 477 request can affect the observed resource, it can cause the server to 478 send a notification with a resource state representation or end the 479 observation relationship with an error notification (e.g., when a 480 DELETE request is successful and the observed resource no longer 481 exists). 483 Note that a client cannot perform a GET request on a resource to get 484 a representation of the current resource state without affecting the 485 lifetime of an existing observation relation to that resource: the 486 client is already notified by the server with a fresh representation 487 whenever the state changes. If the client wants to make sure that is 488 has a fresh representation and wants to continue being notified, it 489 should refresh the observation relationship as described in 490 Section 3.2. If the client wants to make sure it has a fresh 491 representation and does not want to continue being notified, it 492 should perform a GET request with a lifetime duration of 0 seconds as 493 described in Section 3.3. 495 6.2. Block-wise Transfers 497 Resources that are the subject of an observation relationship may be 498 larger than can be comfortably processed or transferred in one CoAP 499 message. CoAP provides a block-wise transfer mechanism to address 500 this problem [I-D.ietf-core-block]. The following rules apply to the 501 combination of block-wise transfers with notifications: 503 o As with basic GET transfers, the client can indicate its desired 504 block size in a Block option in the GET request. If it implements 505 Block, the server SHOULD take note of the block size not just for 506 the initial response but also for further notifications in this 507 observation relationship. 509 o Notification responses can make use of the Block option. With 510 increasing block numbers, the Lifetime option value MUST stay the 511 same or decrease. The client SHOULD use the Lifetime information 512 from the last block. All blocks in a notification response SHOULD 513 also carry an Etag option to ensure they are reassembled 514 correctly. 516 6.3. Resource Discovery 518 Clients can discover interesting resources to observe using CoRE 519 Resource Discovery [I-D.ietf-core-link-format]. Links with the "obs" 520 attribute indicate resources that MUST support the mechanism in this 521 document and are RECOMMENDED to change their state at least once in a 522 while. 524 The "obs" attribute is used as a flag, and thus it has no value 525 component. The attribute MUST NOT appear more than once in a link. 527 7. Security Considerations 529 The security considerations of the base protocol [I-D.ietf-core-coap] 530 apply. 532 Note that the considerations about amplification attacks are somewhat 533 amplified in an observation relationship. In NoSec mode, a server 534 MUST therefore strictly limit the number of messages generated from 535 an observation relationship that it sends between receiving packets 536 that confirm the actual interest of the recipient in the data; i.e., 537 any notifications sent in Non-Confirmable messages MUST be 538 interspersed with Confirmable messages. (An Attacker may still spoof 539 the acknowledgements if the Confirmable messages are sufficiently 540 predictable.) 542 As with any protocol that creates state, attackers may attempt to 543 exhaust the resources that the server has available for maintaining 544 observation relationships. Servers MAY want to access-control this 545 creation of state. As degraded behavior, the server can always fall 546 back to a basic GET (no Lifetime option) if it is unwilling or unable 547 to establish the observation relationship, including if resources for 548 state are exhausted or nearing exhaustion. 550 Intermediaries MUST be careful to ensure that notifications cannot be 551 employed to create a loop. A simple way to break any loops is to 552 employ caches for forwarding notifications in intermediaries. 554 8. IANA Considerations 556 The following entry is added to the CoAP Option Numbers registry: 558 +--------+----------+-----------+ 559 | Number | Name | Reference | 560 +--------+----------+-----------+ 561 | 10 | Lifetime | [RFCXXXX] | 562 +--------+----------+-----------+ 564 Table 2: New CoAP Option Numbers 566 The following entry is added to the CoRE Target Attribute registry: 568 +------+-----------+ 569 | Name | Reference | 570 +------+-----------+ 571 | obs | [RFCXXXX] | 572 +------+-----------+ 574 Table 3: New CoRE Target Attributes 576 9. Acknowledgements 578 Carsten Bormann was an original author of this draft and is 579 acknowledged for significant contribution to this document. 581 Klaus Hartke was funded by the Klaus Tschira Foundation. 583 10. References 585 10.1. Normative References 587 [I-D.ietf-core-block] 588 Shelby, Z. and C. Bormann, "Blockwise transfers in CoAP", 589 draft-ietf-core-block-01 (work in progress), January 2011. 591 [I-D.ietf-core-coap] 592 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 593 "Constrained Application Protocol (CoAP)", 594 draft-ietf-core-coap-04 (work in progress), January 2011. 596 [I-D.ietf-core-link-format] 597 Shelby, Z., "CoRE Link Format", 598 draft-ietf-core-link-format-02 (work in progress), 599 December 2010. 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 10.2. Informative References 606 [REST] Fielding, R., "Architectural Styles and the Design of 607 Network-based Software Architectures", 2000, . 610 (Seminal dissertation introducing the REST architectural 611 style.) 613 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 614 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 615 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 617 [RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes 618 to an HTTP Resource", RFC 5989, October 2010. 620 Appendix A. Examples 622 Client Server 623 | | 624 | | 625 +----->| Header: GET (T=CON, Code=1, MID=0x1633) 626 | GET | Token: 0x4a 627 | | Uri: coap://sensor.example/temperature 628 | | Lifetime: 60sec 629 | | 630 | | 631 |<-----+ Header: 2.00 OK (T=ACK, Code=64, MID=0x1633) 632 | 2.00 | Token: 0x4a 633 | | Lifetime: 60sec 634 | | Payload: "22.9 C" 635 | | 636 | | 637 |<-----+ Header: 2.00 OK (T=NON, Code=64, MID=0x7b50) 638 | 2.00 | Token: 0x4a 639 | | Lifetime: 59sec 640 | | Payload: "22.8 C" 641 | | 642 | | 643 |<-----+ Header: 2.00 OK (T=NON, Code=64, MID=0x7b51) 644 | 2.00 | Token: 0x4a 645 | | Lifetime: 58sec 646 | | Payload: "22.5 C" 647 | | 649 Figure 3: Simple observation with non-confirmable notifications 651 A.1. Proxying 653 Client Proxy Server 654 | | | 655 | | | 656 | +----->| Header: GET (T=CON, Code=1, MID=0x5fb8) 657 | | GET | Token: 0x1a 658 | | | Uri: coap://sensor.example/status 659 | | | Lifetime: 3600 sec 660 | | | 661 | | | 662 | |<-----+ Header: 2.00 OK (T=ACK, Code=64, MID=0x5fb8) 663 | | 2.00 | Token: 0x1a 664 | | | Lifetime: 3600 sec 665 | | | Max-Age 120 sec 666 | | | Payload: "ready" 667 | | | 668 | | | 669 +----->| | Header: GET (T=CON, Code=1, MID=0x1633) 670 | GET | | Token: 0x9a 671 | | | Proxy-Uri: coap://sensor.example/status 672 | | | 673 | | | 674 |<-----+ | Header: 2.00 OK (T=ACK, Code=1, MID=0x1633) 675 | 2.00 | | Token: 0x9a 676 | | | Max-Age: 113 sec 677 | | | Payload: "ready" 678 | | | 679 | | | 680 | |<-----+ Header: 2.00 OK (T=NON, Code=64, MID=0x5fc0) 681 | | 2.00 | Token: 0x1a 682 | | | Lifetime: 1780 sec 683 | | | Max-Age: 120 sec 684 | | | Payload: "busy" 685 | | | 686 | | | 687 +----->| | Header: GET (T=CON, Code=1, MID=0x1634) 688 | GET | | Token: 0x9b 689 | | | Proxy-Uri: coap://sensor.example/status 690 | | | 691 | | | 692 |<-----+ | Header: 2.00 OK (T=ACK, Code=1, MID=0x1634) 693 | 2.00 | | Token: 0x9b 694 | | | Max-Age: 89 sec 695 | | | Payload: "busy" 696 | | | 698 Figure 4: A proxy observes a resource to keep its cache up to date 700 Client Proxy Server 701 | | | 702 | | | 703 +----->| | Header: (T=CON, Code=1, MID=0x1633) 704 | GET | | Token: 0x6a 705 | | | Proxy-Uri: coap://sensor.example/status 706 | | | Lifetime: 360 sec 707 | | | 708 | | | 709 |< - - + | Header: (T=ACK, Code=0, MID=0x1633) 710 | | | 711 | | | 712 | +----->| Header: GET (T=CON, Code=1, MID=0xaf90) 713 | | GET | Token: 0xaa 714 | | | Uri: coap://sensor.example/status 715 | | | Lifetime: 1800 sec 716 | | | 717 | | | 718 | |<-----+ Header: 2.00 (T=ACK, Code=64, MID=0xaf90) 719 | | 2.00 | Token: 0xaa 720 | | | Lifetime: 1800 sec 721 | | | Payload: "ready" 722 | | | 723 | | | 724 |<-----+ | Header: 2.00 (T=CON, Code=64, MID=0xaf94) 725 | 2.00 | | Token: 0x6a 726 | | | Lifetime: 346 sec 727 | | | Payload: "ready" 728 | | | 729 | | | 730 + - - >| | Header: (T=ACK, Code=0, MID=0x...) 731 | | | 732 | | | 733 | |<-----+ Header: 2.00 (T=CON, Code=64, MID=0x5a20) 734 | | 2.00 | Token: 0xaa 735 | | | Lifetime: 1460 sec 736 | | | Payload: "busy" 737 | | | 738 | | | 739 | + - - >| Header: (T=ACK, Code=0, MID=0x5a20) 740 | | | 741 | | | 742 |<-----+ | Header: 2.00 (T=CON, Code=64, MID=0xaf9b) 743 | 2.00 | | Token: 0x6a 744 | | | Lifetime: 6 sec 745 | | | Payload: "busy" 746 | | | 747 | | | 748 + - - >| | Header: (T=ACK, Code=0, MID=0xaf9b) 749 | | | 751 Figure 5: A client observes a resource through a proxy 753 Appendix B. Changelog 755 Changes from ietf-00 to ietf-01: 757 o Name of the option is now simply "Lifetime". 759 o Terminology changed from "subscriptions" to "observation 760 relationships" (#33). 762 o Clarified establishment of observation relationships. 764 o Clarified that an observation is only identified by the URI of the 765 observed resource and the identity of the client (#66). 767 o Clarified rules for establishing observation relationships (#68). 769 o Clarified conditions under which an observation relationship is 770 terminated. 772 o Added explanation on how clients can terminate an observation 773 relationship before the lifetime ends (#34). 775 o Clarified that the overriding objective for notifications is 776 eventual consistency of the actual and the observed state (#67). 778 o Specified how a server needs to deal with clients not 779 acknowledging confirmable messages carrying notifications (#69). 781 o Added a mechanism to detect message reordering (#35). 783 o Added an explanation of how notifications can be cached, 784 supporting both the freshness and the validation model (#39, #64). 786 o Clarified that non-GET requests do not affect observation 787 relationships, and that GET requests without Lifetime Option 788 affecting relationships is by design (#65). 790 o Described interaction with block-wise transfers (#36). 792 o Added Resource Discovery section (#99). 794 o Added IANA Considerations. 796 o Added Security Considerations (#40). 798 o Added examples (#38). 800 Authors' Addresses 802 Klaus Hartke 803 Universitaet Bremen TZI 804 Postfach 330440 805 Bremen D-28359 806 Germany 808 Phone: +49-421-218-63905 809 Fax: +49-421-218-7000 810 Email: hartke@tzi.org 812 Zach Shelby 813 Sensinode 814 Kidekuja 2 815 Vuokatti 88600 816 Finland 818 Phone: +358407796297 819 Email: zach@sensinode.com