idnits 2.17.00 (12 Aug 2021) /tmp/idnits16301/draft-nottingham-http-cache-channels-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 524. 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 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 10, 2007) is 5489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (ref. '1') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: draft-nottingham-atompub-feed-history has been published as RFC 5005 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Yahoo! Inc. 4 Intended status: Informational May 10, 2007 5 Expires: November 11, 2007 7 HTTP Cache Channels 8 draft-nottingham-http-cache-channels-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 11, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This specification defines "cache channels" to propagate out-of-band 42 events from HTTP origin servers (or their delegates) to subscribing 43 caches. It also defines an event payload that gives finer-grained 44 control over cache freshness. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 50 3. Cache Channels . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Channel Subscription . . . . . . . . . . . . . . . . . . . 5 52 3.2. Event Application . . . . . . . . . . . . . . . . . . . . 5 53 3.3. Atom Cache Channels . . . . . . . . . . . . . . . . . . . 6 54 3.3.1. The 'cc:precision' Feed Extension . . . . . . . . . . 7 55 3.3.2. The 'cc:lifetime' Feed Extension . . . . . . . . . . . 7 56 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 57 4. Manging Freshness with Cache Channels . . . . . . . . . . . . 8 58 4.1. The 'channel-max-age' Response Cache-Control Extension . . 9 59 4.2. The 'stale' Cache Channel Event . . . . . . . . . . . . . 9 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 63 Appendix B. Operational Considerations . . . . . . . . . . . . . 10 64 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . . . 13 68 1. Introduction 70 This specification defines "cache channels" to propagate out-of-band 71 events from HTTP [1] origin servers (or their delegates) to 72 subscribing caches. It also defines an event payload that gives 73 finer-grained control over cache freshness. 75 Typically, a cache will discover channels of interest by examining 76 Cache-Control response headers for the "channel" extension; when 77 present, it indicates that the response is associated with that 78 channel. Upon subscription, caches will receive all events in that 79 channel. 81 To allow use of a variety of underlying protocols, the process of 82 subscription and the means of propagating events in the channel are 83 specific to the transport in use. This specification does define one 84 such channel transport, using the Atom Syndication Format [2]. 86 Likewise, channels may be used to convey a variety of events from 87 origin servers to caches. This specification defines one such 88 payload, the 'stale' event, that affords finer-grained control over 89 freshness than available in HTTP alone. 91 Together, cache channels and the stale event enable an origin server 92 to maintain control over the content of a set of caches while 93 increasing their efficiency. For example, "reverse proxies" are 94 often used to accelerate HTTP servers by caching their content; cache 95 channels and stale events can be used to more closely control their 96 behaviour. 98 This use of cache channels is similar to an invalidation protocol, 99 except that the protocol described here operates by extending cached 100 responses' freshness lifetime, rather than invalidating them. This 101 preserves the semantics of the HTTP caching model and assures that 102 the failure modes are safe. 104 Additionally, the 'group' functionality of cache channels enables 105 stale events to apply to several cached responses, thereby offering 106 control over freshness of responses whose request-URIs may not be 107 known. For example, a HTTP search interface may have given several 108 responses containing the same information; if they are grouped 109 together, it is possible to force them to become stale without 110 knowing their request-URIs. 112 2. Notational Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [3], as scoped 117 to those conformance targets. 119 This specification uses the augmented Backus-Naur Form of RFC2616 120 [1], and includes the delta-seconds rule from that specification, and 121 the absolute-URI rule from RFC3986 [4]. 123 Elements defined by this specification use the XML namespace [5] URI 124 "http://purl.org/syndication/cache-channel". In this specification, 125 that URI is assumed to be bound to the prefix "cc". 127 3. Cache Channels 129 A cache channel is an out-of-band path from an origin server (or its 130 delegate) to one or more interested caches. It is identified by a 131 URI [4]. 133 A channel contains events, each of which may be associated with one 134 or more URIs. The payload of each event is applied to its associated 135 URIs when it is received. 137 Typically, a cache channel will convey events applicable to a variety 138 of URIs in an administrative domain; for example, it might carry all 139 events that apply to a single origin server, or a group of origin 140 servers. 142 From the perspective of a cache, a channel has several interesting 143 states; 145 o unsubscribed: The channel is not being monitored. 146 o connected: The channel is being monitored, and events are able to 147 be propagated. 148 o disconnected: The channel is being monitored, but events are not 149 able to be propagated. 151 Channels MUST make the events that they contain available for an 152 advertised amount of time, known as the lifetime of the channel. 153 This allows clients that have been disconnected to re-synchronise 154 themselves with the contents of the channel upon becoming re- 155 connected. 157 Channels SHOULD also advertise the approximate propagation delay, 158 known as their precision. 160 Two general processes facilitate the operation of cache channels; 161 subscription and event application. 163 3.1. Channel Subscription 165 Channels are advertised using the "channel" HTTP response cache- 166 control extension. 168 channel-extension = "channel" "=" <"> channel-URI <"> 169 channel-URI = absolute-URI 171 The recipient of this cache-control extension can subscribe to the 172 channel-URI when interested in receiving events associated with the 173 response. 175 The specific mechanism for subscription is determined by the channel- 176 URI's scheme and other factors (e.g., the media type of the 177 representation obtained by dereferencing that URI). 179 If a subsequent response has a different channel-URI, or no channel- 180 URI, and there are no other responses associated with the same 181 channel-URI, a subscriber SHOULD unsubscribe from the channel. 183 A response MUST NOT have more than one channel-extension. 185 For example, 187 Cache-Control: max-age=300, channel="http://example.org/channels/a" 189 3.2. Event Application 191 An event carries one or more event-URIs, which are used to determine 192 what cached responses the event applies to. This includes responses 193 whose request-URIs match an event-URI, and those with a group-URI 194 matching an event-URI. 196 Responses can be associated with a group-URI using the "group" 197 response Cache-Control extension; 199 group-extension = "group" "=" <"> group-URI <"> 200 group-URI = absolute-URI 202 A response MAY have any number of group-extensions. 204 For example, a response carrying the following Cache-Control header; 206 Cache-Control: max=age=600, channel="http://example.com/channels/a", 207 group="urn:uuid:30A909D9-BC7A-4257-BE09-6F781AD6471F" 209 will not only have those events which match the response's request- 210 URI applied, but also events who match the URI 211 "urn:uuid:30A909D9-BC7A-4257-BE09-6F781AD6471F". 213 This mechanism allows application of events to arbitrary sets of 214 responses using a synthetic identifier. 216 For example, if "http://example.com/", "http://example.com/top.html" 217 and "http://example.com/index.html" are all associated with the group 218 identified by "urn:uuid:30A909D9-BC7A-4257-BE09-6F781AD6471F", an 219 event with that group-URI will be applied to all three. 221 By default, an event will apply to a matching response regardless of 222 the headers used to select it (as indicated by the Vary response 223 header). However, a particular event type can be specified to 224 override this behaviour. 226 Note that an event MUST NOT be applied to responses whose channel- 227 extension does not indicate that the response is associated with the 228 channel that the event occurred in. 230 3.3. Atom Cache Channels 232 The Atom Syndication Format [2] -- when used with channel-specific 233 extensions in a specific pattern over HTTP -- is one suitable cache 234 channel transport. 236 A channel is subscribed to by commencing regular polling of the 237 channel-URI. Polling MUST be attempted at least as often as the 238 channel's precision, as indicted by the cc:precision feed extension. 240 The feed's 'current' link relation value MUST contain the channel- 241 URI, which MUST be a HTTP URI. 243 The channel is considered disconnected when the last successful poll 244 occurred more than channel-precision seconds ago, or a successful 245 poll has not yet occurred. A successful poll is defined as one that 246 results in a fresh (according to the HTTP caching model) copy of a 247 well-formed, valid feed document with a 'self' link relation whose 248 value is character-for-character identical to the channel-URI. 250 The feed MAY be archived [6] to allow the full state of the channel 251 to be reconstructed, while minimising the amount of bandwidth that 252 polling the channel consumes. 254 The cc:lifetime feed extension indicates the minimum span of time 255 that events are available in the feed for. 257 Entries in the feed represent events, in reverse-chronological order. 258 The atom:link element(s) with the "alternate" relation determines the 259 URI(s) that an event is applicable to. 261 3.3.1. The 'cc:precision' Feed Extension 263 An Atom cache channel's precision is indicated by the cc:precision 264 element. This is an feed-level extension element whose content 265 indicates the precision in seconds. 267 For example; 269 60 271 indicates that the precision of the channel it occurs in is one 272 minute. 274 3.3.2. The 'cc:lifetime' Feed Extension 276 An Atom cache channel's lifetime is indicated by the cc:lifetime 277 element. This is an feed-level extension element whose content 278 indicates the lifetime in seconds. 280 For example; 282 2592000 284 indicates that the lifetime of the channel it occurs in is 30 days. 286 3.3.3. Example 288 290 Invalidations for www.example.org 291 http://admin.example.org/events/ 292 294 296 2007-04-13T11:23:42Z 297 298 Administrator 299 web-admin@example.org 300 301 60 302 2592000 303 304 stale 305 http://admin.example.org/events/1124 306 2007-04-13T11:23:42Z 307 308 309 310 311 stale 312 http://admin.example.org/events/1125 313 2007-04-13T10:31:01Z 314 315 316 317 318 320 This feed document contains two events, the most recent applying to 321 the URI "urn:uuid:50D3565C-97A8-40E1-A5C8-CFA070166FEF" and the other 322 to "http://www.example.org/img/123.gif" and 323 "http://www.example.org/img/123.png". The previous archive document 324 is located at "http://admin.example.org/events/archive/1234", to 325 allow the client to reconstruct missed events if necessary. The 326 channel it represents has a precision of 60 seconds (thereby telling 327 clients that they need to poll at least that often), and a lifetime 328 of 30 days. 330 4. Manging Freshness with Cache Channels 332 One use of cache channels is the management of cached responses' 333 freshness lifetime. This is achieved through use of the 'channel- 334 max-age' response Cache-Control extension, which allows subscribed 335 caches to extend the freshness of a response until an applicable 336 'stale' cache channel event is received. 338 4.1. The 'channel-max-age' Response Cache-Control Extension 340 The channel-max-age response cache-control extension allows 341 controlled extension of the freshness lifetime of a cached response. 343 channel-max-age = "channel-max-age" "=" delta-seconds 345 A response containing this extension MAY be considered fresh when all 346 of the following conditions are true; 348 o The cache is connected to the channel indicated by the channel- 349 URI. 350 o The channel does not contain a 'stale' event applicable to the 351 cached response. 352 o The response's current_age (as per HTTP [1], Section 13.2.3) is no 353 more than delta-seconds. 355 For example a response with this Cache-Control header; 357 Cache-Control: channel="http://admin.example.org/events/current", 358 group="urn:uuid:50D3565C-97A8-40E1-A5C8-CFA070166FEF", 359 channel-max-age=86400, max-age=30 361 will be considered fresh for 30 seconds by a cache that is not 362 subscribed to the channel "http://admin.example.org/events/current", 363 but can be considered fresh for up to a day by one that is, as long 364 as the channel does not contain an applicable 'stale' event. 366 4.2. The 'stale' Cache Channel Event 368 Cache channels can indicate that all cached responses associated with 369 a URI are to be considered stale with the 'stale' event. In Atom 370 channels, this event is indicated by the cc:stale entry-level 371 extension; 373 375 When received, this event indicates that any cached response 376 associated with the event's URI(s) MUST be considered stale (for 377 purposes of extension by channel-max-age) within channel-precision 378 seconds. 380 5. Security Considerations 382 Publishers of cache channels MAY require credentials to be presented. 384 6. Normative References 386 [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 387 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 388 HTTP/1.1", RFC 2616, June 1999. 390 [2] Nottingham, M. and R. Sayre, "The Atom Syndication Format", 391 RFC 4287, December 2005. 393 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 394 Levels", BCP 14, RFC 2119, March 1997. 396 [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 397 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 398 January 2005. 400 [5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C 401 REC REC-xml-names-19990114, January 1999. 403 [6] Nottingham, M., "Feed Paging and Archiving", 404 draft-nottingham-atompub-feed-history-09 (work in progress), 405 April 2007. 407 Appendix A. Acknowledgements 409 Thanks to Jeff McCarrell, John Nienart, Henrik Nordstrom, Evan 410 Torrie, and Chris Westin for their suggestions. The author takes all 411 responsibility for errors and omissions. 413 Appendix B. Operational Considerations 415 There are a number of aspects to considered when using cache 416 channels; 418 o They are most efficient when a small number of channels (ideally, 419 one) is used to convey events about a large number of associated 420 resources (e.g., an entire Web site, or a number of related 421 sites). 422 o In particular, when using Atom channels care should be taken to 423 assure that the additional requests necessary to poll the channel 424 are offset by the load reduction achieved. In doing so, the 425 anticipated number of clients, channel-precision, change rate for 426 cached responses and number of responses being monitored by the 427 channel need to be considered. 428 o Feed documents from Atom-based channels should be cacheable, to 429 allow clusters of caches and cache hierarchies to share them more 430 efficiently. 431 o When using channels to update freshness information, it is 432 critical to assure that any new content is actually available 433 before events are propagated; if the event is too early and stale 434 cached content forces revalidation, it is possible that the 435 updated content will not be loaded into cache. 436 o Responses that use the channel-max-age mechanism should also 437 specify a max-age, both to allow channel-naive caches to store 438 them in a limited fashion, and also to allow some types of channel 439 implementations to initially store the response before 440 subscribing. 442 Appendix C. Implementation Notes 444 Handling of the 'stale' event in order to extend freshness can often 445 be effected in an existing cache implementation with only small 446 changes. 448 In particular, most caches can be easily modified to call a function 449 (whether in-process or in a separate process) when a stale response 450 is found, before the decision to validate it on the origin server is 451 made. Using the request-URI, the stored Cache-Control response 452 header and the age of the cached response as input, such a function 453 should return either STALE, which indicates that the cached response 454 is in fact stale, or FRESH, along with an indication of how much the 455 freshness lifetime should be extended by. 457 This function determines its response based upon its application of 458 the following rules to the state that is collected about the channel 459 in question; 461 o If the channel-URI is missing from the Cache-Control response 462 header, the response is assumed to not be associated with any 463 channel, and a STALE can immediately be returned. 464 o If the channel is unsubscribed, it should be scheduled for 465 subscription, and STALE returned. 466 o If the channel is disconnected, return STALE. 467 o If there is a 'stale' event in the channel that applies to the 468 request-URI or group-URI (if present), and cached response's age 469 is greater than the age of the of that event (calculated using the 470 invalidate-date), return STALE. 472 o If the cached response's age is greater than channel-max-age, 473 return STALE. 474 o If the cached response's age is greater than the channel's 475 lifetime, return STALE. 476 o Otherwise, return FRESH freshness=[channel-precision]. 478 Author's Address 480 Mark Nottingham 481 Yahoo! Inc. 483 Email: mnot@yahoo-inc.com 484 URI: http://www.mnot.net/ 486 Full Copyright Statement 488 Copyright (C) The IETF Trust (2007). 490 This document is subject to the rights, licenses and restrictions 491 contained in BCP 78, and except as set forth therein, the authors 492 retain all their rights. 494 This document and the information contained herein are provided on an 495 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 496 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 497 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 498 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 499 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 500 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 502 Intellectual Property 504 The IETF takes no position regarding the validity or scope of any 505 Intellectual Property Rights or other rights that might be claimed to 506 pertain to the implementation or use of the technology described in 507 this document or the extent to which any license under such rights 508 might or might not be available; nor does it represent that it has 509 made any independent effort to identify any such rights. Information 510 on the procedures with respect to rights in RFC documents can be 511 found in BCP 78 and BCP 79. 513 Copies of IPR disclosures made to the IETF Secretariat and any 514 assurances of licenses to be made available, or the result of an 515 attempt made to obtain a general license or permission for the use of 516 such proprietary rights by implementers or users of this 517 specification can be obtained from the IETF on-line IPR repository at 518 http://www.ietf.org/ipr. 520 The IETF invites any interested party to bring to its attention any 521 copyrights, patents or patent applications, or other proprietary 522 rights that may cover technology that may be required to implement 523 this standard. Please address the information to the IETF at 524 ietf-ipr@ietf.org. 526 Acknowledgment 528 Funding for the RFC Editor function is provided by the IETF 529 Administrative Support Activity (IASA).