idnits 2.17.1 draft-ietf-core-observe-09.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 (July 15, 2013) is 3937 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 760, but not defined ** 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: 1 error (**), 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 July 15, 2013 5 Expires: January 16, 2014 7 Observing Resources in CoAP 8 draft-ietf-core-observe-09 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 January 16, 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. Requirements Notation . . . . . . . . . . . . . . . . . . 6 60 2. The Observe Option . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Client-side Requirements . . . . . . . . . . . . . . . . . . . 7 62 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 7 64 3.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.4. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.5. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.6. Transmission . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.7. Cancellation . . . . . . . . . . . . . . . . . . . . . . . 10 69 4. Server-side Requirements . . . . . . . . . . . . . . . . . . . 11 70 4.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Reordering . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.5. Transmission . . . . . . . . . . . . . . . . . . . . . . . 13 75 5. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 84 A.1. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 Appendix B. Modeling Resources to Tailor Notifications . . . . . 24 86 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . . 24 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 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. A representation captures the current or 102 intended state of a resource. The server is the definitive source 103 for representations of the resources in its namespace. A client 104 interested in the state of a resource initiates a request to the 105 server; the server then returns a response with a representation of 106 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 keep this representation updated by the server over a 118 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, it must register separately for all of them. 137 Observer Subject 138 | | 139 | Registration | 140 +----------------->| 141 | | 142 | Notification | 143 |<-----------------+ 144 | | 145 | Notification | 146 |<-----------------+ 147 | | 148 | Notification | 149 |<-----------------+ 150 | | 152 Figure 1: The Observer Design Pattern 154 The observer design pattern is realized in CoAP as follows: 156 Subject: In the context of CoAP, the subject is a resource in the 157 namespace of a CoAP server. The state of the resource can change 158 over time, ranging from infrequent updates to continuous state 159 transformations. 161 Observer: An observer is a CoAP client that is interested in having 162 a current representation of the resource at any given time. 164 Registration: A client registers its interest in a resource by 165 initiating an extended GET request to the server. In addition to 166 returning a representation of the target resource, this request 167 causes the server to add the client endpoint and token specified 168 in the request to the list of observers of that resource. 170 Notification: Whenever the state of a resource changes, the server 171 notifies each client in the list of observers of the resource. 172 Each notification is an additional CoAP response sent by the 173 server in reply to the GET request and includes a complete, 174 updated representation of the new resource state. 176 Figure 2 below shows an example of a CoAP client registering its 177 interest in a resource and receiving three notifications: the first 178 upon registration with the current state, and then two upon changes 179 to the resource state. Both the registration request and the 180 notifications are identified as such by the presence of the Observe 181 Option defined in this document. In notifications, the Observe 182 Option provides a sequence number for reordering detection. All 183 notifications carry the token specified by the client in the request, 184 so the client can easily correlate them to the request. 186 Client Server 187 | | 188 | GET /temperature | 189 | Token: 0x4a | Registration 190 | Observe: (empty) | 191 +----------------->| 192 | | 193 | 2.05 Content | 194 | Token: 0x4a | Notification of 195 | Observe: 12 | the current state 196 | Payload: 22.9 C | 197 |<-----------------+ 198 | | 199 | 2.05 Content | 200 | Token: 0x4a | Notification upon 201 | Observe: 44 | a state change 202 | Payload: 22.8 C | 203 |<-----------------+ 204 | | 205 | 2.05 Content | 206 | Token: 0x4a | Notification upon 207 | Observe: 60 | a state change 208 | Payload: 23.1 C | 209 |<-----------------+ 210 | | 212 Figure 2: Observing a Resource in CoAP 214 The server is the authority for determining under what conditions 215 resources change their state and how often observers are notified. 216 The protocol does not offer explicit means for setting up triggers, 217 thresholds or other conditions; it is up to the server to expose 218 observable resources that change their state in a way that is useful 219 in the application context. Resources can be parameterized to 220 achieve similar effects, though; see Appendix B for examples. 222 A client's entry remains on the list of observers as long as the 223 server can determine the client's continued interest in the resource. 224 The interest is determined from the client's acknowledgement of 225 notifications sent in confirmable messages by the server: If the 226 client actively rejects a notification or if the transmission of a 227 notification times out after several transmission attempts, then the 228 client is assumed to be no longer interested and its entry is removed 229 from the list of observers. 231 While a client is in the list of observers of a resource, the goal of 232 the protocol is to keep the resource state observed by the client as 233 closely in sync with the actual state at the server as possible. 235 Becoming out of sync at times cannot be avoided: First, there is 236 always some latency between the change of the resource state and the 237 receipt of the notification. Second, messages with notifications can 238 get lost, which will cause the client assume an old state until it 239 receives a new notification. And third, the server may erroneously 240 come to the conclusion that the client is no longer interested in the 241 resource, which will cause the server to stop sending notifications 242 and the client to assume an old state until it registers its interest 243 again. 245 The protocol addresses this issue as follows: 247 o It follows a best-effort approach for sending the current 248 representation to the client after a state change: Clients should 249 see the new state after a state change as soon as possible, and 250 they should see as many states as possible. However, a client 251 cannot rely on observing every single state that a resource might 252 go through. 254 o It labels notifications with a maximum duration up to which it is 255 acceptable for the observed state and the actual state to be out 256 of sync. When the age of the notification received reaches this 257 limit, the client cannot use the enclosed representation until it 258 receives a new notification. 260 o It is designed on the principle of eventual consistency: The 261 protocol guarantees that, if the resource does not undergo a new 262 change in state, eventually all registered observers will have a 263 current representation of the latest resource state. 265 1.3. Requirements Notation 267 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 268 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 269 document are to be interpreted as described in RFC 2119 [RFC2119]. 271 2. The Observe Option 273 +-----+---+---+---+---+---------+------------+-----------+---------+ 274 | No. | C | U | N | R | Name | Format | Length | Default | 275 +-----+---+---+---+---+---------+------------+-----------+---------+ 276 | 6 | | x | - | | Observe | empty/uint | 0 B/0-3 B | (none) | 277 +-----+---+---+---+---+---------+------------+-----------+---------+ 279 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 281 Table 1: The Observe Option 283 The Observe Option, when present in a request, extends the GET method 284 so it does not only retrieve a current representation of the target 285 resource, but also requests the server to add a new entry to the list 286 of observers of the resource. The list entry consists of the client 287 endpoint and the token specified by the client in the request. The 288 value of the option in a request MUST be empty on transmission and 289 MUST be ignored on reception. 291 The Observe Option is not critical for processing the request. If 292 the server is unwilling or unable to add the client to the list of 293 observers of the target resource, then the request falls back to a 294 normal GET request. 296 In a response, the Observe Option identifies the message as a 297 notification. This implies that the server has added the client to 298 the list of observers and that it will notify the client of changes 299 to the resource state. The value of the option is a 24-bit sequence 300 number for reordering detection (see Section 3.5 and Section 4.4). 301 The sequence number is encoded in network byte order using a variable 302 number of bytes ('uint' format; see Section 3.2 of RFC XXXX 303 [I-D.ietf-core-coap]). 305 The Observe Option is not part of the cache-key: a cacheable response 306 obtained with an Observe Option in the request can be used to satisfy 307 a request without an Observe Option, and vice versa. When a stored 308 response with an Observe Option is used to satisfy a normal GET 309 request, the option MUST be removed before the response is returned 310 to the client. 312 3. Client-side Requirements 314 3.1. Request 316 A client can register its interest in a resource by issuing a GET 317 request that includes an empty Observe Option. If the server returns 318 a 2.xx response that includes an Observe Option as well, the server 319 has added the client successfully to the list of observers of the 320 target resource and the client will be notified of changes to the 321 resource state. 323 3.2. Notifications 325 Notifications are additional responses sent by the server in reply to 326 the GET request. Each notification includes the token specified by 327 the client in the GET request, an Observe Option with a sequence 328 number for reordering detection (see Section 3.5) and a payload in 329 the same Content-Format as the initial response. 331 Notifications have a 2.05 (Content) response code, or a 2.03 (Valid) 332 response code if the client included one or more ETag Options in the 333 request (see Section 3.3). In the event that the resource changes in 334 a way that would cause a normal GET request at that time to return a 335 non-2.xx response (for example, when the resource is deleted), the 336 server sends a notification with an appropriate response code (such 337 as 4.04 Not Found) and removes the client from the list of observers. 339 3.3. Caching 341 As notifications are just additional responses to a GET request, 342 notifications partake in caching as defined in Section 5.6 of RFC 343 XXXX [I-D.ietf-core-coap]. Both the freshness model and the 344 validation model are supported. 346 3.3.1. Freshness 348 A client MAY store a notification like a response in its cache and 349 use a stored notification that is fresh without contacting the 350 server. Like a response, a notification is considered fresh while 351 its age is not greater than the value indicated by the Max-Age Option 352 and no newer notification/response has been received. 354 The server will do its best to keep the resource state observed by 355 the client as closely in sync with the actual state as possible. 356 However, a client cannot rely on observing every single state that a 357 resource might go through. For example, if the network is congested 358 or the state changes more frequently than the network can handle, the 359 server can skip notifications for any number of intermediate states. 361 The server uses the Max-Age Option to indicate an age up to which it 362 is acceptable that the observed state and the actual state are 363 inconsistent. If the age of the latest notification becomes greater 364 than its indicated Max-Age, then the client MUST NOT use the enclosed 365 representation unless it is validated. 367 3.3.2. Validation 369 When a client has one or more notifications stored in its cache for a 370 resource, it can use the ETag Option in the GET request to give the 371 server an opportunity to select a stored notification to be used. 373 The client MAY include an ETag Option for each stored response that 374 is applicable in the GET request. Whenever the observed resource 375 changes to a representation identified by one of the ETag Options, 376 the server can select a stored response by sending a 2.03 (Valid) 377 notification with an appropriate ETag Option instead of a 2.05 378 (Content) notification. 380 A client implementation needs to keep all candidate responses in its 381 cache until it is no longer interested in the target resource or it 382 issues a GET request with a new set of entity-tags. 384 3.4. Aggregation 386 Every successful GET request with an Observe Option yields a new, 387 independent stream of notifications. Like a fresh response can be 388 used to satisfy a request without contacting the server, the stream 389 of notifications resulting from one request can be used to satisfy 390 another request if the target resource is the same. 392 A client MUST aggregate GET requests with an Observe Option for the 393 same target resource. The target resource SHALL be identified for 394 this purpose by the request URI and all options in the request that 395 are part of the cache-key (such as the Accept Option). 397 To make sure it has a current representation, it MAY issue a GET 398 request without an Observe Option at any time. It is RECOMMENDED 399 that the client does not issue a GET request (with or without Observe 400 Option) for a resource while it still has a fresh notification/ 401 response in its cache. Additionally, the client SHOULD wait for a 402 random amount of time between 5 and 15 seconds before issuing the 403 request to avoid synchronicity with other clients. 405 3.5. Reordering 407 Messages with notifications can arrive in a different order than they 408 were sent. Since the goal is to keep the observed state as closely 409 in sync with the actual state as possible, a client MUST NOT update 410 the observed state with a notification that arrives later than a 411 newer notification. 413 For reordering detection, the server sets the value of the Observe 414 Option in each notification to the 24 least-significant bits of a 415 strictly increasing sequence number. An incoming notification is 416 newer than the newest notification received so far when one of the 417 following conditions is met: 419 (V1 < V2 and V2 - V1 < 2^23) or 420 (V1 > V2 and V1 - V2 > 2^23) or 421 (T2 > T1 + 128 seconds) 423 where V1 is the value of the Observe Option of the newest 424 notification received so far, V2 the value of the Observe Option of 425 the incoming notification, T1 a client-local timestamp of the newest 426 notification received so far, and T2 a client-local timestamp of the 427 incoming notification. 429 Design Note: The first two conditions verify that V1 is less than V2 430 in 24-bit serial number arithmetic [RFC1982]. The third condition 431 ensures that the time elapsed between the two incoming messages is 432 not so large that the difference between V1 and V2 has become 433 larger than the largest integer that it is meaningful to add to a 434 24-bit sequence number; in other words, after 128 seconds have 435 elapsed without any notification, a client does not need to check 436 the sequence numbers in order to assume an incoming notification 437 is new. 439 The client MUST specify a token in its GET request that is currently 440 not in use for the client/server pair, as the sequence numbers 441 provide an order only among the notifications resulting from the same 442 request. 444 3.6. Transmission 446 A notification can be confirmable or non-confirmable, i.e., be sent 447 in a confirmable or a non-confirmable message. The message type used 448 is independent from the type used for the request or for any previous 449 notification. 451 If a client does not recognize the token in a confirmable 452 notification, it MUST NOT acknowledge the message and SHOULD reject 453 it with a Reset message; otherwise, the client MUST acknowledge the 454 message as usual. In the case of a non-confirmable notification, 455 rejecting the message with a Reset message is OPTIONAL. 457 An acknowledgement message signals to the server that the client is 458 alive and interested in receiving further notifications; if the 459 server does not receive an acknowledgement in reply to a confirmable 460 notification, it will assume that the client is no longer interested 461 and will eventually remove the associated entry from the list of 462 observers. 464 3.7. Cancellation 466 A client that is no longer interested in receiving notifications for 467 a resource can simply reject the next notification with a Reset 468 message. In the case of a confirmable notification, the server will 469 then remove the associated entry from the list of observers of this 470 resource. In the case of a non-confirmable notification, the server 471 may (but is not required to) remove the list entry. So the client 472 may have to wait for a confirmable notification if the servers seems 473 to ignore the Reset messages that the client sends to reject non- 474 confirmable notifications. 476 4. Server-side Requirements 478 4.1. Request 480 A GET request that includes an Observe Option requests the server not 481 only to return a current representation of the target resource, but 482 also to add a new entry to the list of observers of that resource. 483 The list entry consists of the client endpoint and the token 484 specified by the client in the request. If a client sends multiple 485 requests, each request creates a new entry in the list. 487 Upon success, the server MUST return a current representation of the 488 resource and MUST notify the client of subsequent changes to the 489 resource state for each entry of the client in the list of observers. 491 A server that is unable or unwilling to add the client to the list of 492 observers of the target resource MAY silently ignore the Observe 493 Option and process the GET request as usual. The resulting response 494 MUST NOT include an Observe Option, the absence of which signals to 495 the client that it will not be notified of changes to the resource 496 and, e.g., needs to poll the resource for its state instead. 498 4.2. Notifications 500 A client is notified of changes to the resource state by additional 501 responses sent by the server in reply to the GET request. Each such 502 notification response (including the initial response) MUST include 503 an Observe Option and MUST echo the token specified by the client in 504 the GET request. If there are multiple entries in the list of 505 observers, the order in which the clients are notified is not 506 defined; the server is free to use any method to determine the order. 508 A notification SHOULD have a 2.05 (Content) or 2.03 (Valid) response 509 code. However, in the event that the state of a resource changes in 510 a way that would cause a normal GET request at that time to return a 511 non-2.xx response (for example, when the resource is deleted), the 512 server SHOULD notify the client by sending a notification with an 513 appropriate response code (such as 4.04 Not Found) and MUST remove 514 the client from the list of observers of the resource. 516 The Content-Format used in a notification MUST be the same as the one 517 used in the initial response to the GET request. If the server is 518 unable to continue sending notifications in this Content-Format, it 519 SHOULD send a notification with a 4.06 (Not Acceptable) response code 520 and MUST remove the client from the list of observers of the 521 resource. 523 A non-2.xx notification MUST NOT include an Observe Option. 525 4.3. Caching 527 As notifications are just additional responses sent by the server, 528 they are subject to caching as defined in Section 5.6 of RFC XXXX 529 [I-D.ietf-core-coap]. 531 4.3.1. Freshness 533 After returning the initial response, the server MUST try to keep the 534 returned representation current, i.e., keep the resource state 535 observed by the client as closely in sync with the actual resource 536 state as possible. 538 Since becoming out of sync at times cannot be avoided, the server 539 MUST indicate for each representation an age up to which it is 540 acceptable that the observed state and the actual state are 541 inconsistent. This age is application-dependent and MUST be 542 specified in notifications using the Max-Age Option. 544 When the resource does not change and the client has a current 545 representation, the server does not need to send a notification. 546 However, if the client does not receive a notification, it cannot 547 tell if the observed state and the actual state are still in sync. 548 Thus, when the the age of the latest notification becomes greater 549 than its indicated Max-Age, the client must assume that the states 550 have become inconsistent. The server MAY wish to prevent that by 551 sending a notification with the unchanged representation just before 552 Max-Age expires. 554 4.3.2. Validation 556 A client can include a set of entity-tags in its request using the 557 ETag Option. When a observed resource changes its state and the 558 origin server is about to send a 2.05 (Content) notification, then, 559 whenever that notification has an entity-tag in the set of entity- 560 tags specified by the client, the server MAY send a 2.03 (Valid) 561 response with an appropriate ETag Option instead. 563 4.4. Reordering 565 Because messages can get reordered, the client needs a way to 566 determine if a notification arrived later than a newer notification. 567 For this purpose, the server MUST set the value of the Observe Option 568 of each notification it sends to the 24 least-significant bits of a 569 strictly increasing sequence number. The sequence number MAY start 570 at any value and MUST NOT increase so fast that it increases by more 571 than 2^24 within less than 256 seconds. 573 The sequence number selected for a notification MUST be greater than 574 that of any preceding notification sent to the same client for the 575 same resource with the same token. The value of the Observe Option 576 MUST be current at the time of transmission; if a notification is 577 retransmitted, the server MUST update value of option to the sequence 578 number that is current at that time before sending the message. 580 Implementation Note: A simple implementation that satisfies the 581 requirements is to obtain a timestamp from a local clock. The 582 sequence number then is the timestamp in ticks, where 1 tick = 583 (256 seconds)/(2^24) = 15.26 microseconds. It is not necessary 584 that the clock reflects the current time/date or that it ticks in 585 a precisely periodical way. 587 Another valid implementation is to store a 24-bit unsigned integer 588 variable per resource and increment this variable each time the 589 resource undergoes a change of state (provided that the resource 590 changes its state less than 2^24 times in the next 256 seconds 591 after every state change). This removes the need to update the 592 value of the Observe Option on retransmission when the resource 593 state did not change. 595 Design Note: The choice of a 24-bit option value and a time span of 596 256 seconds allows for a notification rate of up to 65536 597 notifications per second. 64K ought to be enough for anybody. 599 4.5. Transmission 601 A notification can be sent in a confirmable or a non-confirmable 602 message. The message type used is typically application-dependent 603 and MAY be determined by the server for each notification 604 individually. For example, for resources that change in a somewhat 605 predictable or regular fashion, notifications can be sent in non- 606 confirmable messages; for resources that change infrequently, 607 notifications can be sent in confirmable messages. The server can 608 combine these two approaches depending on the frequency of state 609 changes and the importance of individual notifications. 611 A server MAY choose to skip sending a notification if it knows that 612 it will send another notification soon, for example, when the state 613 is changing frequently. Similarly, it MAY choose to send a 614 notification more than once. However, above all, the server MUST 615 ensure that a client in the list of observers of a resource 616 eventually observes the latest state if the resource does not undergo 617 a new change in state. For example, when state changes occur in 618 bursts, the server can skip some notifications, send the 619 notifications in non-confirmable messages, and make sure that the 620 client observes the latest state change by repeating the last 621 notification in a confirmable message when the burst is over. 623 The client's acknowledgement of a confirmable notification signals to 624 the server that the client is interested in receiving further 625 notifications. If a client rejects a confirmable notification with a 626 Reset message, the client is no longer interested and the server MUST 627 remove the associated entry from the list of observers. If the 628 client rejects a non-confirmable notification, the server MAY remove 629 the entry from the list of observers as well. (It is expected that 630 the server does remove the entry if it has the information available 631 that is needed to match the Reset message to the non-confirmable 632 notification, but the server is not required to keep this 633 information.) 635 At a minimum, the server MUST send a notification in a confirmable 636 message instead of a non-confirmable message at least every 24 hours, 637 so a client that went away or is no longer interested does not remain 638 forever in the list of observers. 640 The server MUST limit the number of confirmable notifications for 641 which an acknowledgement has not been received yet to NSTART (1 by 642 default; see Section 4.7 of RFC XXXX [I-D.ietf-core-coap]); and it 643 SHOULD NOT send more than one non-confirmable notification every 644 3 seconds on average. 646 When the state of an observed resource changes while the server is 647 still waiting for a confirmable notification to be acknowledged or 648 the 3 seconds for a non-confirmable notification to elapse, then the 649 server MUST proceed as follows: 651 1. Wait for the current transmission attempt to complete. 653 2. If the result is a Reset message or the transmission was the last 654 attempt to deliver a notification, remove the associated entry 655 from the list of observers of the observed resource. 657 3. If the entry is still in the list of observers, start to transmit 658 a new notification with a representation of the current resource 659 state. Should the resource have changed its state more than once 660 in the meantime, the notifications for the intermediate states 661 are silently skipped. 663 4. If the transmission attempt completed in step 1 timed out, 664 increment the retransmission counter and double the timeout for 665 the new transmission; otherwise, reinitialize both the 666 retransmission counter and the timeout as described in Section 667 4.2 of RFC XXXX [I-D.ietf-core-coap]. 669 5. Intermediaries 671 A client may be interested in a resource in the namespace of an 672 origin server that is reached through a chain of one or more CoAP 673 intermediaries. In this case, the client registers its interest with 674 the first intermediary towards the origin server, acting as if it was 675 communicating with the origin server itself as specified in 676 Section 3. It is the task of this intermediary to provide the client 677 with a current representation of the target resource and send 678 notifications upon changes to the target resource state, much like an 679 origin server as specified in Section 4. 681 To perform this task, the intermediary SHOULD make use of the 682 protocol specified in this document, taking the role of the client 683 and registering its own interest in the target resource with the next 684 hop towards the origin server. If the next hop does not return a 685 response with an Observe Option, the intermediary MAY resort to 686 polling the next hop or MAY itself return a response without an 687 Observe Option. 689 The communication between each pair of hops is independent; each hop 690 in the server role MUST determine individually how many notifications 691 to send, of which message type, and so on. Each hop MUST generate 692 its own values for the Observe Option, and MUST set the value of the 693 Max-Age Option according to the age of the local current 694 representation. 696 If two or more clients have registered their interest in a resource 697 with an intermediary, the intermediary MUST register itself only once 698 with the next hop and fan out the notifications it receives to all 699 registered clients. This relieves the next hop from sending the same 700 notifications multiple times and thus enables scalability. 702 An intermediary is not required to act on behalf of a client to 703 observe a resource; an intermediary MAY observe a resource, for 704 example, just to keep its own cache up to date. 706 See Appendix A.1 for examples. 708 6. Web Linking 710 A web link [RFC5988] to a resource accessible over CoAP (for example, 711 in a link-format document [RFC6690]) MAY include the target attribute 712 "obs". 714 The "obs" attribute, when present, is a hint indicating that the 715 destination of a link is useful for observation and thus, for 716 example, should have a suitable graphical representation in a user 717 interface. Note that this is only a hint; it is not a promise that 718 the Observe Option can actually be used to perform the observation. 719 A client may need to resort to polling the resource if the Observe 720 Option is not returned in the response to the GET request. 722 A value MUST NOT be given for the "obs" attribute; any present value 723 MUST be ignored by parsers. The "obs" attribute MUST NOT appear more 724 than once in a given link-value; occurrences after the first MUST be 725 ignored by parsers. 727 7. Security Considerations 729 The security considerations of RFC XXXX [I-D.ietf-core-coap] apply. 731 The considerations about amplification attacks are somewhat amplified 732 when observing resources. Without client authentication, a server 733 MUST therefore strictly limit the number of notifications that it 734 sends between receiving acknowledgements that confirm the actual 735 interest of the client in the data; i.e., any notifications sent in 736 non-confirmable messages MUST be interspersed with confirmable 737 messages. (An attacker may still spoof the acknowledgements if the 738 confirmable messages are sufficiently predictable.) 740 As with any protocol that creates state, attackers may attempt to 741 exhaust the resources that the server has available for maintaining 742 the list of observers for each resource. Servers may want to access- 743 control this creation of state. As degraded behavior, the server can 744 always fall back to processing the request as a normal GET request 745 (without an Observe Option) if it is unwilling or unable to add a 746 client to the list of observers of a resource, including if system 747 resources are exhausted or nearing exhaustion. 749 Intermediaries must be careful to ensure that notifications cannot be 750 employed to create a loop. A simple way to break any loops is to 751 employ caches for forwarding notifications in intermediaries. 753 8. IANA Considerations 755 The following entry is added to the CoAP Option Numbers registry: 757 +--------+---------+-----------+ 758 | Number | Name | Reference | 759 +--------+---------+-----------+ 760 | 6 | Observe | [RFCXXXX] | 761 +--------+---------+-----------+ 763 9. Acknowledgements 765 Carsten Bormann was an original author of this draft and is 766 acknowledged for significant contribution to this document. 768 Thanks to Daniele Alessandrelli, Jari Arkko, Peter Bigot, Angelo P. 769 Castellani, Gilbert Clark, Esko Dijk, Thomas Fossati, Brian Frank, 770 Bert Greevenbosch, Jeroen Hoebeke, Cullen Jennings, Matthias 771 Kovatsch, Salvatore Loreto, Charles Palmer, Zach Shelby, and Floris 772 Van den Abeele for helpful comments and discussions that have shaped 773 the document. 775 This work was supported in part by Klaus Tschira Foundation, Intel, 776 Cisco, and Nokia. 778 10. References 780 10.1. Normative References 782 [I-D.ietf-core-coap] 783 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 784 Application Protocol (CoAP)", draft-ietf-core-coap-18 785 (work in progress), June 2013. 787 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 788 August 1996. 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 795 10.2. Informative References 797 [GOF] Gamma, E., Helm, R., Johnson, R., and J. Vlissides, 798 "Design Patterns: Elements of Reusable Object-Oriented 799 Software", Addison-Wesley, Reading, MA, USA, 800 November 1994. 802 [REST] Fielding, R., "Architectural Styles and the Design of 803 Network-based Software Architectures", Ph.D. Dissertation, 804 University of California, Irvine, 2000, . 808 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 809 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 810 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 812 [RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes 813 to an HTTP Resource", RFC 5989, October 2010. 815 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 816 "Known Issues and Best Practices for the Use of Long 817 Polling and Streaming in Bidirectional HTTP", RFC 6202, 818 April 2011. 820 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 821 Format", RFC 6690, August 2012. 823 Appendix A. Examples 825 Observed CLIENT SERVER Actual 826 t State | | State 827 ____________ | | ____________ 828 1 | | 829 2 unknown | | 18.5 C 830 3 +----->| Header: GET 0x41011633 831 4 | GET | Token: 0x4a 832 5 | | Uri-Path: temperature 833 6 | | Observe: (empty) 834 7 | | 835 8 | | 836 9 ____________ |<-----+ Header: 2.05 0x61451633 837 10 | 2.05 | Token: 0x4a 838 11 18.5 C | | Observe: 9 839 12 | | Max-Age: 15 840 13 | | Payload: "18.5 C" 841 14 | | 842 15 | | ____________ 843 16 ____________ |<-----+ Header: 2.05 0x51457b50 844 17 | 2.05 | 19.2 C Token: 0x4a 845 18 19.2 C | | Observe: 16 846 29 | | Max-Age: 15 847 20 | | Payload: "19.2 C" 848 21 | | 850 Figure 3: A client registers and receives one notification of the 851 current state and one of a new state upon a state change 852 Observed CLIENT SERVER Actual 853 t State | | State 854 ____________ | | ____________ 855 22 | | 856 23 19.2 C | | 19.2 C 857 24 | | ____________ 858 25 | X----+ Header: 2.05 0x51457b51 859 26 | 2.05 | 19.7 C Token: 0x4a 860 27 | | Observe: 25 861 28 | | Max-Age: 15 862 29 | | Payload: "19.7 C" 863 30 | | 864 31 ____________ | | 865 32 | | 866 33 19.2 C | | 867 34 (stale) | | 868 35 | | 869 36 | | 870 37 | | 871 38 +----->| Header: GET 0x41011634 872 39 | GET | Token: 0xb2 873 40 | | Uri-Path: temperature 874 41 | | Observe: (empty) 875 42 | | 876 43 | | 877 44 ____________ |<-----+ Header: 2.05 0x61451634 878 45 | 2.05 | Token: 0xb2 879 46 19.7 C | | Observe: 44 880 47 | | Max-Age: 15 881 48 | | ETag: 0x78797a7a79 882 49 | | Payload: "19.7 C" 883 50 | | 885 Figure 4: The client re-registers after Max-Age ends 887 Observed CLIENT SERVER Actual 888 t State | | State 889 ____________ | | ____________ 890 51 | | 891 52 19.7 C | | 19.7 C 892 53 | | 893 54 | | ____________ 894 55 | crash 895 56 | 896 57 | 897 58 | 898 59 ____________ | 899 60 | 900 61 19.7 C | 901 62 (stale) | 902 63 | reboot____________ 903 64 | | 904 65 | | 20.0 C 905 66 | | 906 67 +----->| Header: GET 0x41011635 907 68 | GET | Token: 0xf9 908 69 | | Uri-Path: temperature 909 70 | | Observe: (empty) 910 71 | | ETag: 0x78797a7a79 911 72 | | 912 73 | | 913 74 ____________ |<-----+ Header: 2.05 0x61451635 914 75 | 2.05 | Token: 0xf9 915 76 20.0 C | | Observe: 74 916 77 | | Max-Age: 15 917 78 | | Payload: "20.0 C" 918 79 | | 919 80 | | ____________ 920 81 ____________ |<-----+ Header: 2.03 0x5143aa0c 921 82 | 2.03 | 19.7 C Token: 0xf9 922 83 19.7 C | | Observe: 81 923 84 | | ETag: 0x78797a7a79 924 85 | | Max-Age: 15 925 86 | | 927 Figure 5: The client re-registers and gives the server the 928 opportunity to select a stored response 930 Observed CLIENT SERVER Actual 931 t State | | State 932 ____________ | | ____________ 933 87 | | 934 88 19.7 C | | 19.7 C 935 89 | | 936 90 | | ____________ 937 91 ____________ |<-----+ Header: 2.05 0x4145aa0f 938 92 | 2.05 | 19.3 C Token: 0xf9 939 93 19.3 C | | Observe: 91 940 94 | | Max-Age: 15 941 95 | | Payload: "19.3 C" 942 96 | | 943 97 | | 944 98 +- - ->| Header: 0x7000aa0f 945 99 | | 946 100 | | 947 101 | | 948 102 | | ____________ 949 103 | | 950 104 | | 19.0 C 951 105 | | 952 106 ____________ | | 953 107 | | 954 108 19.3 C | | 955 109 (stale) | | 956 110 | | 958 Figure 6: The client rejects a notification and thereby cancels the 959 observation 961 A.1. Proxying 963 CLIENT PROXY SERVER 964 | | | 965 | +----->| Header: GET 0x41015fb8 966 | | GET | Token: 0x1a 967 | | | Uri-Host: sensor.example 968 | | | Uri-Path: status 969 | | | Observe: (empty) 970 | | | 971 | |<-----+ Header: 2.05 0x61455fb8 972 | | 2.05 | Token: 0x1a 973 | | | Observe: 42 974 | | | Max-Age: 60 975 | | | Payload: "ready" 976 | | | 977 +----->| | Header: GET 0x41011633 978 | GET | | Token: 0x9a 979 | | | Proxy-Uri: coap://sensor.example/status 980 | | | 981 |<-----+ | Header: 2.05 0x61451633 982 | 2.05 | | Token: 0x9a 983 | | | Max-Age: 53 984 | | | Payload: "ready" 985 | | | 986 | |<-----+ Header: 2.05 0x514505fc0 987 | | 2.05 | Token: 0x1a 988 | | | Observe: 135 989 | | | Max-Age: 60 990 | | | Payload: "busy" 991 | | | 992 +----->| | Header: GET 0x41011634 993 | GET | | Token: 0x9b 994 | | | Proxy-Uri: coap://sensor.example/status 995 | | | 996 |<-----+ | Header: 2.05 0x61451634 997 | 2.05 | | Token: 0x9b 998 | | | Max-Age: 49 999 | | | Payload: "busy" 1000 | | | 1002 Figure 7: A proxy observes a resource to keep its cache up to date 1004 CLIENT PROXY SERVER 1005 | | | 1006 +----->| | Header: GET 0x41011635 1007 | GET | | Token: 0x6a 1008 | | | Proxy-Uri: coap://sensor.example/status 1009 | | | Observe: (empty) 1010 | | | 1011 |<- - -+ | Header: 0x60001635 1012 | | | 1013 | +----->| Header: GET 0x4101af90 1014 | | GET | Token: 0xaa 1015 | | | Uri-Host: sensor.example 1016 | | | Uri-Path: status 1017 | | | Observe: (empty) 1018 | | | 1019 | |<-----+ Header: 2.05 0x6145af90 1020 | | 2.05 | Token: 0xaa 1021 | | | Observe: 67 1022 | | | Max-Age: 60 1023 | | | Payload: "ready" 1024 | | | 1025 |<-----+ | Header: 2.05 0x4145af94 1026 | 2.05 | | Token: 0x6a 1027 | | | Observe: 17346 1028 | | | Max-Age: 60 1029 | | | Payload: "ready" 1030 | | | 1031 +- - ->| | Header: 0x6000af94 1032 | | | 1033 | |<-----+ Header: 2.05 0x51455a20 1034 | | 2.05 | Token: 0xaa 1035 | | | Observe: 157 1036 | | | Max-Age: 60 1037 | | | Payload: "busy" 1038 | | | 1039 |<-----+ | Header: 2.05 0x5145af9b 1040 | 2.05 | | Token: 0x6a 1041 | | | Observe: 17436 1042 | | | Max-Age: 60 1043 | | | Payload: "busy" 1044 | | | 1046 Figure 8: A client observes a resource through a proxy 1048 Appendix B. Modeling Resources to Tailor Notifications 1050 A server may want to provide notifications that respond to very 1051 specific conditions on some state. This is best done by modeling the 1052 resources that the server exposes according to these needs. 1054 For example, for a CoAP server with an attached temperature sensor, 1056 o the server could, in the simplest form, expose a resource 1057 that changes its state every second to 1058 the current temperature measured by the sensor; 1060 o the server could, however, also expose a resource 1061 that changes its state to "cold" 1062 when it's warm and the temperature drops below a preconfigured 1063 threshold, and to "warm" when it's cold and the temperature 1064 exceeds a second, slightly higher threshold; 1066 o the server could expose a parameterized resource 1067 that changes its 1068 state every second to the current temperature if the sensor 1069 reading exceeds the specified parameter value, and that changes 1070 its state to "OK" when the temperature drops below; or 1072 o the server could expose a parameterized resource 1073 that accepts expressions of arbitrary 1075 complexity and changes its state accordingly. 1077 In any case, the client is notified about the current state of the 1078 resource whenever the state of the appropriately modeled resource 1079 changes. By designing resources that change their state on certain 1080 conditions, it is possible to notify the client only when these 1081 conditions occur instead of continuously supplying it with 1082 information it doesn't need. 1084 By parameterizing resources, this is not limited to conditions 1085 defined by the server, but can be extended to arbitrarily complex 1086 conditions defined by the client. Thus, the server designer can 1087 choose exactly the right level of complexity for the application 1088 envisioned and devices used, and is not constrained to a "one size 1089 fits all" mechanism built into the protocol. 1091 Appendix C. Changelog 1093 (To be removed by RFC editor before publication.) 1094 Changes from ietf-08 to ietf-09: 1096 o Removed the side effects of requests on existing observations. 1097 This includes removing that 1099 * the client can use a GET request to cancel an observation; 1101 * the server updates the entry in the list of observers instead 1102 of adding a new entry if the client is already present (#258, 1103 #281). 1105 o Clarified that a resource (and hence an observation relationship) 1106 is identified by the request options that are part of the Cache- 1107 Key (#258). 1109 o Clarified that a non-2.xx notification MUST NOT include an Observe 1110 Option. 1112 o Moved block-wise transfer of notifications to [I-D.ietf-core- 1113 block]. 1115 Changes from ietf-07 to ietf-08: 1117 o Expanded text on transmitting a notification while a previous 1118 transmission is pending (#242). 1120 o Changed reordering detection to use a fixed time span of 128 1121 seconds instead of EXCHANGE_LIFETIME (#276). 1123 o Removed the use of the freshness model to determine if the client 1124 is still on the list of observers. This includes removing that 1126 * the client assumes that it has been removed from the list of 1127 observers when Max-Age ends; 1129 * the server sets the Max-Age Option of a notification to a value 1130 that indicates when the server will send the next notification; 1132 * the server uses a number of retransmit attempts such that 1133 removing a client from the list of observers before Max-Age 1134 ends is avoided (#235); 1136 * the server may remove the client from all lists of observers 1137 when the transmission of a confirmable notification ultimately 1138 times out. 1140 o Changed that an unrecognized critical option in a request must 1141 actually have no effect on the state of any observation 1142 relationship to any resource, as the option could lead to a 1143 different target resource. 1145 o Clarified that client implementations must be prepared to receive 1146 each notification equally as a confirmable or a non-confirmable 1147 message, regardless of the message type of the request and of any 1148 previous notification. 1150 o Added a requirement for sending a confirmable notification at 1151 least every 24 hours before continuing with non-confirmable 1152 notifications (#221). 1154 o Added congestion control considerations from [I-D.bormann-core- 1155 congestion-control-02]. 1157 o Recommended that the client waits for a randomized time after the 1158 freshness of the latest notification expired before re- 1159 registering. This prevents that multiple clients observing a 1160 resource perform a GET request at the same time when the need to 1161 re-register arises. 1163 o Changed reordering detection from 'MAY' to 'SHOULD', as the goal 1164 of the protocol (to keep the observed state as closely in sync 1165 with the actual state as possible) is not optional. 1167 o Fixed the length of the Observe (3 bytes) in the table in 1168 Section 2. 1170 o Replaced the 'x' in the No-Cache-Key column in the table in 1171 Section 2 with a '-', as the Observe Option doesn't have the No- 1172 Cache-Key flag set, even though it is not part of the cache key. 1174 o Updated examples. 1176 Changes from ietf-06 to ietf-07: 1178 o Moved to 24-bit sequence numbers to allow for up to 15000 1179 notifications per second per client and resource (#217). 1181 o Re-numbered option number to use Unsafe/Safe and Cache-Key 1182 compliant numbers (#241). 1184 o Clarified how to react to a Reset message that is sent in reply to 1185 a non-confirmable notification (#225). 1187 o Clarified the semantics of the "obs" link target attribute (#236). 1189 Changes from ietf-05 to ietf-06: 1191 o Improved abstract and introduction to say that the protocol is 1192 about best effort and eventual consistency (#219). 1194 o Clarified that the value of the Observe Option in a request must 1195 have zero length. 1197 o Added requirement that the sequence number must be updated each 1198 time a server retransmits a notification. 1200 o Clarified that a server must remove a client from the list of 1201 observers when it receives a GET request with an unrecognized 1202 critical option. 1204 o Updated the text to use the endpoint concept from 1205 [I-D.ietf-core-coap] (#224). 1207 o Improved the reordering text (#223). 1209 Changes from ietf-04 to ietf-05: 1211 o Recommended that a client does not re-register while a new 1212 notification from the server is still likely to arrive. This is 1213 to avoid that the request of the client and the last notification 1214 after max-age cross over each other (#174). 1216 o Relaxed requirements when sending a Reset message in reply to non- 1217 confirmable notifications. 1219 o Added an implementation note about careless GET requests (#184). 1221 o Updated examples. 1223 Changes from ietf-03 to ietf-04: 1225 o Removed the "Max-OFE" Option. 1227 o Allowed a Reset message in reply to non-confirmable notifications. 1229 o Added a section on cancellation. 1231 o Updated examples. 1233 Changes from ietf-02 to ietf-03: 1235 o Separated client-side and server-side requirements. 1237 o Fixed uncertainty if client is still on the list of observers by 1238 introducing a liveliness model based on Max-Age and a new option 1239 called "Max-OFE" (#174). 1241 o Simplified the text on message reordering (#129). 1243 o Clarified requirements for intermediaries. 1245 o Clarified the combination of blockwise transfers with 1246 notifications (#172). 1248 o Updated examples to show how the state observed by the client 1249 becomes eventually consistent with the actual state on the server. 1251 o Added examples for parameterization of observable resource. 1253 Changes from ietf-01 to ietf-02: 1255 o Removed the requirement of periodic refreshing (#126). 1257 o The new "Observe" Option replaces the "Lifetime" Option. 1259 o Introduced a new mechanism to detect message reordering. 1261 o Changed 2.00 (OK) notifications to 2.05 (Content) notifications. 1263 Changes from ietf-00 to ietf-01: 1265 o Changed terminology from "subscriptions" to "observation 1266 relationships" (#33). 1268 o Changed the name of the option to "Lifetime". 1270 o Clarified establishment of observation relationships. 1272 o Clarified that an observation is only identified by the URI of the 1273 observed resource and the identity of the client (#66). 1275 o Clarified rules for establishing observation relationships (#68). 1277 o Clarified conditions under which an observation relationship is 1278 terminated. 1280 o Added explanation on how clients can terminate an observation 1281 relationship before the lifetime ends (#34). 1283 o Clarified that the overriding objective for notifications is 1284 eventual consistency of the actual and the observed state (#67). 1286 o Specified how a server needs to deal with clients not 1287 acknowledging confirmable messages carrying notifications (#69). 1289 o Added a mechanism to detect message reordering (#35). 1291 o Added an explanation of how notifications can be cached, 1292 supporting both the freshness and the validation model (#39, #64). 1294 o Clarified that non-GET requests do not affect observation 1295 relationships, and that GET requests without "Lifetime" Option 1296 affecting relationships is by design (#65). 1298 o Described interaction with blockwise transfers (#36). 1300 o Added Resource Discovery section (#99). 1302 o Added IANA Considerations. 1304 o Added Security Considerations (#40). 1306 o Added examples (#38). 1308 Author's Address 1310 Klaus Hartke 1311 Universitaet Bremen TZI 1312 Postfach 330440 1313 Bremen D-28359 1314 Germany 1316 Phone: +49-421-218-63905 1317 Email: hartke@tzi.org