| draft-nottingham-http-cache-channels-00.txt |  | draft-nottingham-http-cache-channels-01.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Internet-Draft Yahoo! Inc. |  | Internet-Draft Yahoo! Inc. |
| Intended status: Informational May 10, 2007 |  | Intended status: Informational October 12, 2007 |
| Expires: November 11, 2007 |  | Expires: April 14, 2008 |
| HTTP Cache Channels |  | HTTP Cache Channels |
| draft-nottingham-http-cache-channels-00 |  | draft-nottingham-http-cache-channels-01 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 34 |  | skipping to change at page 1, line 34 |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on November 11, 2007. |  | This Internet-Draft will expire on April 14, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2007). |
| Abstract |  | Abstract |
| This specification defines "cache channels" to propagate out-of-band |  | This specification defines "cache channels" to propagate out-of-band |
| events from HTTP origin servers (or their delegates) to subscribing |  | events from HTTP origin servers (or their delegates) to subscribing |
| caches. It also defines an event payload that gives finer-grained |  | caches. It also defines an event payload that gives finer-grained |
| skipping to change at page 2, line 17 |  | skipping to change at page 2, line 17 |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 |  | 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 |
| 3. Cache Channels . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 3. Cache Channels . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 3.1. Channel Subscription . . . . . . . . . . . . . . . . . . . 5 |  | 3.1. Channel Subscription . . . . . . . . . . . . . . . . . . . 5 |
| 3.2. Event Application . . . . . . . . . . . . . . . . . . . . 5 |  | 3.2. Event Application . . . . . . . . . . . . . . . . . . . . 5 |
| 3.3. Atom Cache Channels . . . . . . . . . . . . . . . . . . . 6 |  | 3.3. Atom Cache Channels . . . . . . . . . . . . . . . . . . . 6 |
| 3.3.1. The 'cc:precision' Feed Extension . . . . . . . . . . 7 |  | 3.3.1. The 'cc:precision' Feed Extension . . . . . . . . . . 7 |
| 3.3.2. The 'cc:lifetime' Feed Extension . . . . . . . . . . . 7 |  | 3.3.2. The 'cc:lifetime' Feed Extension . . . . . . . . . . . 7 |
| 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 4. Manging Freshness with Cache Channels . . . . . . . . . . . . 8 |  | 4. Manging Freshness with Cache Channels . . . . . . . . . . . . 8 |
| 4.1. The 'channel-max-age' Response Cache-Control Extension . . 9 |  | 4.1. The 'channel-maxage' Response Cache-Control Extension . . 9 |
| 4.2. The 'stale' Cache Channel Event . . . . . . . . . . . . . 9 |  | 4.2. The 'stale' Cache Channel Event . . . . . . . . . . . . . 9 |
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 |  | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 |
| 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 |  | 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 |
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 |  | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 |
| Appendix B. Operational Considerations . . . . . . . . . . . . . 10 |  | Appendix B. Operational Considerations . . . . . . . . . . . . . 11 |
| Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 11 |  | Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 11 |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 13 |  | Intellectual Property and Copyright Statements . . . . . . . . . . 13 |
| 1. Introduction |  | 1. Introduction |
| This specification defines "cache channels" to propagate out-of-band |  | This specification defines "cache channels" that propagate out-of- |
| events from HTTP [1] origin servers (or their delegates) to |  | band events from HTTP [1] origin servers (or their delegates) to |
| subscribing caches. It also defines an event payload that gives |  | subscribing caches. It also defines an event payload that gives |
| finer-grained control over cache freshness. |  | finer-grained control over cache freshness. |
| Typically, a cache will discover channels of interest by examining |  | Typically, a cache will discover channels of interest by examining |
| Cache-Control response headers for the "channel" extension; when |  | Cache-Control response headers for the "channel" extension; when |
| present, it indicates that the response is associated with that |  | present, it indicates that the response is associated with that |
| channel. Upon subscription, caches will receive all events in that |  | channel. Upon subscription, caches will receive all events in that |
| channel. |  | channel. |
| To allow use of a variety of underlying protocols, the process of |  | To allow use of a variety of underlying protocols, the process of |
| skipping to change at page 4, line 46 |  | skipping to change at page 4, line 46 |
| be propagated. |  | be propagated. |
| o disconnected: The channel is being monitored, but events are not |  | o disconnected: The channel is being monitored, but events are not |
| able to be propagated. |  | able to be propagated. |
| Channels MUST make the events that they contain available for an |  | Channels MUST make the events that they contain available for an |
| advertised amount of time, known as the lifetime of the channel. |  | advertised amount of time, known as the lifetime of the channel. |
| This allows clients that have been disconnected to re-synchronise |  | This allows clients that have been disconnected to re-synchronise |
| themselves with the contents of the channel upon becoming re- |  | themselves with the contents of the channel upon becoming re- |
| connected. |  | connected. |
| Channels SHOULD also advertise the approximate propagation delay, |  | Channels SHOULD also advertise the desired maximum propagation delay |
| known as their precision. |  | for events, known as their precision. |
| Two general processes facilitate the operation of cache channels; |  | Two general processes facilitate the operation of cache channels; |
| subscription and event application. |  | subscription and event application. |
| 3.1. Channel Subscription |  | 3.1. Channel Subscription |
| Channels are advertised using the "channel" HTTP response cache- |  | Channels are advertised using the "channel" HTTP response cache- |
| control extension. |  | control extension. |
| channel-extension = "channel" "=" <"> channel-URI <"> |  | channel-extension = "channel" "=" <"> channel-URI <"> |
| channel-URI = absolute-URI |  | channel-URI = absolute-URI |
| The recipient of this cache-control extension can subscribe to the |  | A recipient of this cache-control extension can subscribe to the |
| channel-URI when interested in receiving events associated with the |  | channel-URI when interested in receiving events associated with the |
| response. |  | response. |
| The specific mechanism for subscription is determined by the channel- |  | The specific mechanism for subscription is determined by the channel- |
| URI's scheme and other factors (e.g., the media type of the |  | URI's scheme and other factors (e.g., the media type of the |
| representation obtained by dereferencing that URI). |  | representation obtained by dereferencing that URI). |
| If a subsequent response has a different channel-URI, or no channel- |  | If a subsequent response has a different channel-URI, or no channel- |
| URI, and there are no other responses associated with the same |  | URI, and there are no other responses associated with the same |
| channel-URI, a subscriber SHOULD unsubscribe from the channel. |  | channel-URI, a subscriber MAY unsubscribe from the channel. |
| A response MUST NOT have more than one channel-extension. |  | A response MUST NOT have more than one channel-extension. |
| For example, |  | For example, |
| Cache-Control: max-age=300, channel="http://example.org/channels/a" |  | Cache-Control: max-age=300, channel="http://example.org/channels/a" |
| 3.2. Event Application |  | 3.2. Event Application |
| An event carries one or more event-URIs, which are used to determine |  | An event carries one or more event-URIs, which are used to determine |
| what cached responses the event applies to. This includes responses |  | what cached responses the event applies to. This includes responses |
| whose request-URIs match an event-URI, and those with a group-URI |  | whose request-URI matches an event-URI, and those with a group-URI |
| matching an event-URI. |  | matching an event-URI. |
| Responses can be associated with a group-URI using the "group" |  | Responses can be associated with a group-URI using the "group" |
| response Cache-Control extension; |  | response Cache-Control extension; |
| group-extension = "group" "=" <"> group-URI <"> |  | group-extension = "group" "=" <"> group-URI <"> |
| group-URI = absolute-URI |  | group-URI = absolute-URI |
| A response MAY have any number of group-extensions. |  | A response MAY have any number of group-extensions. |
| skipping to change at page 6, line 43 |  | skipping to change at page 6, line 43 |
| The feed's 'current' link relation value MUST contain the channel- |  | The feed's 'current' link relation value MUST contain the channel- |
| URI, which MUST be a HTTP URI. |  | URI, which MUST be a HTTP URI. |
| The channel is considered disconnected when the last successful poll |  | The channel is considered disconnected when the last successful poll |
| occurred more than channel-precision seconds ago, or a successful |  | occurred more than channel-precision seconds ago, or a successful |
| poll has not yet occurred. A successful poll is defined as one that |  | poll has not yet occurred. A successful poll is defined as one that |
| results in a fresh (according to the HTTP caching model) copy of a |  | results in a fresh (according to the HTTP caching model) copy of a |
| well-formed, valid feed document with a 'self' link relation whose |  | well-formed, valid feed document with a 'self' link relation whose |
| value is character-for-character identical to the channel-URI. |  | value is character-for-character identical to the channel-URI. |
| The feed MAY be archived [6] to allow the full state of the channel |  | The feed SHOULD be archived [6] to allow the full state of the |
| to be reconstructed, while minimising the amount of bandwidth that |  | channel to be reconstructed, while minimising the amount of bandwidth |
| polling the channel consumes. |  | that polling the channel consumes. If a feed is archived, the |
|  |  | channel is only considered connected when the entire contents of the |
|  |  | logical feed. |
| The cc:lifetime feed extension indicates the minimum span of time |  | The cc:lifetime feed extension indicates the minimum span of time |
| that events are available in the feed for. |  | that events are available in the logical feed for. |
| Entries in the feed represent events, in reverse-chronological order. |  | Entries in the feed represent events, in reverse-chronological order. |
| The atom:link element(s) with the "alternate" relation determines the |  | The atom:link element(s) with the "alternate" relation determines the |
| URI(s) that an event is applicable to. |  | URI(s) that an event is applicable to. |
| 3.3.1. The 'cc:precision' Feed Extension |  | 3.3.1. The 'cc:precision' Feed Extension |
| An Atom cache channel's precision is indicated by the cc:precision |  | An Atom cache channel's precision is indicated by the cc:precision |
| element. This is an feed-level extension element whose content |  | element. This is an feed-level extension element whose content |
| indicates the precision in seconds. |  | indicates the precision in seconds. |
| skipping to change at page 9, line 5 |  | skipping to change at page 9, line 5 |
| is located at "http://admin.example.org/events/archive/1234", to |  | is located at "http://admin.example.org/events/archive/1234", to |
| allow the client to reconstruct missed events if necessary. The |  | allow the client to reconstruct missed events if necessary. The |
| channel it represents has a precision of 60 seconds (thereby telling |  | channel it represents has a precision of 60 seconds (thereby telling |
| clients that they need to poll at least that often), and a lifetime |  | clients that they need to poll at least that often), and a lifetime |
| of 30 days. |  | of 30 days. |
| 4. Manging Freshness with Cache Channels |  | 4. Manging Freshness with Cache Channels |
| One use of cache channels is the management of cached responses' |  | One use of cache channels is the management of cached responses' |
| freshness lifetime. This is achieved through use of the 'channel- |  | freshness lifetime. This is achieved through use of the 'channel- |
| max-age' response Cache-Control extension, which allows subscribed |  | maxage' response Cache-Control extension, which allows subscribed |
| caches to extend the freshness of a response until an applicable |  | caches to extend the freshness of a response until an applicable |
| 'stale' cache channel event is received. |  | 'stale' cache channel event is received. |
| 4.1. The 'channel-max-age' Response Cache-Control Extension |  | 4.1. The 'channel-maxage' Response Cache-Control Extension |
| The channel-max-age response cache-control extension allows |  | The channel-maxage response cache-control extension allows controlled |
| controlled extension of the freshness lifetime of a cached response. |  | extension of the freshness lifetime of a cached response. |
| channel-max-age = "channel-max-age" "=" delta-seconds |  | channel-maxage = "channel-maxage" [ "=" delta-seconds ] |
| A response containing this extension MAY be considered fresh when all |  | A response containing this extension MAY be considered fresh when all |
| of the following conditions are true; |  | of the following conditions are true; |
| o The cache is connected to the channel indicated by the channel- |  | o The cache is connected to the channel indicated by the channel- |
| URI. |  | URI. |
| o The channel does not contain a 'stale' event applicable to the |  | o The channel does not contain a 'stale' event applicable to the |
| cached response. |  | cached response. |
| o The response's current_age (as per HTTP [1], Section 13.2.3) is no |  | o The response's current_age (as per HTTP [1], Section 13.2.3) is no |
| more than delta-seconds. |  | more than delta-seconds, if specified. |
| For example a response with this Cache-Control header; |  | For example a response with this Cache-Control header; |
| Cache-Control: channel="http://admin.example.org/events/current", |  | Cache-Control: channel="http://admin.example.org/events/current", |
| group="urn:uuid:50D3565C-97A8-40E1-A5C8-CFA070166FEF", |  | channel-maxage=86400, max-age=30 |
| channel-max-age=86400, max-age=30 |  |  |
| will be considered fresh for 30 seconds by a cache that is not |  | will be considered fresh for 30 seconds by a cache that is not |
| subscribed to the channel "http://admin.example.org/events/current", |  | subscribed to the channel "http://admin.example.org/events/current", |
| but can be considered fresh for up to a day by one that is, as long |  | but can be considered fresh for up to a day by one that is, as long |
| as the channel does not contain an applicable 'stale' event. |  | as the channel is connected and does not contain an applicable |
|  |  | 'stale' event. |
|  |  | Or, if the response contains; |
|  |  | Cache-Control: channel="http://admin.example.org/events/current", |
|  |  | channel-maxage, max-age=30 |
|  |  | then it will be considered fresh for up to the channels' lifetime, |
|  |  | provided that the channel is connected and does not contain a 'stale' |
|  |  | event. |
| 4.2. The 'stale' Cache Channel Event |  | 4.2. The 'stale' Cache Channel Event |
| Cache channels can indicate that all cached responses associated with |  | Cache channels can indicate that all cached responses associated with |
| a URI are to be considered stale with the 'stale' event. In Atom |  | a URI are to be considered stale with the 'stale' event. In Atom |
| channels, this event is indicated by the cc:stale entry-level |  | channels, this event is indicated by the cc:stale entry-level |
| extension; |  | extension; |
| <cc:stale/> |  | <cc:stale/> |
| When received, this event indicates that any cached response |  | When received, this event indicates that any cached response |
| associated with the event's URI(s) MUST be considered stale (for |  | associated with the event's URI(s) MUST be considered stale (for |
| purposes of extension by channel-max-age) within channel-precision |  | purposes of extension by channel-maxage) within channel-precision |
| seconds. |  | seconds. |
| 5. Security Considerations |  | 5. Security Considerations |
| Publishers of cache channels MAY require credentials to be presented. |  | Subscribing to a cache channel may incur more traffic than would |
|  |  | otherwise be generated by typical operation of a cache. Attackers |
|  |  | might use this to cause an implementation to subscribe to many |
|  |  | channels, reducing their capacity or even denying service. As a |
|  |  | result, caches that implement this protocol should have some |
|  |  | mechanism of limiting or controlling the channels that will be |
|  |  | subscribed to. |
|  |  | The information in a cache channel may be considered sensitive by its |
|  |  | publisher; in this case, they should require credentials to be |
|  |  | presented by subscribers. |
| 6. Normative References |  | 6. Normative References |
| [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., |  | [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., |
| Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- |  | Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- |
| HTTP/1.1", RFC 2616, June 1999. |  | HTTP/1.1", RFC 2616, June 1999. |
| [2] Nottingham, M. and R. Sayre, "The Atom Syndication Format", |  | [2] Nottingham, M. and R. Sayre, "The Atom Syndication Format", |
| RFC 4287, December 2005. |  | RFC 4287, December 2005. |
| [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement |  | [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement |
| Levels", BCP 14, RFC 2119, March 1997. |  | Levels", BCP 14, RFC 2119, March 1997. |
| [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, |  | Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, |
| January 2005. |  | January 2005. |
| [5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C |  | [5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C |
| REC REC-xml-names-19990114, January 1999. |  | REC REC-xml-names-19990114, January 1999. |
| [6] Nottingham, M., "Feed Paging and Archiving", |  | [6] Nottingham, M., "Feed Paging and Archiving", RFC 5005, |
| draft-nottingham-atompub-feed-history-09 (work in progress), |  | September 2007. |
| April 2007. |  |  |
| Appendix A. Acknowledgements |  | Appendix A. Acknowledgements |
| Thanks to Jeff McCarrell, John Nienart, Henrik Nordstrom, Evan |  | Henrik Nordstrom has given invaluable advice and feedback on the |
| Torrie, and Chris Westin for their suggestions. The author takes all |  | design of this specification. Thanks also to Jeff McCarrell, John |
| responsibility for errors and omissions. |  | Nienart, Evan Torrie, and Chris Westin for their suggestions. The |
|  |  | author takes all responsibility for errors and omissions. |
| Appendix B. Operational Considerations |  | Appendix B. Operational Considerations |
| There are a number of aspects to considered when using cache |  | There are a number of aspects to considered when using cache |
| channels; |  | channels; |
| o They are most efficient when a small number of channels (ideally, |  | o They are most efficient when a small number of channels (ideally, |
| one) is used to convey events about a large number of associated |  | one) is used to convey events about a large number of associated |
| resources (e.g., an entire Web site, or a number of related |  | resources (e.g., an entire Web site, or a number of related |
| sites). |  | sites). |
| skipping to change at page 11, line 15 |  | skipping to change at page 11, line 35 |
| cached responses and number of responses being monitored by the |  | cached responses and number of responses being monitored by the |
| channel need to be considered. |  | channel need to be considered. |
| o Feed documents from Atom-based channels should be cacheable, to |  | o Feed documents from Atom-based channels should be cacheable, to |
| allow clusters of caches and cache hierarchies to share them more |  | allow clusters of caches and cache hierarchies to share them more |
| efficiently. |  | efficiently. |
| o When using channels to update freshness information, it is |  | o When using channels to update freshness information, it is |
| critical to assure that any new content is actually available |  | critical to assure that any new content is actually available |
| before events are propagated; if the event is too early and stale |  | before events are propagated; if the event is too early and stale |
| cached content forces revalidation, it is possible that the |  | cached content forces revalidation, it is possible that the |
| updated content will not be loaded into cache. |  | updated content will not be loaded into cache. |
| o Responses that use the channel-max-age mechanism should also |  | o Responses that use the channel-maxage mechanism should also |
| specify a max-age, both to allow channel-naive caches to store |  | specify a max-age, both to allow channel-naive caches to store |
| them in a limited fashion, and also to allow some types of channel |  | them in a limited fashion, and also to allow some types of channel |
| implementations to initially store the response before |  | implementations to initially store the response before |
| subscribing. |  | subscribing. |
| Appendix C. Implementation Notes |  | Appendix C. Implementation Notes |
| Handling of the 'stale' event in order to extend freshness can often |  | Handling of the 'stale' event in order to extend freshness can often |
| be effected in an existing cache implementation with only small |  | be effected in an existing cache implementation with only small |
| changes. |  | changes. |
| skipping to change at page 11, line 40 |  | skipping to change at page 12, line 13 |
| made. Using the request-URI, the stored Cache-Control response |  | made. Using the request-URI, the stored Cache-Control response |
| header and the age of the cached response as input, such a function |  | header and the age of the cached response as input, such a function |
| should return either STALE, which indicates that the cached response |  | should return either STALE, which indicates that the cached response |
| is in fact stale, or FRESH, along with an indication of how much the |  | is in fact stale, or FRESH, along with an indication of how much the |
| freshness lifetime should be extended by. |  | freshness lifetime should be extended by. |
| This function determines its response based upon its application of |  | This function determines its response based upon its application of |
| the following rules to the state that is collected about the channel |  | the following rules to the state that is collected about the channel |
| in question; |  | in question; |
|  |  | o If there is no channel-maxage directive in the Cache-Control |
|  |  | response header, STALE can be returned immediately. |
| o If the channel-URI is missing from the Cache-Control response |  | o If the channel-URI is missing from the Cache-Control response |
| header, the response is assumed to not be associated with any |  | header, the response is assumed to not be associated with any |
| channel, and a STALE can immediately be returned. |  | channel, and a STALE can immediately be returned. |
| o If the channel is unsubscribed, it should be scheduled for |  | o If the channel is unsubscribed, it should be scheduled for |
| subscription, and STALE returned. |  | subscription, and STALE returned. |
| o If the channel is disconnected, return STALE. |  | o If the channel is disconnected, return STALE. |
| o If there is a 'stale' event in the channel that applies to the |  | o If there is a 'stale' event in the channel that applies to the |
| request-URI or group-URI (if present), and cached response's age |  | request-URI or group-URI (if present), and cached response's age |
| is greater than the age of the of that event (calculated using the |  | is greater than the age of the of that event, return STALE. |
| invalidate-date), return STALE. |  | o If the cached response's age is greater than channel-maxage, |
| o If the cached response's age is greater than channel-max-age, |  |  |
| return STALE. |  | return STALE. |
| o If the cached response's age is greater than the channel's |  | o If the cached response's age is greater than the channel's |
| lifetime, return STALE. |  | lifetime, return STALE. |
| o Otherwise, return FRESH freshness=[channel-precision]. |  | o Otherwise, return FRESH freshness=[channel-precision]. |
| Author's Address |  | Author's Address |
| Mark Nottingham |  | Mark Nottingham |
| Yahoo! Inc. |  | Yahoo! Inc. |
End of changes. 27 change blocks.
| 41 lines changed or deleted |  | 61 lines changed or added |
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/