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/