idnits 2.17.1 draft-nottingham-webi-warm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2002) is 8098 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft February 21, 2002 4 Expires: August 22, 2002 6 Web Active Resource Monitoring 7 draft-nottingham-webi-warm-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 22, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 WARM is a straw-man proposal for a solution to the RUP requirements 39 of the WEBI WG which reuses the Web Architecture (and HTTP). In 40 particular, it provides a mechanism for distributing cache 41 invalidations from HTTP servers to clients. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.2 WARM Resources . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.2.1 Channel Resources . . . . . . . . . . . . . . . . . . . . . 4 49 1.2.2 Subscription Resources . . . . . . . . . . . . . . . . . . . 5 50 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 51 2.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.1.1 Active Discovery . . . . . . . . . . . . . . . . . . . . . . 5 53 2.1.2 Passive Discovery . . . . . . . . . . . . . . . . . . . . . 6 54 2.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.2.1 Subscription-Based Monitoring . . . . . . . . . . . . . . . 7 56 2.2.2 Polling-Based Monitoring . . . . . . . . . . . . . . . . . . 8 57 3. Relationships to Network Nodes . . . . . . . . . . . . . . . 9 58 4. Using WARM for Cache Invalidation . . . . . . . . . . . . . 9 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 60 5.1 The WATCH HTTP request method . . . . . . . . . . . . . . . 10 61 5.2 The Subscription HTTP request header . . . . . . . . . . . . 11 62 5.3 The Channel HTTP response header . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 64 References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 66 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 B. Issues/TODO . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 WEBI's Resource Update Protocol requirements are broad enough that a 73 wide variety of architectural styles could satisfy them. WARM is a 74 straw-man proposal for RUP that concentrates on reusing the Web 75 architecture. This approach has several advantages; 77 o Generality - The Web is most correctly defined as an information 78 space, rather than the use of any particular protocol or format. 79 A notification protocol that uses the same foundations as the Web 80 (namely, resources identified by URIs and HTTP) will be able to 81 make statements about any resource on the Web, not just a subset 82 of them. 84 o Extensibility/Evolvability - WARM leverages the Web's properties 85 of extensibility and evolvability, in turn providing them to 86 applications that use it for notifications. 88 o Simplicity - A HTTP-based system is easier for Web publishers and 89 HTTP implementors to understand. 91 o Ease of Implementation - Because WARM uses the HTTP, the cost of 92 implementing on HTTP devices it is extremely low. Additionally, 93 WARM will be able to use well-understood HTTP mechanisms like 94 authentication, SSL/TLS, ETag validation, content negotiation, 95 redirection, etc. 97 This document defines the WARM architecture and a cache invalidation 98 payload for it. Please direct comments to the WEBI WG mailing list, 99 webi@lists.equinix.com. 101 1.1 Requirements 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [2]. 107 An implementation is not compliant if it fails to satisfy one or more 108 of the MUST or REQUIRED level requirements. An implementation that 109 satisfies all the MUST or REQUIRED level and all the SHOULD level 110 requirements is said to be "unconditionally compliant"; one that 111 satisfies all the MUST level requirements but not all the SHOULD 112 level requirements is said to be "conditionally compliant". 114 1.2 WARM Resources 116 WARM provides for propogation of events concerning Web resources by 117 defining two new types of resources; Channel Resources and 118 Subscription Resources. 120 Note that these classifications are conveniences; they are not 121 fundamentally different from other kinds of resources on the Web. 123 WARM effects monitoring by transferring representations of the state 124 of Channel Resources and caching it for a short period of time. If 125 subscription-based monitoring is in use, clients expose a 126 Subscription Resource, into which representations of the Channel 127 Resource's state are copied. Clients using Polling-based monitoring 128 will directly fetch a representation of the Channel Resource's state 129 and cache it locally. 131 Representations of Channel Resources (whether polled or subscribed) 132 have a freshness associated with them, which is functionally similar 133 to HTTP cache freshness. When they become stale, any assertions made 134 by the representations SHOULD be considered invalid. 136 On their own, these mechanisms allow the transfer of state 137 representations in the channel and subscriptions to it; they do not 138 describe what the representations of that state are. This 139 specification defines one representation format that can be used to 140 maintain coherence in an HTTP cache; other payloads may be defined in 141 the future. 143 1.2.1 Channel Resources 145 Channel Resources characterize the state of an arbitrary grouping of 146 Web resources. They are are identified by URIs, are accessed using 147 the HTTP, and can be monitored either by polling or through 148 subscription. 150 Traditional Web resources may be monitored using the same mechanisms; 151 they behave as Channel Resources that characterize the state of only 152 one Web resource. 154 For example, the Channel Resource 155 http://www.example.com/channel;A 157 embodies a channel that contains the state of an arbitrary number of 158 resources. Those resources may be under control of the same 159 authority as the Channel Resource, or they may be elsewhere. 161 Informally, the semantics of common HTTP methods on Channel Resources 162 are: 164 o GET - retrieve a representation of the state of the channel. 166 o WATCH - subscribe to the channel. 168 1.2.2 Subscription Resources 170 When a Channel Resource is subscribed to using the WATCH method, a 171 reference to a Subscription Resource is provided in the Subscription 172 HTTP request header. This allows the Channel Resource to maintain 173 state regarding who is subscribed, and to locate them to perform 174 operations related to the subscription. 176 For example, a Subscription Resource 177 http://client.example.net/subscription;1 179 contains the state associated with a particular subscription to the 180 Channel Resource. Subscription resources might be accessed through 181 any number of protocols; this document only defines how they are 182 accessed in HTTP. 184 Informally, the semantics of common HTTP methods on Subscription 185 Resources are: 187 o GET - retrieve a representation of the state of the subscription. 189 o PUT - replace the state of the subscription. 191 o POST - update the freshness of the subscription. 193 o DELETE - terminate the subscription. 195 2. Overview of Operation 197 WARM's operation is composed of two different modes; discovery and 198 monitoring. 200 2.1 Discovery 202 The appropriate Channel Resource for a given Web resource can be 203 discovered either passively or actively. Discovery is OPTIONAL; some 204 deployments may require out-of-band discovery, which is out of scope 205 for this document. 207 2.1.1 Active Discovery 209 Active discovery is accomplished by performing a WATCH on the Web 210 resource. 212 For example: 214 (request) 215 WATCH http://www.example.org/image.png 217 (response) 218 302 Found 219 Location: http://www.example.org/channel;A 221 Here, the location of the appropriate Channel Resource is found by 222 examining the target of the redirect. The semantics of HTTP status 223 codes in responses to active discovery requests should be honored as 224 they are defined in the HTTP. 226 The Resource SHOULD be considered associated with the actively 227 discovered Channel Resource until a subsequent WATCH changes the 228 association, or the semantics of the Channel Resource's 229 representation explicitly change the association. 231 2.1.2 Passive Discovery 233 Clients can passively discover Channel Resources by looking for the 234 Channel HTTP response header; 236 (request) 237 GET http://www.example.org/image.png 239 (response) 240 200 OK 241 Channel: http://www.example.org/channel;A 242 ... 244 The Resource SHOULD be considered associated with the passively 245 discovered Channel Resource until subsequent representation has a 246 different or missing Channel response header, or the semantics of a 247 representation of the Channel Resource explicitly change the 248 association. 250 [[[ what about changes to the Channel Resource's state? ]]] 252 2.2 Monitoring 254 Once the appropriate Channel Resource is discovered, its state can be 255 monitored through the use of one of two techniques; subscription- 256 based monitoring and polling-based monitoring. 258 Subscription-based monitoring allows notifications to be sent as 259 quickly as network and other resource limitations allow them to be, 260 in combination with a heartbeat mechanism to assure that the channel 261 remains available. 263 Polling-based monitoring can be used in situations where the Channel 264 Resource is unwilling to maintain state about subscriptions, or where 265 network conditions (e.g., a firewall) make it impractical to expose a 266 Subscription Resource. 268 2.2.1 Subscription-Based Monitoring 270 Clients who wish to use subscription-based monitoring advertise this 271 through use of the Subscription HTTP request header, in combination 272 with the WATCH method. For example; 274 (request) 275 WATCH http://www.example.com/channel;A 276 Subscription: http://client.example.net/subscription;1 277 Accept: text/xml, */*;q=0.0 279 (response) 280 200 OK 282 A Channel Resourse SHOULD NOT return a successful status code to the 283 WATCH method until it has initiated the Subscription Resource (with a 284 PUT). If it cannot do so, it SHOULD return an appropriate client or 285 server failure status code. In disconnected deployments, it MAY 286 return 202 Accepted. 288 In subscription-based monitoring, the Channel Resource must first 289 initialise the state of the Subscription Resource by PUTing a 290 representation of the channel into it. Thereafter, the Channel 291 Resource may update the state of the Subscription Resource with 292 subsequent PUTs, and forceably delete the subscription with DELETE. 293 Integrity of channel connectivity is assured by polling the 294 Subscription Resource with the POST method and an empty entity body. 296 For example; 297 (initialise/update request) 298 PUT http://client.example.net/subscription;1 299 Cache-Control: max-age=600 300 Content-Type: text/xml 301 [entity body] 303 (initialise response) 304 201 Created 306 (update response) 307 200 OK 309 (heartbeat request) 310 POST http://client.example.net/subscription;1 311 Cache-Control: max-age=600 312 Content-Length: 0 314 (heartbeat response) 315 204 No Content 317 (delete request) 318 DELETE http://client.example.net/subscription;1 320 (delete response) 321 200 OK 323 PUT and POST requests to Subscription Resources SHOULD include a 324 Cache-Control: max-age header. Its value is used to determine when 325 the next heartbeat should arrive by; if a heartbeat is not received 326 by its expiry, the Subscription Resource SHOULD be considered 327 deleted. 329 [[[ is this a good use of Cache-Control, or would it be more correct 330 to define a new header? ]]] 332 The semantics of HTTP status codes in responses MUST be honored. In 333 particular, if any request to a Subscription Resource returns 410 334 Gone, the Channel Resource SHOULD consider the subscription canceled, 335 and cease monitoring. 337 2.2.2 Polling-Based Monitoring 339 Clients using polling-based monitoring make periodic HTTP requests to 340 the Channel Resource; the response represents its current state. 342 To ensure correctness and efficiency in polling-based monitoring, 343 Channel Resources MUST support ETag validation. Channel Resources 344 SHOULD use the Cache-Control response header for GETs to declare how 345 long that representation of the channel should be considered fresh 346 (and therefore, how long before the client should poll again). 348 For example; 350 (request) 351 GET http://www.example.com/channel;A 352 If-None-Match: "abcde" 353 Accept: text/xml, */*;q=0.0 355 (response) 356 304 Not Modified 357 Cache-Control: max-age=600 358 ETag: "abcde" 360 3. Relationships to Network Nodes 362 Because they are located by URIs, Channel and Subscription Resources 363 may be located on any addressable network node. However, it may be 364 helpful to illustrate a typical implementation; 366 +--------+ +--------+ 367 | | ------ request(s) to Channel Resource(s) -----> | | 368 | HTTP | | HTTP | 369 | Client | | Server | 370 | + | <--- request(s) to Subscription Resource(s) --- | + + | 371 +--------+ +--------+ 372 ^ ^ ^ 373 \ Subscription Resource Channel Resource / | 374 Web Resource / 376 This illustration should not be construed to limit the location of a 377 Channel Resource to the network node on which the resource(s) it 378 characterizes reside, or to prohibit the location of a Subscription 379 Resource on a node other than the HTTP client. Indeed, there are 380 many scenarios where it is beneficial to do so, for purposes of 381 scalability, managability, assertion of administrative control, or 382 for disconnected operation. 384 4. Using WARM for Cache Invalidation 386 WARM may be used to maintain coherence of cached representations. In 387 this application, the payload of notifications is a simple XML 388 document identified by the application/xml media type, using a single 389 element, 'cache', in the WARM cache namespace; 390 391 392 abcdefg 393 395 The content of the element is a nonce generated by the Channel 396 Resource to identify its current revision level; it MUST be 397 guaranteed by the Channel Resource to be unique in its scope. When 398 any Web resource associated with the Channel Resource becomes stale, 399 the Channel Resource state SHOULD change. 401 This implies that the cache will track the mapping between Web 402 resources and Channel Resources and/or Subscription Resources, so 403 that when notifications are received, the appropriate representations 404 can be marked stale. Web resources that are associated with such 405 WARM Channel Resources SHOULD be considered fresh until such a 406 notification is received, the channel is deleted, or connectivity is 407 lost. 409 WARM can also be used with other cache-related payloads; their 410 semantics, interactions with cache behaviour, and additional 411 association mechanisms are format-dependent. 413 For purposes of content negotiation, the media type of this format is 414 "[[[ TBD ]]]". 416 5. IANA Considerations 418 5.1 The WATCH HTTP request method 420 The WATCH method is used to associate a Subscription Resource with a 421 Channel Resource, or to locate an appropriate Channel Resource. If a 422 Subscription Resource is associated, regular requests containing 423 heartbeat and/or update messages (as described above) will be made to 424 it. 426 watch = "WATCH" 428 WATCHing a resource may instigate one or more requests to 429 subscription resources, if subscription-based monitoring is in use 430 (as evidenced by a Subscription request header). If content 431 negotiation is used to determine the representation sent in response 432 to the WATCH, the same representation SHOULD be sent in subsequent 433 PUTs to the Subscription Resource. 435 Implementations SHOULD interpret HTTP status codes resulting from 436 WATCH as defined in RFC2616. Web resources that are not Channel 437 Resources MAY return 303 See Other to direct clients to the 438 appropriate Channel Resource, which may then be monitored by polling 439 or subscription. 441 WATCH requests MAY contain an entity-body; however, this document 442 does not specify a format for them. 444 5.2 The Subscription HTTP request header 446 The Subscription request header is used to indicate the URI of the 447 Subscription Resource that the client wishes to associate with a 448 Channel Resource. 450 subscription = "Subscription" ":" URI 452 5.3 The Channel HTTP response header 454 The Channel response header is used to indicate the URI of the 455 Channel Resource associated with the Web resource. 457 channel = "Channel" ":" URI 459 6. Security Considerations 461 WARM uses the same confidentiality, integrity, authorization and 462 authentication as HTTP does. Therefore, the use of SSL/TLS, the 463 Content-MD5 header and HTTP authentication mechanisms are 464 encouraged, and support for them in implementations is 465 RECOMMENDED. Such issues are relevent to both Channel Resources 466 and Subscription Resources. 468 WARM allows Channel Resources to make statements about Web 469 resources in other administrative domains. Client implementations 470 SHOULD be aware of the impliations of this, and be conservative in 471 their trust of such statements. 473 Certain modes in WARM imply non-trivial resource use by either the 474 client or the server; implementations SHOULD limit their use 475 through techniques such as increasing the lifetime of 476 representations (through the Cache-Control header), limiting the 477 number of clients accepted, etc. 479 References 481 [1] Fielding, R., "Architectural Styles and the Design of Network- 482 based Software Architectures", 2000, . 485 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 486 Levels", RFC 2119, March 1997. 488 Author's Address 490 Mark Nottingham 492 EMail: mnot@pobox.com 493 URI: http://www.mnot.net/ 495 Appendix A. Acknowledgements 497 The author would like to thank Paul Prescod for the spark that led to 498 WARM, Roy Fielding for his description of the REST architectural 499 style [1] that it is built upon, Mark Baker for his insight and 500 patience in explaining and applying REST, and Rohit Khare and Adam 501 Rifkin for their overview of Internet-Scale Event Notification 502 Services. 504 Any error, misconception or bad design in this document is the 505 responsibility of the author, not them. 507 Appendix B. Issues/TODO 509 o Discuss WARM Intermediaries, to scale to large deployments. 511 o Formalize the cache and state models. 513 o how does a client specify authentication credentials for the 514 Subscrition Resource? 516 Full Copyright Statement 518 Copyright (C) The Internet Society (2002). All Rights Reserved. 520 This document and translations of it may be copied and furnished to 521 others, and derivative works that comment on or otherwise explain it 522 or assist in its implementation may be prepared, copied, published 523 and distributed, in whole or in part, without restriction of any 524 kind, provided that the above copyright notice and this paragraph are 525 included on all such copies and derivative works. However, this 526 document itself may not be modified in any way, such as by removing 527 the copyright notice or references to the Internet Society or other 528 Internet organizations, except as needed for the purpose of 529 developing Internet standards in which case the procedures for 530 copyrights defined in the Internet Standards process must be 531 followed, or as required to translate it into languages other than 532 English. 534 The limited permissions granted above are perpetual and will not be 535 revoked by the Internet Society or its successors or assigns. 537 This document and the information contained herein is provided on an 538 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 539 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 540 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 541 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 542 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Acknowledgement 546 Funding for the RFC Editor function is currently provided by the 547 Internet Society.