idnits 2.17.1 draft-ietf-core-observe-11.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 (October 15, 2013) is 3845 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 820, but not defined ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 October 15, 2013 5 Expires: April 18, 2014 7 Observing Resources in CoAP 8 draft-ietf-core-observe-11 10 Abstract 12 CoAP is a RESTful application protocol for constrained nodes and 13 networks. The state of a resource on a CoAP server can change over 14 time. This document specifies a simple protocol extension for CoAP 15 that enables CoAP clients to "observe" resources, i.e., to retrieve 16 a representation of a resource and keep this representation updated 17 by the server over a period of time. The protocol follows a best- 18 effort approach for sending new representations to clients and 19 provides eventual consistency between the state observed by each 20 client and the actual resource state at the server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 18, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Observable Resources . . . . . . . . . . . . . . . . . . . 5 60 1.4. Consistency . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.5. Requirements Notation . . . . . . . . . . . . . . . . . . 7 62 2. The Observe Option . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Client-side Requirements . . . . . . . . . . . . . . . . . . . 8 64 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.5. Transmission . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.6. Cancellation . . . . . . . . . . . . . . . . . . . . . . . 11 70 4. Server-side Requirements . . . . . . . . . . . . . . . . . . . 11 71 4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.5. Transmission . . . . . . . . . . . . . . . . . . . . . . . 14 76 5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 16 77 6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 85 A.1. Client/Server Examples . . . . . . . . . . . . . . . . . . 20 86 A.2. Proxy Examples . . . . . . . . . . . . . . . . . . . . . . 24 87 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 89 1. Introduction 91 1.1. Background 93 CoAP [I-D.ietf-core-coap] is an application protocol for constrained 94 nodes and networks. It is intended to provide RESTful services 95 [REST] not unlike HTTP [RFC2616] while reducing the complexity of 96 implementation as well as the size of packets exchanged in order to 97 make these services useful in a highly constrained network of 98 themselves highly constrained nodes. 100 The model of REST is that of a client exchanging representations of 101 resources with a server, where a representation captures the current 102 or intended state of a resource and the server is the definitive 103 source for representations of the resources in its namespace. A 104 client interested in the state of a resource initiates a request to 105 the server; the server then returns a response with a representation 106 of the resource that is current at the time of the request. 108 This model does not work well when a client is interested in having a 109 current representation of a resource over a period of time. Existing 110 approaches from HTTP, such as repeated polling or HTTP long polling 111 [RFC6202], generate significant complexity and/or overhead and thus 112 are less applicable in a constrained environment. 114 The protocol specified in this document extends the CoAP core 115 protocol with a mechanism for a CoAP client to "observe" a resource 116 on a CoAP server: the client can retrieve a representation of the 117 resource and request this representation be updated by the server 118 over a period of time. 120 The protocol keeps the architectural properties of REST. It enables 121 high scalability and efficiency through the support of caches and 122 proxies. There is no intention for it, though, to solve the full set 123 of problems that the existing HTTP solutions solve, or to replace 124 publish/subscribe networks that solve a much more general problem 125 [RFC5989]. 127 1.2. Protocol Overview 129 The protocol is based on the well-known observer design pattern 130 [GOF]. In this design pattern, components called "observers" 131 register at a specific, known provider called the "subject" that they 132 are interested in being notified whenever the subject undergoes a 133 change in state. The subject is responsible for administering its 134 list of registered observers. If multiple subjects are of interest 135 to an observer, the observer must register separately for all of 136 them. 138 Observer Subject 139 | | 140 | Registration | 141 +------------------->| 142 | | 143 | Notification | 144 |<-------------------+ 145 | | 146 | Notification | 147 |<-------------------+ 148 | | 149 | Notification | 150 |<-------------------+ 151 | | 153 Figure 1: The Observer Design Pattern 155 The observer design pattern is realized in CoAP as follows: 157 Subject: In the context of CoAP, the subject is a resource in the 158 namespace of a CoAP server. The state of the resource can change 159 over time, ranging from infrequent updates to continuous state 160 transformations. 162 Observer: An observer is a CoAP client that is interested in having 163 a current representation of the resource at any given time. 165 Registration: A client registers its interest in a resource by 166 initiating an extended GET request to the server. In addition to 167 returning a representation of the target resource, this request 168 causes the server to add the client to the list of observers of 169 the resource. 171 Notification: Whenever the state of a resource changes, the server 172 notifies each client in the list of observers of the resource. 173 Each notification is an additional CoAP response sent by the 174 server in reply to the GET request and includes a complete, 175 updated representation of the new resource state. 177 Figure 2 below shows an example of a CoAP client registering its 178 interest in a resource and receiving three notifications: the first 179 upon registration with the current state, and then two upon changes 180 to the resource state. Both the registration request and the 181 notifications are identified as such by the presence of the Observe 182 Option defined in this document. In notifications, the Observe 183 Option additionally provides a sequence number for reordering 184 detection. All notifications carry the token specified by the 185 client, so the client can easily correlate them to the request. 187 Client Server 188 | | 189 | GET /temperature | 190 | Token: 0x4a | Registration 191 | Observe: (empty) | 192 +------------------->| 193 | | 194 | 2.05 Content | 195 | Token: 0x4a | Notification of 196 | Observe: 12 | the current state 197 | Payload: 22.9 Cel | 198 |<-------------------+ 199 | | 200 | 2.05 Content | 201 | Token: 0x4a | Notification upon 202 | Observe: 44 | a state change 203 | Payload: 22.8 Cel | 204 |<-------------------+ 205 | | 206 | 2.05 Content | 207 | Token: 0x4a | Notification upon 208 | Observe: 60 | a state change 209 | Payload: 23.1 Cel | 210 |<-------------------+ 211 | | 213 Figure 2: Observing a Resource in CoAP 215 A client remains on the list of observers as long as the server can 216 determine the client's continued interest in the resource. The 217 interest is determined from the client's acknowledgement of 218 notifications sent in confirmable CoAP messages by the server: If the 219 client actively rejects a notification or if the transmission of a 220 notification times out after several transmission attempts, then the 221 client is assumed to be no longer interested and it is removed from 222 the list of observers. 224 1.3. Observable Resources 226 A CoAP server is the authority for determining under what conditions 227 resources change their state and thus when observers are notified of 228 new resource states. The protocol does not offer explicit means for 229 setting up triggers or thresholds; it is up to the server to expose 230 observable resources that change their state in a way that is useful 231 in the application context. 233 For example, a CoAP server with an attached temperature sensor could 234 expose one or more of the following resources: 236 o , which changes its state every second 237 to the current reading of the temperature sensor; 239 o , which changes its state to 240 "cold" when the temperature reading drops below a certain pre- 241 configured threshold, and to "warm" when the reading exceeds a 242 second, slightly higher threshold; 244 o , which changes its 245 state based on the client-specified parameter value: every second 246 to the current temperature reading if the temperature exceeds the 247 threshold, or to "OK" when the reading drops below; and/or 249 o , which accepts expressions of arbitrary complexity 251 and changes its state accordingly. 253 So, by designing CoAP resources that change their state on certain 254 conditions, it is possible to update the client only when these 255 conditions occur instead of continuously supplying it with raw sensor 256 readings. By parameterizing resources, this is not limited to 257 conditions defined by the server, but can be extended to arbitrarily 258 complex queries specified by the client. Thus, the application 259 designer can choose exactly the right level of complexity for the 260 application envisioned and devices used, and is not constrained to a 261 "one size fits all" mechanism built into the protocol. 263 1.4. Consistency 265 While a client is in the list of observers of a resource, the goal of 266 the protocol is to keep the resource state observed by the client as 267 closely in sync with the actual state at the server as possible. 269 It cannot be avoided that the client and the server become 270 inconsistent at times: First, there is always some latency between 271 the change of the resource state and the receipt of the notification. 272 Second, messages with notifications can get lost, which will cause 273 the client to assume an old state until it receives a new 274 notification. And third, the server may erroneously come to the 275 conclusion that the client is no longer interested in the resource, 276 which will cause the server to stop sending notifications and the 277 client to assume an old state until it registers its interest 278 eventually again. 280 The protocol addresses this as follows: 282 o It follows a best-effort approach for sending the current 283 representation to the client after a state change: Clients should 284 see the new state after a state change as soon as possible, and 285 they should see as many states as possible. However, a client 286 cannot rely on observing every single state that a resource might 287 go through. 289 o It labels notifications with a maximum duration up to which it is 290 acceptable for the observed state and the actual state to be out 291 of sync. When the age of the notification received reaches this 292 limit, the client cannot use the enclosed representation until it 293 receives a new notification. 295 o It is designed on the principle of eventual consistency: The 296 protocol guarantees that, if the resource does not undergo a new 297 change in state, eventually all registered observers will have a 298 current representation of the latest resource state. 300 1.5. Requirements Notation 302 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 303 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 304 document are to be interpreted as described in RFC 2119 [RFC2119]. 306 2. The Observe Option 308 +-----+---+---+---+---+---------+------------+-----------+---------+ 309 | No. | C | U | N | R | Name | Format | Length | Default | 310 +-----+---+---+---+---+---------+------------+-----------+---------+ 311 | 6 | | x | - | | Observe | empty/uint | 0 B/0-3 B | (none) | 312 +-----+---+---+---+---+---------+------------+-----------+---------+ 314 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 316 Table 1: The Observe Option 318 The Observe Option, when present in a request, extends the GET method 319 so it does not only retrieve a current representation of the target 320 resource, but also requests the server to add a new entry to the list 321 of observers of the resource. The list entry consists of the client 322 endpoint and the token specified by the client in the request. 324 The value of the Observe Option in a request MUST be empty on 325 transmission and MUST be ignored on reception. 327 The Observe Option is not critical for processing the request. If 328 the server is unwilling or unable to add the client to the list of 329 observers of the target resource, then the request falls back to a 330 normal GET request. 332 In a response, the Observe Option identifies the message as a 333 notification. This implies that the server has added the client to 334 the list of observers and that it will notify the client of changes 335 to the resource state. 337 The value of the Observe Option in a response is a 24-bit sequence 338 number for reordering detection (see Section 3.4 and Section 4.4). 339 The sequence number is encoded in network byte order using a variable 340 number of bytes ('uint' format; see Section 3.2 of RFC XXXX 341 [I-D.ietf-core-coap]). 343 The Observe Option is not part of the cache-key: a cacheable response 344 obtained with an Observe Option in the request can be used to satisfy 345 a request without an Observe Option, and vice versa. When a stored 346 response that includes an Observe Option is used to satisfy a normal 347 GET request, the option MUST be removed before the response is 348 returned to the client. 350 3. Client-side Requirements 352 3.1. Request 354 A client can register its interest in a resource by issuing a GET 355 request that includes an empty Observe Option. If the server returns 356 a 2.xx response that includes an Observe Option as well, the server 357 has added the client successfully to the list of observers of the 358 target resource and the client will be notified of changes to the 359 resource state. 361 Like a fresh response can be used to satisfy a request without 362 contacting the server, the updates resulting from one request can be 363 used to satisfy another request if the target resource is the same. 364 A client therefore MUST aggregate requests where possible, and MUST 365 NOT register more than once for the same target resource. The target 366 resource SHALL be identified for this purpose by all options in the 367 request that are part of the cache-key, such as the full request URI 368 and the Accept Option. 370 3.2. Notifications 372 Notifications are additional responses sent by the server in reply to 373 the GET request. Each notification includes the token specified by 374 the client in the GET request, an Observe Option with a sequence 375 number for reordering detection (see Section 3.4), and a payload in 376 the same Content-Format as the initial response. 378 Notifications have a 2.05 (Content) response code, or potentially a 379 2.03 (Valid) response code if the client included one or more ETag 380 Options in the request (see Section 3.3). In the event that the 381 resource changes in a way that would cause a normal GET request at 382 that time to return a non-2.xx response (for example, when the 383 resource is deleted), the server sends a notification with an 384 appropriate response code (such as 4.04 Not Found) and removes all 385 clients from the list of observers of the resource. 387 3.3. Caching 389 As notifications are just additional responses to a GET request, 390 notifications partake in caching as defined in Section 5.6 of RFC 391 XXXX [I-D.ietf-core-coap]. Both the freshness model and the 392 validation model are supported. 394 3.3.1. Freshness 396 A client MAY store a notification like a response in its cache and 397 use a stored notification that is fresh without contacting the 398 server. Like a response, a notification is considered fresh while 399 its age is not greater than the value indicated by the Max-Age Option 400 and no newer notification/response has been received. 402 The server will do its best to keep the resource state observed by 403 the client as closely in sync with the actual state as possible. 404 However, a client cannot rely on observing every single state that a 405 resource might go through. For example, if the network is congested 406 or the state changes more frequently than the network can handle, the 407 server can skip notifications for any number of intermediate states. 409 The server uses the Max-Age Option to indicate an age up to which it 410 is acceptable that the observed state and the actual state are 411 inconsistent. If the age of the latest notification becomes greater 412 than its indicated Max-Age, then the client MUST NOT assume that the 413 enclosed representation reflects the actual resource state. 415 To make sure it has a current representation and/or to re-register 416 its interest in a resource, a client MAY issue a new GET request with 417 an Observe Option and the same token at any time. It is RECOMMENDED 418 that the client does not issue the request while it still has a fresh 419 notification/response for the resource in its cache. Additionally, 420 the client SHOULD wait for a random amount of time between 5 and 15 421 seconds to avoid synchronicity with other clients. 423 3.3.2. Validation 425 When a client has one or more notifications stored in its cache for a 426 resource, it can use the ETag Option in the GET request to give the 427 server an opportunity to select a stored notification to be used. 429 The client MAY include an ETag Option for each stored response that 430 is applicable in the GET request. Whenever the observed resource 431 changes to a representation identified by one of the ETag Options, 432 the server can select a stored response by sending a 2.03 (Valid) 433 notification with an appropriate ETag Option instead of a 2.05 434 (Content) notification. 436 A client implementation needs to keep all candidate responses in its 437 cache until it is no longer interested in the target resource or it 438 issues a GET request with a new set of entity-tags. 440 3.4. Reordering 442 Messages with notifications can arrive in a different order than they 443 were sent. Since the goal is to keep the observed state as closely 444 in sync with the actual state as possible, a client MUST NOT update 445 the observed state with a notification that arrives later than a 446 newer notification. 448 For reordering detection, the server sets the value of the Observe 449 Option in each notification to the 24 least-significant bits of a 450 strictly increasing sequence number. An incoming notification is 451 newer than the newest notification received so far when one of the 452 following conditions is met: 454 (V1 < V2 and V2 - V1 < 2^23) or 455 (V1 > V2 and V1 - V2 > 2^23) or 456 (T2 > T1 + 128 seconds) 458 where V1 is the value of the Observe Option of the newest 459 notification received so far, V2 the value of the Observe Option of 460 the incoming notification, T1 a client-local timestamp of the newest 461 notification received so far, and T2 a client-local timestamp of the 462 incoming notification. 464 Design Note: The first two conditions verify that V1 is less than V2 465 in 24-bit serial number arithmetic [RFC1982]. The third condition 466 ensures that the time elapsed between the two incoming messages is 467 not so large that the difference between V1 and V2 has become 468 larger than the largest integer that it is meaningful to add to a 469 24-bit serial number; in other words, after 128 seconds have 470 elapsed without any notification, a client does not need to check 471 the sequence numbers to assume an incoming notification is new. 473 The duration of 128 seconds was chosen as a nice round number 474 greater than MAX_LATENCY (see Section 4.8.2 of RFC XXXX 475 [I-D.ietf-core-coap]). 477 3.5. Transmission 479 A notification can be confirmable or non-confirmable, i.e., be sent 480 in a confirmable or a non-confirmable message. The message type used 481 for a notification is independent from the type used for the request 482 or for any previous notification. 484 If a client does not recognize the token in a confirmable 485 notification, it MUST NOT acknowledge the message and SHOULD reject 486 it with a Reset message; otherwise, the client MUST acknowledge the 487 message as usual. In the case of a non-confirmable notification, 488 rejecting the message with a Reset message is OPTIONAL. 490 An acknowledgement message signals to the server that the client is 491 alive and interested in receiving further notifications; if the 492 server does not receive an acknowledgement in reply to a confirmable 493 notification, it will assume that the client is no longer interested 494 and will eventually remove the associated entry from the list of 495 observers. 497 3.6. Cancellation 499 A client that is no longer interested in receiving further 500 notifications for a resource can simply "forget" the pending request. 501 When the server then sends a notification, the client will not 502 recognize the token in the message. If the notification was 503 confirmable, this will cause the client to return a Reset message and 504 thus the server to remove the associated entry from the list of 505 observers. Entries in lists of observers are effectively "garbage 506 collected" by the server. 508 When a client rejects a non-confirmable notification, the server may 509 also (but is not required to) remove the associated entry from the 510 list of observers. So, if the servers seems to ignore the Reset 511 messages that the client sends to reject non-confirmable 512 notifications, the client may have to wait for a confirmable 513 notification until the list entry is removed. 515 4. Server-side Requirements 517 4.1. Request 519 A GET request with an Observe Option requests the server not only to 520 return a current representation of the target resource, but also to 521 add the client to the list of observers of that resource. Upon 522 success, the server MUST return a current representation of the 523 resource and MUST notify the client of subsequent changes to the 524 state as long as the client is on the list of observers. 526 The entry in the list of observers is keyed by the client endpoint 527 and the token specified by the client in the request. If an entry 528 with a matching endpoint/token pair is already present in the list 529 (which, for example, happens when the client wishes to reinforce its 530 interest in a resource), the server MUST NOT add a new entry but MUST 531 replace or update the existing one. 533 A server that is unable or unwilling to add a new entry to the list 534 of observers of a resource MAY silently ignore the Observe Option and 535 process the GET request as usual. The resulting response MUST NOT 536 include an Observe Option, the absence of which signals to the client 537 that it will not be notified of changes to the resource and, e.g., 538 needs to poll the resource for its state instead. 540 4.2. Notifications 542 A client is notified of changes to the resource state by additional 543 responses sent by the server in reply to the GET request. Each such 544 notification response (including the initial response) MUST include 545 an Observe Option and MUST echo the token specified by the client in 546 the GET request. If there are multiple entries in the list of 547 observers, the order in which the clients are notified is not 548 defined; the server is free to use any method to determine the order. 550 A notification SHOULD have a 2.05 (Content) or 2.03 (Valid) response 551 code. However, in the event that the state of a resource changes in 552 a way that would cause a normal GET request at that time to return a 553 non-2.xx response (for example, when the resource is deleted), the 554 server SHOULD notify the client by sending a notification with an 555 appropriate response code (such as 4.04 Not Found) and MUST remove 556 the client from the list of observers of the resource. 558 The Content-Format used in a notification MUST be the same as the one 559 used in the initial response to the GET request. If the server is 560 unable to continue sending notifications in this Content-Format, it 561 SHOULD send a notification with a 4.06 (Not Acceptable) response code 562 and MUST remove the client from the list of observers of the 563 resource. 565 A non-2.xx notification MUST NOT include an Observe Option. 567 4.3. Caching 569 As notifications are just additional responses sent by the server, 570 they are subject to caching as defined in Section 5.6 of RFC XXXX 571 [I-D.ietf-core-coap]. 573 4.3.1. Freshness 575 After returning the initial response, the server MUST try to keep the 576 returned representation current, i.e., keep the resource state 577 observed by the client as closely in sync with the actual resource 578 state as possible. 580 Since becoming out of sync at times cannot be avoided, the server 581 MUST indicate for each representation an age up to which it is 582 acceptable that the observed state and the actual state are 583 inconsistent. This age is application-dependent and MUST be 584 specified in notifications using the Max-Age Option. 586 When the resource does not change and the client has a current 587 representation, the server does not need to send a notification. 588 However, if the client does not receive a notification, the client 589 cannot tell if the observed state and the actual state are still in 590 sync. Thus, when the the age of the latest notification becomes 591 greater than its indicated Max-Age, the client no longer has a usable 592 representation of the resource state. The server MAY wish to prevent 593 that by sending a notification with the unchanged representation and 594 a new Max-Age just before the old Max-Age expires. 596 4.3.2. Validation 598 A client can include a set of entity-tags in its request using the 599 ETag Option. When a observed resource changes its state and the 600 origin server is about to send a 2.05 (Content) notification, then, 601 whenever that notification has an entity-tag in the set of entity- 602 tags specified by the client, the server MAY send a 2.03 (Valid) 603 response with an appropriate ETag Option instead. 605 4.4. Reordering 607 Because messages can get reordered, the client needs a way to 608 determine if a notification arrived later than a newer notification. 609 For this purpose, the server MUST set the value of the Observe Option 610 of each notification it sends to the 24 least-significant bits of a 611 strictly increasing sequence number. The sequence number MAY start 612 at any value and MUST NOT increase so fast that it increases by more 613 than 2^23 within less than 256 seconds. 615 The sequence number selected for a notification MUST be greater than 616 that of any preceding notification sent to the same client with the 617 same token for the same resource. The value of the Observe Option 618 MUST be current at the time of transmission; if a notification is 619 retransmitted, the server MUST update the value of the option to the 620 sequence number that is current at that time before sending the 621 message. 623 The sequence numbers generated for a resource MUST provide an order 624 among all notifications resulting from all requests from the same 625 client endpoint. 627 Implementation Note: A simple implementation that satisfies the 628 requirements is to obtain a timestamp from a local clock. The 629 sequence number then is the timestamp in ticks, where 1 tick = 630 (256 seconds)/(2^23) = 30.52 microseconds. It is not necessary 631 that the clock reflects the current time/date. 633 Another valid implementation is to store a 24-bit unsigned integer 634 variable per resource and increment this variable each time the 635 resource undergoes a change of state (provided that the resource 636 changes its state less than 2^23 times in the next 256 seconds 637 after every state change). This removes the need to update the 638 value of the Observe Option on retransmission when the resource 639 state did not change. 641 Design Note: The choice of a 24-bit option value and a time span of 642 256 seconds allows for a notification rate of up to 65536 643 notifications per second. Constrained nodes often have rather 644 imprecise clocks, though, and inaccuracies of the client and 645 server side may cancel out or add in effect. Reducing the maximum 646 notification rate to 32768 notifications per second is still well 647 beyond the highest known design objective of around 1 kHz (most 648 CoAP applications will be several orders of magnitude below that), 649 but allows total clock inaccuracies of up to -50/+100 %. 651 4.5. Transmission 653 A notification can be sent in a confirmable or a non-confirmable 654 message. The message type used is typically application-dependent 655 and MAY be determined by the server for each notification 656 individually. For example, for resources that change in a somewhat 657 predictable or regular fashion, notifications can be sent in non- 658 confirmable messages; for resources that change infrequently, 659 notifications can be sent in confirmable messages. The server can 660 combine these two approaches depending on the frequency of state 661 changes and the importance of individual notifications. 663 A server MAY choose to skip sending a notification if it knows that 664 it will send another notification soon, for example, when the state 665 is changing frequently. Similarly, it MAY choose to send a 666 notification more than once. However, above all, the server MUST 667 ensure that a client in the list of observers of a resource 668 eventually observes the latest state if the resource does not undergo 669 a new change in state. For example, when state changes occur in 670 bursts, the server can skip some notifications, send the 671 notifications in non-confirmable messages, and make sure that the 672 client observes the latest state change by repeating the last 673 notification in a confirmable message when the burst is over. 675 The client's acknowledgement of a confirmable notification signals to 676 the server that the client is interested in receiving further 677 notifications. If a client rejects a confirmable notification with a 678 Reset message, the client is no longer interested and the server MUST 679 remove the associated entry from the list of observers. If the 680 client rejects a non-confirmable notification, the server MAY remove 681 the entry from the list of observers as well. (It is expected that 682 the server does remove the entry if it has the information available 683 that is needed to match the Reset message to the non-confirmable 684 notification, but the server is not required to keep this 685 information.) 687 At a minimum, the server MUST send a notification in a confirmable 688 message instead of a non-confirmable message at least every 24 hours, 689 so a client that went away or is no longer interested does not remain 690 forever in the list of observers. 692 The server MUST limit the number of confirmable notifications for 693 which an acknowledgement has not been received from a client yet to 694 NSTART (1 by default; see Section 4.7 of RFC XXXX 695 [I-D.ietf-core-coap]). 697 The server SHOULD NOT send more than one non-confirmable notification 698 per round-trip time (RTT) to a client on average. If the server 699 cannot maintain an RTT estimate for a client, it SHOULD NOT send more 700 than one non-confirmable notification every 3 seconds, and SHOULD use 701 an even less aggressive rate when possible (see also Section 3.1.2 of 702 RFC 5405 [RFC5405]). 704 When the state of an observed resource changes while the number of 705 outstanding acknowledgements is greater than or equal to NSTART, or 706 while the waiting time for a non-confirmable notification has not 707 elapsed yet, the server MUST proceed as follows: 709 1. Wait for the current transmission attempt to be acknowledged, 710 rejected or to time out (confirmable transmission), or the 711 waiting time to elapse (non-confirmable transmission). 713 2. If the transmission is rejected or the transmission was the last 714 attempt to deliver a notification, remove the associated entry 715 from the list of observers of the observed resource. 717 3. If the entry is still in the list of observers, start to transmit 718 a new notification with a representation of the current resource 719 state. Should the resource have changed its state more than once 720 in the meantime, the notifications for the intermediate states 721 are silently skipped. 723 4. If the completed transmission attempt timed out, increment the 724 retransmission counter and double the timeout for the new 725 transmission; otherwise, reinitialize both the retransmission 726 counter and timeout as described in Section 4.2 of RFC XXXX 727 [I-D.ietf-core-coap]. 729 5. Intermediaries 731 A client may be interested in a resource in the namespace of an 732 origin server that is reached through a chain of one or more CoAP 733 intermediaries. In this case, the client registers its interest with 734 the first intermediary towards the origin server, acting as if it was 735 communicating with the origin server itself as specified in 736 Section 3. It is the task of this intermediary to provide the client 737 with a current representation of the target resource and send 738 notifications upon changes to the target resource state, much like an 739 origin server as specified in Section 4. 741 To perform this task, the intermediary SHOULD make use of the 742 protocol specified in this document, taking the role of the client 743 and registering its own interest in the target resource with the next 744 hop towards the origin server. If the next hop does not return a 745 response with an Observe Option, the intermediary MAY resort to 746 polling the next hop or MAY itself return a response without an 747 Observe Option. 749 The communication between each pair of hops is independent; each hop 750 in the server role MUST determine individually how many notifications 751 to send, of which message type, and so on. Each hop MUST generate 752 its own values for the Observe Option, and MUST set the value of the 753 Max-Age Option according to the age of the local current 754 representation. 756 If two or more clients have registered their interest in a resource 757 with an intermediary, the intermediary MUST register itself only once 758 with the next hop and fan out the notifications it receives to all 759 registered clients. This relieves the next hop from sending the same 760 notifications multiple times and thus enables scalability. 762 An intermediary is not required to act on behalf of a client to 763 observe a resource; an intermediary MAY observe a resource, for 764 example, just to keep its own cache up to date. 766 See Appendix A.2 for examples. 768 6. Web Linking 770 A web link [RFC5988] to a resource accessible over CoAP (for example, 771 in a link-format document [RFC6690]) MAY include the target attribute 772 "obs". 774 The "obs" attribute, when present, is a hint indicating that the 775 destination of a link is useful for observation and thus, for 776 example, should have a suitable graphical representation in a user 777 interface. Note that this is only a hint; it is not a promise that 778 the Observe Option can actually be used to perform the observation. 779 A client may need to resort to polling the resource if the Observe 780 Option is not returned in the response to the GET request. 782 A value MUST NOT be given for the "obs" attribute; any present value 783 MUST be ignored by parsers. The "obs" attribute MUST NOT appear more 784 than once in a given link-value; occurrences after the first MUST be 785 ignored by parsers. 787 7. Security Considerations 789 The security considerations of RFC XXXX [I-D.ietf-core-coap] apply. 791 The considerations about amplification attacks are somewhat amplified 792 when observing resources. Without client authentication, a server 793 MUST therefore strictly limit the number of notifications that it 794 sends between receiving acknowledgements that confirm the actual 795 interest of the client in the data; i.e., any notifications sent in 796 non-confirmable messages MUST be interspersed with confirmable 797 messages. (An attacker may still spoof the acknowledgements if the 798 confirmable messages are sufficiently predictable.) 800 As with any protocol that creates state, attackers may attempt to 801 exhaust the resources that the server has available for maintaining 802 the list of observers for each resource. Servers may want to access- 803 control this creation of state. As degraded behavior, the server can 804 always fall back to processing the request as a normal GET request 805 (without an Observe Option) if it is unwilling or unable to add a 806 client to the list of observers of a resource, including if system 807 resources are exhausted or nearing exhaustion. 809 Intermediaries must be careful to ensure that notifications cannot be 810 employed to create a loop. A simple way to break any loops is to 811 employ caches for forwarding notifications in intermediaries. 813 8. IANA Considerations 815 The following entry is added to the CoAP Option Numbers registry: 817 +--------+---------+-----------+ 818 | Number | Name | Reference | 819 +--------+---------+-----------+ 820 | 6 | Observe | [RFCXXXX] | 821 +--------+---------+-----------+ 823 [Note to RFC Editor: Please replace XXXX with the RFC number of this 824 specification.] 826 9. Acknowledgements 828 Carsten Bormann was an original author of this draft and is 829 acknowledged for significant contribution to this document. 831 Thanks to Daniele Alessandrelli, Jari Arkko, Peter Bigot, Angelo P. 832 Castellani, Gilbert Clark, Esko Dijk, Thomas Fossati, Brian Frank, 833 Bert Greevenbosch, Jeroen Hoebeke, Cullen Jennings, Matthias 834 Kovatsch, Salvatore Loreto, Charles Palmer, Zach Shelby, and Floris 835 Van den Abeele for helpful comments and discussions that have shaped 836 the document. 838 This work was supported in part by Klaus Tschira Foundation, Intel, 839 Cisco, and Nokia. 841 10. References 843 10.1. Normative References 845 [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, 846 "Constrained Application Protocol (CoAP)", 847 draft-ietf-core-coap-18 (work in progress), 848 June 2013. 850 [RFC1982] Elz, R. and R. Bush, "Serial Number 851 Arithmetic", RFC 1982, August 1996. 853 [RFC2119] Bradner, S., "Key words for use in RFCs to 854 Indicate Requirement Levels", BCP 14, RFC 2119, 855 March 1997. 857 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage 858 Guidelines for Application Designers", BCP 145, 859 RFC 5405, November 2008. 861 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 862 October 2010. 864 10.2. Informative References 866 [GOF] Gamma, E., Helm, R., Johnson, R., and J. 867 Vlissides, "Design Patterns: Elements of 868 Reusable Object-Oriented Software", Addison- 869 Wesley, Reading, MA, USA, November 1994. 871 [REST] Fielding, R., "Architectural Styles and the 872 Design of Network-based Software 873 Architectures", Ph.D. Dissertation, University 874 of California, Irvine, 2000, . 878 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, 879 H., Masinter, L., Leach, P., and T. Berners- 880 Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 881 RFC 2616, June 1999. 883 [RFC5989] Roach, A., "A SIP Event Package for Subscribing 884 to Changes to an HTTP Resource", RFC 5989, 885 October 2010. 887 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and 888 G. Wilkins, "Known Issues and Best Practices 889 for the Use of Long Polling and Streaming in 890 Bidirectional HTTP", RFC 6202, April 2011. 892 [RFC6690] Shelby, Z., "Constrained RESTful Environments 893 (CoRE) Link Format", RFC 6690, August 2012. 895 Appendix A. Examples 896 A.1. Client/Server Examples 898 Observed CLIENT SERVER Actual 899 t State | | State 900 ____________ | | ____________ 901 1 | | 902 2 unknown | | 18.5 Cel 903 3 +----->| Header: GET 0x41011633 904 4 | GET | Token: 0x4a 905 5 | | Uri-Path: temperature 906 6 | | Observe: (empty) 907 7 | | 908 8 | | 909 9 ____________ |<-----+ Header: 2.05 0x61451633 910 10 | 2.05 | Token: 0x4a 911 11 18.5 Cel | | Observe: 9 912 12 | | Max-Age: 15 913 13 | | Payload: "18.5 Cel" 914 14 | | 915 15 | | ____________ 916 16 ____________ |<-----+ Header: 2.05 0x51457b50 917 17 | 2.05 | 19.2 Cel Token: 0x4a 918 18 19.2 Cel | | Observe: 16 919 29 | | Max-Age: 15 920 20 | | Payload: "19.2 Cel" 921 21 | | 923 Figure 3: A client registers and receives one notification of the 924 current state and one of a new state upon a state change 925 Observed CLIENT SERVER Actual 926 t State | | State 927 ____________ | | ____________ 928 22 | | 929 23 19.2 Cel | | 19.2 Cel 930 24 | | ____________ 931 25 | X----+ Header: 2.05 0x51457b51 932 26 | 2.05 | 19.7 Cel Token: 0x4a 933 27 | | Observe: 25 934 28 | | Max-Age: 15 935 29 | | Payload: "19.7 Cel" 936 30 | | 937 31 ____________ | | 938 32 | | 939 33 19.2 Cel | | 940 34 (stale) | | 941 35 | | 942 36 | | 943 37 | | 944 38 +----->| Header: GET 0x41011634 945 39 | GET | Token: 0xb2 946 40 | | Uri-Path: temperature 947 41 | | Observe: (empty) 948 42 | | 949 43 | | 950 44 ____________ |<-----+ Header: 2.05 0x61451634 951 45 | 2.05 | Token: 0xb2 952 46 19.7 Cel | | Observe: 44 953 47 | | Max-Age: 15 954 48 | | ETag: 0x78797a7a79 955 49 | | Payload: "19.7 Cel" 956 50 | | 958 Figure 4: The client re-registers after Max-Age ends 960 Observed CLIENT SERVER Actual 961 t State | | State 962 ____________ | | ____________ 963 51 | | 964 52 19.7 Cel | | 19.7 Cel 965 53 | | 966 54 | | ____________ 967 55 | crash 968 56 | 969 57 | 970 58 | 971 59 ____________ | 972 60 | 973 61 19.7 Cel | 974 62 (stale) | 975 63 | reboot____________ 976 64 | | 977 65 | | 20.0 Cel 978 66 | | 979 67 +----->| Header: GET 0x41011635 980 68 | GET | Token: 0xf9 981 69 | | Uri-Path: temperature 982 70 | | Observe: (empty) 983 71 | | ETag: 0x78797a7a79 984 72 | | 985 73 | | 986 74 ____________ |<-----+ Header: 2.05 0x61451635 987 75 | 2.05 | Token: 0xf9 988 76 20.0 Cel | | Observe: 74 989 77 | | Max-Age: 15 990 78 | | Payload: "20.0 Cel" 991 79 | | 992 80 | | ____________ 993 81 ____________ |<-----+ Header: 2.03 0x5143aa0c 994 82 | 2.03 | 19.7 Cel Token: 0xf9 995 83 19.7 Cel | | Observe: 81 996 84 | | ETag: 0x78797a7a79 997 85 | | Max-Age: 15 998 86 | | 1000 Figure 5: The client re-registers and gives the server the 1001 opportunity to select a stored response 1003 Observed CLIENT SERVER Actual 1004 t State | | State 1005 ____________ | | ____________ 1006 87 | | 1007 88 19.7 Cel | | 19.7 Cel 1008 89 | | 1009 90 | | ____________ 1010 91 ____________ |<-----+ Header: 2.05 0x4145aa0f 1011 92 | 2.05 | 19.3 Cel Token: 0xf9 1012 93 19.3 Cel | | Observe: 91 1013 94 | | Max-Age: 15 1014 95 | | Payload: "19.3 Cel" 1015 96 | | 1016 97 | | 1017 98 +- - ->| Header: 0x7000aa0f 1018 99 | | 1019 100 | | 1020 101 | | 1021 102 | | ____________ 1022 103 | | 1023 104 | | 19.0 Cel 1024 105 | | 1025 106 ____________ | | 1026 107 | | 1027 108 19.3 Cel | | 1028 109 (stale) | | 1029 110 | | 1031 Figure 6: The client rejects a notification and thereby cancels the 1032 observation 1034 A.2. Proxy Examples 1036 CLIENT PROXY SERVER 1037 | | | 1038 | +----->| Header: GET 0x41015fb8 1039 | | GET | Token: 0x1a 1040 | | | Uri-Host: sensor.example 1041 | | | Uri-Path: status 1042 | | | Observe: (empty) 1043 | | | 1044 | |<-----+ Header: 2.05 0x61455fb8 1045 | | 2.05 | Token: 0x1a 1046 | | | Observe: 42 1047 | | | Max-Age: 60 1048 | | | Payload: "ready" 1049 | | | 1050 +----->| | Header: GET 0x41011633 1051 | GET | | Token: 0x9a 1052 | | | Proxy-Uri: coap://sensor.example/status 1053 | | | 1054 |<-----+ | Header: 2.05 0x61451633 1055 | 2.05 | | Token: 0x9a 1056 | | | Max-Age: 53 1057 | | | Payload: "ready" 1058 | | | 1059 | |<-----+ Header: 2.05 0x514505fc0 1060 | | 2.05 | Token: 0x1a 1061 | | | Observe: 135 1062 | | | Max-Age: 60 1063 | | | Payload: "busy" 1064 | | | 1065 +----->| | Header: GET 0x41011634 1066 | GET | | Token: 0x9b 1067 | | | Proxy-Uri: coap://sensor.example/status 1068 | | | 1069 |<-----+ | Header: 2.05 0x61451634 1070 | 2.05 | | Token: 0x9b 1071 | | | Max-Age: 49 1072 | | | Payload: "busy" 1073 | | | 1075 Figure 7: A proxy observes a resource to keep its cache up to date 1077 CLIENT PROXY SERVER 1078 | | | 1079 +----->| | Header: GET 0x41011635 1080 | GET | | Token: 0x6a 1081 | | | Proxy-Uri: coap://sensor.example/status 1082 | | | Observe: (empty) 1083 | | | 1084 |<- - -+ | Header: 0x60001635 1085 | | | 1086 | +----->| Header: GET 0x4101af90 1087 | | GET | Token: 0xaa 1088 | | | Uri-Host: sensor.example 1089 | | | Uri-Path: status 1090 | | | Observe: (empty) 1091 | | | 1092 | |<-----+ Header: 2.05 0x6145af90 1093 | | 2.05 | Token: 0xaa 1094 | | | Observe: 67 1095 | | | Max-Age: 60 1096 | | | Payload: "ready" 1097 | | | 1098 |<-----+ | Header: 2.05 0x4145af94 1099 | 2.05 | | Token: 0x6a 1100 | | | Observe: 17346 1101 | | | Max-Age: 60 1102 | | | Payload: "ready" 1103 | | | 1104 +- - ->| | Header: 0x6000af94 1105 | | | 1106 | |<-----+ Header: 2.05 0x51455a20 1107 | | 2.05 | Token: 0xaa 1108 | | | Observe: 157 1109 | | | Max-Age: 60 1110 | | | Payload: "busy" 1111 | | | 1112 |<-----+ | Header: 2.05 0x5145af9b 1113 | 2.05 | | Token: 0x6a 1114 | | | Observe: 17436 1115 | | | Max-Age: 60 1116 | | | Payload: "busy" 1117 | | | 1119 Figure 8: A client observes a resource through a proxy 1121 Appendix B. Changelog 1123 [Note to RFC Editor: Please remove this section before publication.] 1125 Changes from ietf-10 to ietf-11: 1127 o Pointed out that client and server clocks may differ in their 1128 realization of the SI second, and added robustness to the existing 1129 reordering scheme by reducing the maximum notification rate to 1130 32768 notifications per second (#341). 1132 Changes from ietf-09 to ietf-10: 1134 o Required consistent sequence numbers across requests (#333). 1136 o Clarified that a server needs to update the entry in the list of 1137 observers instead of adding a new entry if the endpoint/token pair 1138 is already present. 1140 o Allowed that a client uses a token that is currently in use to 1141 ensure that it's still in the list of observers. This is possible 1142 because sequence numbers are now consistent across requests and 1143 servers won't add a new entry for the same token. 1145 o Improved text on the transmission of non-confirmable notifications 1146 to match Section 3.1.2 of RFC 5405 more closely. 1148 o Updated examples to use UCUM units. 1150 o Moved Appendix B into the introduction. 1152 Changes from ietf-08 to ietf-09: 1154 o Removed the side effects of requests on existing observations. 1155 This includes removing that 1157 * the client can use a GET request to cancel an observation; 1159 * the server updates the entry in the list of observers instead 1160 of adding a new entry if the client is already present (#258, 1161 #281). 1163 o Clarified that a resource (and hence an observation relationship) 1164 is identified by the request options that are part of the Cache- 1165 Key (#258). 1167 o Clarified that a non-2.xx notification MUST NOT include an Observe 1168 Option. 1170 o Moved block-wise transfer of notifications to [I-D.ietf-core- 1171 block]. 1173 Changes from ietf-07 to ietf-08: 1175 o Expanded text on transmitting a notification while a previous 1176 transmission is pending (#242). 1178 o Changed reordering detection to use a fixed time span of 128 1179 seconds instead of EXCHANGE_LIFETIME (#276). 1181 o Removed the use of the freshness model to determine if the client 1182 is still on the list of observers. This includes removing that 1184 * the client assumes that it has been removed from the list of 1185 observers when Max-Age ends; 1187 * the server sets the Max-Age Option of a notification to a value 1188 that indicates when the server will send the next notification; 1190 * the server uses a number of retransmit attempts such that 1191 removing a client from the list of observers before Max-Age 1192 ends is avoided (#235); 1194 * the server may remove the client from all lists of observers 1195 when the transmission of a confirmable notification ultimately 1196 times out. 1198 o Changed that an unrecognized critical option in a request must 1199 actually have no effect on the state of any observation 1200 relationship to any resource, as the option could lead to a 1201 different target resource. 1203 o Clarified that client implementations must be prepared to receive 1204 each notification equally as a confirmable or a non-confirmable 1205 message, regardless of the message type of the request and of any 1206 previous notification. 1208 o Added a requirement for sending a confirmable notification at 1209 least every 24 hours before continuing with non-confirmable 1210 notifications (#221). 1212 o Added congestion control considerations from [I-D.bormann-core- 1213 congestion-control-02]. 1215 o Recommended that the client waits for a randomized time after the 1216 freshness of the latest notification expired before re- 1217 registering. This prevents that multiple clients observing a 1218 resource perform a GET request at the same time when the need to 1219 re-register arises. 1221 o Changed reordering detection from 'MAY' to 'SHOULD', as the goal 1222 of the protocol (to keep the observed state as closely in sync 1223 with the actual state as possible) is not optional. 1225 o Fixed the length of the Observe Option (3 bytes) in the table in 1226 Section 2. 1228 o Replaced the 'x' in the No-Cache-Key column in the table in 1229 Section 2 with a '-', as the Observe Option doesn't have the No- 1230 Cache-Key flag set, even though it is not part of the cache key. 1232 o Updated examples. 1234 Changes from ietf-06 to ietf-07: 1236 o Moved to 24-bit sequence numbers to allow for up to 15000 1237 notifications per second per client and resource (#217). 1239 o Re-numbered option number to use Unsafe/Safe and Cache-Key 1240 compliant numbers (#241). 1242 o Clarified how to react to a Reset message that is sent in reply to 1243 a non-confirmable notification (#225). 1245 o Clarified the semantics of the "obs" link target attribute (#236). 1247 Changes from ietf-05 to ietf-06: 1249 o Improved abstract and introduction to say that the protocol is 1250 about best effort and eventual consistency (#219). 1252 o Clarified that the value of the Observe Option in a request must 1253 have zero length. 1255 o Added requirement that the sequence number must be updated each 1256 time a server retransmits a notification. 1258 o Clarified that a server must remove a client from the list of 1259 observers when it receives a GET request with an unrecognized 1260 critical option. 1262 o Updated the text to use the endpoint concept from 1263 [I-D.ietf-core-coap] (#224). 1265 o Improved the reordering text (#223). 1267 Changes from ietf-04 to ietf-05: 1269 o Recommended that a client does not re-register while a new 1270 notification from the server is still likely to arrive. This is 1271 to avoid that the request of the client and the last notification 1272 after max-age cross over each other (#174). 1274 o Relaxed requirements when sending a Reset message in reply to non- 1275 confirmable notifications. 1277 o Added an implementation note about careless GET requests (#184). 1279 o Updated examples. 1281 Changes from ietf-03 to ietf-04: 1283 o Removed the "Max-OFE" Option. 1285 o Allowed a Reset message in reply to non-confirmable notifications. 1287 o Added a section on cancellation. 1289 o Updated examples. 1291 Changes from ietf-02 to ietf-03: 1293 o Separated client-side and server-side requirements. 1295 o Fixed uncertainty if client is still on the list of observers by 1296 introducing a liveliness model based on Max-Age and a new option 1297 called "Max-OFE" (#174). 1299 o Simplified the text on message reordering (#129). 1301 o Clarified requirements for intermediaries. 1303 o Clarified the combination of blockwise transfers with 1304 notifications (#172). 1306 o Updated examples to show how the state observed by the client 1307 becomes eventually consistent with the actual state on the server. 1309 o Added examples for parameterization of observable resource. 1311 Changes from ietf-01 to ietf-02: 1313 o Removed the requirement of periodic refreshing (#126). 1315 o The new "Observe" Option replaces the "Lifetime" Option. 1317 o Introduced a new mechanism to detect message reordering. 1319 o Changed 2.00 (OK) notifications to 2.05 (Content) notifications. 1321 Changes from ietf-00 to ietf-01: 1323 o Changed terminology from "subscriptions" to "observation 1324 relationships" (#33). 1326 o Changed the name of the option to "Lifetime". 1328 o Clarified establishment of observation relationships. 1330 o Clarified that an observation is only identified by the URI of the 1331 observed resource and the identity of the client (#66). 1333 o Clarified rules for establishing observation relationships (#68). 1335 o Clarified conditions under which an observation relationship is 1336 terminated. 1338 o Added explanation on how clients can terminate an observation 1339 relationship before the lifetime ends (#34). 1341 o Clarified that the overriding objective for notifications is 1342 eventual consistency of the actual and the observed state (#67). 1344 o Specified how a server needs to deal with clients not 1345 acknowledging confirmable messages carrying notifications (#69). 1347 o Added a mechanism to detect message reordering (#35). 1349 o Added an explanation of how notifications can be cached, 1350 supporting both the freshness and the validation model (#39, #64). 1352 o Clarified that non-GET requests do not affect observation 1353 relationships, and that GET requests without "Lifetime" Option 1354 affecting relationships is by design (#65). 1356 o Described interaction with blockwise transfers (#36). 1358 o Added Resource Discovery section (#99). 1360 o Added IANA Considerations. 1362 o Added Security Considerations (#40). 1364 o Added examples (#38). 1366 Author's Address 1368 Klaus Hartke 1369 Universitaet Bremen TZI 1370 Postfach 330440 1371 Bremen D-28359 1372 Germany 1374 Phone: +49-421-218-63905 1375 EMail: hartke@tzi.org