idnits 2.17.1 draft-hartke-coap-observe-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2010) is 5058 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 806, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Hartke 3 Internet-Draft C. Bormann 4 Intended status: Informational Universitaet Bremen TZI 5 Expires: December 23, 2010 June 21, 2010 7 Observing Resources in CoAP 8 draft-hartke-coap-observe-00 10 Abstract 12 The state of a resource can change over time. We want to give 13 clients of the CoRE WG CoAP protocol the ability to observe this 14 change. This short I-D provides an example design for such an 15 addition to CoAP, in order to be able to discuss the design 16 alternatives in specific terms. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 23, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Design Pattern . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. The Design . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.1. State . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 3.2. Subscription Lifetime . . . . . . . . . . . . . . . . . . 9 59 3.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 3.3.1. Requests . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.3.2. Replies . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.3.3. Notifications . . . . . . . . . . . . . . . . . . . . 11 63 4. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 12 64 4.1. Subscribing to a resource . . . . . . . . . . . . . . . . 12 65 4.2. Notifying of state changes . . . . . . . . . . . . . . . . 13 66 4.3. Unsubscribing from a resource . . . . . . . . . . . . . . 14 67 4.4. Retrieving resource state . . . . . . . . . . . . . . . . 15 68 4.5. Changing resource state . . . . . . . . . . . . . . . . . 16 69 4.6. Deleting a resource . . . . . . . . . . . . . . . . . . . 16 70 5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 6. Identifying notifications and subscriptions . . . . . . . . . 19 72 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Introduction 80 The state of a resource can change over time. We want to give CoAP 81 [I-D.ietf-core-coap] clients the ability to observe this change. 83 This short I-D provides an example design for such an addition to 84 CoAP, in order to be able to discuss the design alternatives in 85 specific terms. 87 1.1. Design Pattern 89 Many designs are possible for the observe capability of CoAP. So 90 that we don't end up with a random, arbitrary design, we base our 91 considerations on the well-known subject/observer design pattern. In 92 this pattern, an object, called the subject, maintains a list of 93 interested parties, called observers, and notifies them automatically 94 of any state changes. 96 There are a number of variants of that design pattern. We like one 97 that explicitly considers the way the evolution of the resource state 98 might end [DUAL]. In detail, this variant of the design pattern 99 consists of the following elements: 101 o A _subject_, which sends notifications to observers. It has a 102 single method, SUBSCRIBE, which is called by observers that wish 103 to receive notifications from the subject. 105 o An _observer_, which receives notifications from a subject. It 106 has three methods: YIELD, which supplies the observer with new or 107 current information; THROW, which informs the observer that the 108 subject experienced an error condition; and BREAK, which indicates 109 that the subject has finished sending notifications. The grammar 110 of notifications to be expected over time therefore is: 112 YIELD* ( BREAK | THROW )? 114 o A _subscription_, which represents the interest of an observer in 115 a subject. It has a single method, UNSUBSCRIBE, which enables the 116 subject to unsubscribe observers when notification has finished. 117 Observers receive a reference to the subscription from the 118 SUBSCRIBE method, so they can also call the UNSUBSCRIBE method to 119 unsubscribe before the subject has finished sending notifications. 121 In this document, we describe an architecture and a protocol design 122 that realizes a meaningful rendition of this design pattern within 123 the REST-based [REST] environment of CoAP. 125 1.2. Architecture 127 We interpret resources as the _subjects_ of the subject/observer 128 pattern. The _subscription_ causes the subject to continuously 129 supply an _observer_ with the state of the resource: once upon 130 subscription and then whenever the state of the resource changes. We 131 call a CoAP node offering a resource _server_, and a CoAP node 132 subscribing an observer to a resource _client_. As with the existing 133 REST methods, this architecture is about exchanging representations 134 of resources, not about the messages (or method calls). 136 The design is REST-based, as it maintains REST's uniform interface 137 and its four interface constraints ([REST], section 5.1.5): 139 o Identification of resources by the uniform mechanism of URIs 140 [RFC3986]; 142 o Resource manipulation through the exchange of resource state 143 representations; 145 o Self-describing messages (potentially with multiple representation 146 formats); 148 o Hypermedia as the engine of application state: A server 149 premediates application state transitions by providing links in 150 resources.; 152 While this is not a necessary implication of the design described 153 here, the assumption is that the subscription itself is modeled on 154 the level of conversation state, not as a resource by itself. (This, 155 of course, does not imply that there can't be resources that help 156 nodes decide whether to create subscriptions, but these are 157 application-specific and outside the scope of CoAP.) 159 2. Requirements 161 The requirements for implementing the subject/observer design pattern 162 over UDP stem largely from the the fact that UDP is an unreliable, 163 connectionless transport. This means that method calls must be 164 expressed as messages, that preparation must be taken for the case 165 that messages arrive out of order, appear duplicated, or go missing 166 without notice, and that the transport keeps no state between 167 messages that can be utilized. 169 The detailed requirements that follow from this are: 171 o An invocation of the SUBSCRIBE method on an observable resource is 172 implemented by sending a message (a subscription request) from the 173 subscribing client to the server that offers the resource. 175 The client must be able to determine if a subscription request was 176 received by the server, and, if not, must be able to retransmit 177 the request. 179 The server must acknowledge the subscription request, and must be 180 prepared to receive duplicated subscription requests. 182 Since subscribing can be made idempotent (Section 6), the server 183 need not be able to detect a duplicated subscription request as 184 such. 186 The client must be able to relate the acknowledgement to the 187 subscription request. 189 o The usual considerations for retrieving the representation of a 190 resource in a REST-based protocol apply, e.g.: 192 A subscribing client must be able to influence the representation 193 format in which the server supplies the resource state to the 194 client. 196 o Upon subscription, an observer must be supplied with the current 197 state of the resource in the requested format. 199 If the observer cannot be supplied with the current state (for 200 example, because the resource does not exist, the state cannot be 201 represented in the requested format, the client lacks 202 authorization, or a general error condition occurred), the server 203 must inform the client of the error condition. 205 For efficiency, this initial notification may be sent within the 206 same datagram that acknowledges the subscription request. 208 The initial notification might not include the actual 209 representation (e.g., take the form of a "304 not modified") if 210 the client already has a valid representation of the resource. 211 The client should be able to supply information (e.g., Etags or a 212 modification date) to enable the server to make this 213 determination. 215 o To take advantage of the multicast capabilities of the transport, 216 it should be possible to subscribe a UDP multicast group to a 217 resource. In contrast to subscribing multiple clients 218 individually to the resource, the server in this case must treat 219 the multicast group as a single observer. 221 o For robustness, a subscription has to be maintained through 222 periodic refreshing. If a subscription is not refreshed, its 223 lifetime must end after a certain duration that is negotiated as 224 part of the message exchange that implements the SUBSCRIBE method 225 call. 227 So a subscribing client must be able to specify a subscription 228 lifetime duration in a subscription request. A server must be 229 able to return the negotiated subscription lifetime duration back 230 to the client. 232 Since the client is responsible for taking care of the 233 subscription, refreshing a subscription must be implemented by 234 sending a message (a subscription refresh request) from the 235 subscribed client to the server. 237 The client must be able to determine if a subscription refresh 238 request was received by the server, and, if not, must be able to 239 retransmit the request. 241 The server must acknowledge the request. It must be prepared to 242 receive duplicated requests. It must be able to relate a refresh 243 request to a subscription. 245 The client must be able to relate the acknowledgement to the 246 subscription refresh request. 248 The server must be prepared for a refresh request to arrive after 249 the subscription expired. In this case, the subscription refresh 250 request is treated the same as a subscription request, since the 251 client expressed the desire to continue being subscribed to the 252 resource. 254 o For notifications, the equivalent of an invocation of the YIELD, 255 BREAK or THROW method on an observer must be implemented by 256 sending a notification message from the server offering the 257 resource to the subscribed client. 259 The subscribed client must be able to relate a notification 260 message to a subscription and/or to a resource (see also 261 Section 6). 263 It is not a requirement that a subscribed client receives every 264 single notification messages sent by a server, or that the server 265 sends a notification message for every single state change. 266 However, the state observed by an observer must eventually become 267 consistent with the actual state of the observed resource. 269 o The representation format used during the lifetime of a 270 subscription must not change. If the server is unable to continue 271 notifying a client in the requested representation format, it must 272 invoke the THROW method on the observer. 274 o A server must not send any further notification messages after 275 sending a notification message that denotes a BREAK or THROW. 277 However, a client must be prepared to receive notification 278 messages after receiving such a notification message. (In this 279 case, it discards the excessive notification messages.) 281 o For robustness, a server can request the acknowledgement of a 282 notification message from a client. (For example, in order to 283 check if the client is still there, or to make sure that an 284 observer observes a particular resource state.) Such a 285 notification is called a _confirmable_ notification message. 287 A server must be able to determine if a confirmable notification 288 message was received by the client, and, if not, must retransmit 289 the message. 291 If the client cannot relate the confirmable notification message 292 to a subscription, it must reject the message. Otherwise, it must 293 acknowledge the message. 295 The server must be able to relate the acknowledgement or rejection 296 to the confirmable notification message. 298 There is no support for multicasting confirmable notification 299 messages. 301 o To end a subscription before the lifetime of the subscription 302 expires (UNSUSBCRIBE method), a message (an 'unsubscribe' request) 303 can be sent from the subscribed client to the server that 304 maintains the subscription. 306 The client must be able to determine if an 'unsubscribe' request 307 was indeed received by the server, and, if not, must be able to 308 retransmit the request. 310 The server must acknowledge the 'unsubscribe' request, and must be 311 prepared to receive duplicated requests (which also need to be 312 acknowledged). 314 The client must be able to relate the acknowledgement to the 315 request. 317 Note that, in a REST-based environment, all these message exchanges 318 should also work correctly through proxies. 320 3. The Design 322 3.1. State 324 The state required on nodes as indicated by the requirements, can be 325 summarized as follows: 327 o Nodes that send requests must keep track of pending requests. 328 (For non-idempotent requests, the node that receives the request 329 also must retain state to deduplicate requests.) 331 o A server offering a resource must keep track of the observers of 332 the resource. Similarly, a proxy must keep track of the observers 333 that observe a resource through that proxy. 335 o Due to the initial notification of an observer upon subscription, 336 the server must also keep track the resource state itself. (It 337 cannot just notify all observers when the state changes and then 338 immediately forget the state.) 340 o A client subscribed to a resource may have to keep track of the 341 subscriptions to the resource in order to be able to relate 342 notifications to the subscription and in order to be able to 343 refresh the subscription before the subscription lifetime ends 344 (Section 6). 346 o A client (or a proxy) may optionally keep a cache of resource 347 states. 349 3.2. Subscription Lifetime 351 To summarize, the lifetime of a subscription begins with a 352 subscription request, and it ends when 354 o the subscription lifetime expires (as defined by the subscription 355 duration option in the subscription request), 357 o the client unsubscribes from the resource, 359 o the client rejects a request related to a subscription, 361 o an error condition related to a subscription occurred, or 363 o the observed resource has finished sending notifications. 365 A client can extend the lifetime of a subscription before its end by 366 sending a subscription refresh request. 368 3.3. Messages 370 The following message types and elements can be gathered from the 371 requirements. 373 3.3.1. Requests 375 Requests are messages that need to be acknowledged by the recipient. 376 As with other request in CoAP, they are retransmitted by the sender 377 using an exponential back-off delay until the acknowledgment is 378 received. 380 The request message types as indicated by the requirements can be 381 summarized as follows: 383 o A SUBSCRIBE request creates a new subscription or refreshes an 384 existing subscription. 386 o An UNSUBSCRIBE request ends an existing subscription. 388 To put this into perspective, the existing GET, PUT, POST and DELETE 389 messages have request semantics as well. 391 o A GET request retrieves a representation of the current resource 392 state. 394 o A PUT request provides a new resource state in some representation 395 format. 397 o A POST request creates or extends a resource. 399 o A DELETE request deletes a resource. 401 A request message includes a _transaction identifier_ which allows 402 the recipient to detect duplicated requests and, by inclusion of the 403 transaction identifier in the acknowledgement to the request, enables 404 the sender to relate the acknowledgement to the request. 406 3.3.2. Replies 408 Replies are messages that are sent in reply to a request. They carry 409 the aforementioned transaction identifier. 411 The reply messages types as indicated by the requirements can be 412 summarized as follows: 414 o An ACK reply indicates an acknowledgement of a request. 416 o A RST reply indicates the rejection of a request. 418 (Responses in CoAP are replies that may carry a resource 419 representation.) 421 3.3.3. Notifications 423 Matching the methods of an observer, the notification message types 424 can be summarized as follows: 426 o A YIELD notification supplies the subscribed client with the state 427 of a resource in some representation. 429 o A BREAK notification indicates that the observed resource has 430 finished sending notifications. 432 o A THROW notification informs the subscribed client of an error 433 condition. 435 Each of these notification messages can be sent as a message that 436 does not require acknowledgement, as a confirmable message that does 437 require acknowledgement (which makes it a request), or (in case of an 438 initial notification) piggy-backed with the ACK message that is sent 439 in reply to the subscription request. 441 4. Message Exchanges 443 The following message exchanges can be derived from the requirements. 445 4.1. Subscribing to a resource 447 Client Server Client Server 448 | | | | 449 | SUBSCRIBE | | SUBSCRIBE | 450 +---------------->| +---------------->| 451 | | | | 452 | ACK+YIELD | | ACK | 453 |<----------------+ or |<----------------+ 454 | | | | 455 ... Time Passes ... 456 | | 457 | YIELD [c?] | 458 |<----------------+ 459 | | 460 | ACK (if c) | 461 +---------------->| 462 | | 464 Figure 1 466 The workflow for subscribing an observer to an observable resource or 467 refreshing a subscription is as follows: 469 1. The subscribing client sends a SUBSCRIBE request to the server 470 that is offering the observable resource. The subscription 471 request includes the identifier of a representation format in 472 which the notifications have to be sent, specifies a subscription 473 lifetime duration and optionally indicates states cached by the 474 client (by Etag or Date) and other information that might be 475 relayed in a GET request. 477 2. The server creates a new subscription if no subscription exists 478 (Section 6), and changes the lifetime duration of the 479 subscription to the duration specified in the subscription 480 request, or any shorter duration if it so desires. The server 481 then acknowledges the request and indicates the actual lifetime 482 with a ACK reply (or with a ACK+THROW, ACK+BREAK or ACK+YIELD 483 reply as described in the next step). 485 3. The server performs one of the following actions: 487 * If an error occurred, the server sends a THROW notification 488 (either as THROW request or as ACK+THROW reply to the 489 SUBSCRIBE request). 491 * If the resource has finished sending notifications, the server 492 sends a BREAK notification (either as BREAK request or as ACK+ 493 BREAK reply to the SUBSCRIBE request). 495 * Otherwise, the server supplies the observer with the current 496 resource state in the requested representation format, or 497 indicates that the cached state is the current state (either 498 as YIELD request or as ACK+YIELD reply to the SUBSCRIBE 499 request). 501 If the server sends a THROW, BREAK or YIELD request, the request 502 is treated like any other notification (i.e. the client must 503 acknowledge it if the message is marked as confirmable, etc.). 505 4. If the client does not receive the ACK, ACK+THROW, ACK+BREAK or 506 ACK+YIELD reply within a certain time frame (because the request 507 or the reply went missing), the client retransmits the SUBSCRIBE 508 request using the same request identifier. 510 4.2. Notifying of state changes 512 Client Server Client Server 513 | | | | 514 | YIELD | | YIELD [c] | 515 |<----------------+ or |<----------------+ 516 | | | | 517 | ACK | 518 +---------------->| 519 | | 521 Figure 2 523 The workflow for notifying an observer of a state change is as 524 follows: 526 1. The server performs one of the following actions: 528 * If the resource experienced an error condition, the server 529 sends a THROW request to the client. 531 * If the resource has finished sending notifications, the server 532 sends a BREAK request to the client. 534 * If the state of the resource changed, the server sends a YIELD 535 request with the current resource state in the requested 536 representation format. 538 The server may or may not mark the request sent as confirmable 539 ("[c]"). The server marks a request as confirmable because it 540 wants to check if the observer is still alive, or because there 541 might not be another notification in the near future and the 542 confirmation process is therefore needed to ensure eventual 543 consistency. 545 2. If the request is marked as confirmable, the subscribed client 546 performs one of the following actions: 548 * If the notification cannot be related to a subscription, the 549 client sends a RST reply. 551 * Otherwise, the client sends an ACK reply. 553 3. If the request is marked as confirmable and the server does not 554 receive the ACK reply or the RST reply within a given time frame, 555 the server retransmits the request using the same transaction 556 identifier. 558 (Note that it is entirely the decision of the server whether to 559 request an acknowledgement by marking the request as confirmable - it 560 might want to employ different strategies to determine this, e.g. 561 based on frequency of change, management of state etc.) 563 4.3. Unsubscribing from a resource 565 Client Server 566 | | 567 | UNSUBSCRIBE | 568 +---------------->| 569 | | 570 | ACK | 571 |<----------------+ 572 | | 574 Figure 3 576 The workflow for unsubscribing an observer from an observed resource 577 is as follows: 579 1. The subscribed client sends an UNSUBSCRIBE request to the server 580 offering the observed resource. 582 2. The server changes the lifetime duration of the subscription to 583 zero, which immediately expires the subscription. The server 584 then acknowledges the request with a ACK reply. 586 3. If the client does not receive the ACK reply within a certain 587 time frame, the client retransmits the UNSUBSCRIBE request using 588 the same request identifier. 590 Note that an subscribed client can also unsubscribe by "forgetting" 591 the subscription and subsequently replying with a RST to the next 592 notification. (In order to allow sending that RST even for messages 593 that are not marked as confirmable, an otherwise redundant 594 transaction identifier is sent in all messages.) 596 (An UNSUBSCRIBE message might be implemented as a SUBSCRIBE message 597 with a lifetime duration of 0, but this has some unintended 598 consequences. See Section 6.) 600 4.4. Retrieving resource state 602 Note that a GET request matches closely the first steps of 603 subscribing, except that the GET request does not create or update an 604 subscription. (A GET request is likely to mark the yield as 605 confirmable.) 607 The second form in Figure 4 solves the long-poll case. 609 Client Server Client Server 610 | | | | 611 | GET | | GET | 612 +---------------->| +---------------->| 613 | | | | 614 | ACK+YIELD | | ACK | 615 |<----------------+ or |<----------------+ 616 | | | | 617 ... Time Passes ... 618 | | 619 | YIELD [c] | 620 |<----------------+ 621 | | 622 | ACK | 623 +---------------->| 624 | | 626 Figure 4 628 4.5. Changing resource state 630 Client Server Client Server 631 | | | | 632 | PUT | | PUT | 633 +---------------->| +---------------->| 634 | | | | 635 | ACK+BREAK | | ACK | 636 |<----------------+ or |<----------------+ 637 | | | | 638 ... Time Passes ... 639 | | 640 | BREAK [c] | 641 |<----------------+ 642 | | 643 | ACK | 644 +---------------->| 645 | | 647 Figure 5 649 (The motivation for the BREAK component of the response is: PUT, like 650 GET, can experience some error condition, so we need a place in the 651 state machine to put the THROW response; therefore we also need a 652 BREAK response. The second case in Figure 5 is motivated by: PUT, 653 like GET, can take some time to be processed, so we must be able to 654 send an ACK immediately and the THROW or BREAK response later.) 656 Obviously, changing the state of this resource leads to notification 657 of any observers of new state. PUT is idempotent, but if we add 658 notifications it may be a bit surprising that a duplicated or 659 retransmitted PUT might send notifications twice. To prevent that, 660 the resource might check whether it is being changed to the same 661 state it had before and not send notifications in that case. 663 4.6. Deleting a resource 665 A DELETE request is the same as a PUT request, except that the 666 resource is not created or its state changed, but deleted. 668 Client Server 669 | | 670 | DELETE | 671 +---------------->| 672 | | 673 | ACK+BREAK | 674 |<----------------+ 675 | | 677 Figure 6 679 If a resource is observed, deleting the resource leads to an error 680 condition of which the observers are notified with a THROW 681 notification or THROW request. 683 5. Caching 685 An observer may cache part or all of a resource's state changes. 686 This allows clients to make conditional requests: If a subscribing 687 client has cached a particular resource state, the server offering 688 the resource does not need to send a full notification. 690 o A client informs the server of its cached resource states by 691 including Etags of cached resource states in the subscription 692 request. This can be multiple Etags, as this enables the server 693 to just send a "304 not modified" for a different Etag instead of 694 a different representation if the resource switches around between 695 multiple states. (Note that this list might be updated by a 696 subscription refresh.) 698 o A server notifies a client of a change to a cached state by 699 omitting the representation of the resource state in the 700 notification and including a flag ("304 not modified") that 701 indicates that the state changed to a cached state. 703 Another approach to caching multiple values for a resource is to 704 express each possible value of the resource's representation by a 705 reference to another (unchanging) resource. This lets a resource 706 change states between a set of such references that then provide the 707 actual state information. A subscribed client fetches the individual 708 resources on demand and caches the results for future use. 710 6. Identifying notifications and subscriptions 712 There are two ways that a notification could be related to the 713 resource that it is about: 715 1. The notification could name the resource (its URI). 717 2. The notification could name a target that relates to a 718 subscription, which in turn relates back to the resource. 720 One or both ways could be implemented in CoAP, there are not 722 For way 1, each notification would contain the URI of the resource. 723 This is particularly useful for multicast messages, but could be 724 relatively wasteful. Also, it is not entirely clear that all servers 725 will be aware of their own authority. Apart from cached states 726 (Section 5) and other information that could be part of a GET, a 727 subscription would simply be the triple 729 [URI, observer transport address, lifetime] 731 Resubscribing (or a duplicate subscription request) for the same 732 [URI, observer transport address] pair simply updates the lifetime; 733 thus, the subscription operation is idempotent. Similarly, 734 resubscribing with a lifetime of 0 will serve to delete the 735 subscription (however, a SUBSCRIBE message will be replied to with 736 the current state of the resource; a SUBSCRIBE with lifetime 0 is 737 thus equivalent to a GET with the side effect of deleting the 738 subscription). 740 The notification then needs to contain the URI (and might 741 occasionally contain a remaining lifetime): 743 [resource representation, resource metadata, URI, lifetime?] 745 For way 2, the subscription request would also contain a target 746 identifier that is to be used in every notification, identifying the 747 specific observer object that is to receive the notification. Again 748 apart from cached states (Section 5) and other information that could 749 be part of a GET, the subscription would be the quadruple: 751 [URI, observer transport address, target, lifetime] 753 (Note that the combination of the observer transport address and the 754 target could be expressed as another URI, with the transport address 755 as the authority and the target as the path. Alternatively, the 756 target could be a short byte string. By varying the transport 757 address, i.e. the port number, the target could also made to be 758 always empty.) 760 Resubscribing (or a duplicate subscription request) for the same 761 [URI, observer transport address, target] triple simply updates the 762 lifetime, thus, the subscription operation again is idempotent. (The 763 same comment as with way 1 applies to SUBSCRIBE with lifetime 0.) 765 As the notification already implicitly contains the transport 766 address, it would just list the target (and might occasionally 767 contain a remaining lifetime): 769 [resource representation, resource metadata, target, lifetime?] 771 In both cases, it would be beneficial if rebooting nodes could obtain 772 the same transport address they had before, because a resubscription 773 after the reboot does not create additional state. 775 Multicast works nicely in way 1 (except that the URI may be large). 776 In way 2, we can give each observer in a multicast group the same 777 target name, so multicast works. 779 For normal subscriptions, the observer transport address can be 780 implied from the source address of the subscription request. For 781 multicast, there needs to be a way to explicitly indicate that 782 transport address. (This may be beneficial for unicast, too.) 784 7. Open issues 786 Add discussion of messages that get reordered. 788 Add detailed message and option formats, once the semantics are 789 agreed. 791 Describe how to map this to HTTP long-polls, WebSockets, and other 792 asynchronous forms of HTTP. 794 8. References 796 8.1. Normative References 798 [I-D.ietf-core-coap] 799 Shelby, Z., Frank, B., and D. Sturek, "Constrained 800 Application Protocol (CoAP)", draft-ietf-core-coap-00 801 (work in progress), June 2010. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 807 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 808 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 810 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 811 Resource Identifier (URI): Generic Syntax", STD 66, 812 RFC 3986, January 2005. 814 8.2. Informative References 816 [DUAL] Meijer, E., "Subject/Observer is Dual to Iterator", 817 June 2010. 819 [REST] Fielding, R., "Architectural Styles and the Design of 820 Network-based Software Architectures", 2000. 822 Authors' Addresses 824 Klaus Hartke 825 Universitaet Bremen TZI 826 Postfach 330440 827 Bremen D-28359 828 Germany 830 Phone: +49-421-218-63908 831 Fax: +49-421-218-7000 832 Email: hartke@tzi.org 834 Carsten Bormann 835 Universitaet Bremen TZI 836 Postfach 330440 837 Bremen D-28359 838 Germany 840 Phone: +49-421-218-63921 841 Fax: +49-421-218-7000 842 Email: cabo@tzi.org