draft-ietf-httpbis-p6-cache-13.txt		draft-ietf-httpbis-p6-cache-14.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: September 15, 2011 J. Mogul		Expires: October 20, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	M. Nottingham, Ed.		M. Nottingham, Ed.
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 14, 2011		April 18, 2011
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-13		draft-ietf-httpbis-p6-cache-14
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. This document is Part 6 of the seven-part specification		systems. This document is Part 6 of the seven-part specification
	that defines the protocol referred to as "HTTP/1.1" and, taken		that defines the protocol referred to as "HTTP/1.1" and, taken
	together, obsoletes RFC 2616. Part 6 defines requirements on HTTP		together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
	caches and the associated header fields that control cache behavior		caches and the associated header fields that control cache behavior
	or indicate cacheable response messages.		or indicate cacheable response messages.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org), which is archived at
	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
			The current issues list is at
			<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.14.		The changes in this draft are summarized in Appendix C.15.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 2, line 17		skipping to change at page 2, line 20
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on September 15, 2011.		This Internet-Draft will expire on October 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 10		skipping to change at page 4, line 12
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37
	C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37		C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37
	C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38		C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38
	C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38		C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38
	C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38		C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38
			C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	HTTP is typically used for distributed information systems, where		HTTP is typically used for distributed information systems, where
	performance can be improved by the use of response caches. This		performance can be improved by the use of response caches. This
	document defines aspects of HTTP/1.1 related to caching and reusing		document defines aspects of HTTP/1.1 related to caching and reusing
	response messages.		response messages.
	1.1. Purpose		1.1. Purpose
	skipping to change at page 10, line 13		skipping to change at page 10, line 13
	request and having received a corresponding response.		request and having received a corresponding response.
	Also, note that unsafe requests might invalidate already stored		Also, note that unsafe requests might invalidate already stored
	responses; see Section 2.5.		responses; see Section 2.5.
	A cache MUST use the most recent response (as determined by the Date		A cache MUST use the most recent response (as determined by the Date
	header field) when more than one suitable response is stored. It can		header field) when more than one suitable response is stored. It can
	also forward a request with "Cache-Control: max-age=0" or "Cache-		also forward a request with "Cache-Control: max-age=0" or "Cache-
	Control: no-cache" to disambiguate which response to use.		Control: no-cache" to disambiguate which response to use.
	A cache that does not have a clock available MUST NOT used stored		A cache that does not have a clock available MUST NOT use stored
	responses without revalidating them on every use. A cache,		responses without revalidating them on every use. A cache,
	especially a shared cache, SHOULD use a mechanism, such as NTP		especially a shared cache, SHOULD use a mechanism, such as NTP
	[RFC1305], to synchronize its clock with a reliable external		[RFC1305], to synchronize its clock with a reliable external
	standard.		standard.
	2.3. Freshness Model		2.3. Freshness Model
	When a response is "fresh" in the cache, it can be used to satisfy		When a response is "fresh" in the cache, it can be used to satisfy
	subsequent requests without contacting the origin server, thereby		subsequent requests without contacting the origin server, thereby
	improving efficiency.		improving efficiency.
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	used (including the following in Section 8 of [Part2]: 200, 203, 206,		used (including the following in Section 8 of [Part2]: 200, 203, 206,
	300, 301 and 410), a cache MAY calculate a heuristic expiration time.		300, 301 and 410), a cache MAY calculate a heuristic expiration time.
	A cache MUST NOT use heuristics to determine freshness for responses		A cache MUST NOT use heuristics to determine freshness for responses
	with status codes that do not explicitly allow it.		with status codes that do not explicitly allow it.
	When a heuristic is used to calculate freshness lifetime, a cache		When a heuristic is used to calculate freshness lifetime, a cache
	SHOULD attach a Warning header field with a 113 warn-code to the		SHOULD attach a Warning header field with a 113 warn-code to the
	response if its current_age is more than 24 hours and such a warning		response if its current_age is more than 24 hours and such a warning
	is not already present.		is not already present.
	Also, if the response has a Last-Modified header field (Section 6.6		Also, if the response has a Last-Modified header field (Section 2.1
	of [Part4]), a cache SHOULD NOT use a heuristic expiration value that		of [Part4]), a cache SHOULD NOT use a heuristic expiration value that
	is more than some fraction of the interval since that time. A		is more than some fraction of the interval since that time. A
	typical setting of this fraction might be 10%.		typical setting of this fraction might be 10%.
	Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do		Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
	not calculate heuristic freshness for URIs with query components		not calculate heuristic freshness for URIs with query components
	(i.e., those containing '?'). In practice, this has not been		(i.e., those containing '?'). In practice, this has not been
	widely implemented. Therefore, servers are encouraged to send		widely implemented. Therefore, servers are encouraged to send
	explicit directives (e.g., Cache-Control: no-cache) if they wish		explicit directives (e.g., Cache-Control: no-cache) if they wish
	to preclude caching.		to preclude caching.
	skipping to change at page 14, line 9		skipping to change at page 14, line 9
	according to the calculations in Section 2.3.		according to the calculations in Section 2.3.
	A cache MUST NOT return a stale response if it is prohibited by an		A cache MUST NOT return a stale response if it is prohibited by an
	explicit in-protocol directive (e.g., by a "no-store" or "no-cache"		explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
	cache directive, a "must-revalidate" cache-response-directive, or an		cache directive, a "must-revalidate" cache-response-directive, or an
	applicable "s-maxage" or "proxy-revalidate" cache-response-directive;		applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
	see Section 3.2.2).		see Section 3.2.2).
	A cache SHOULD NOT return stale responses unless it is disconnected		A cache SHOULD NOT return stale responses unless it is disconnected
	(i.e., it cannot contact the origin server or otherwise find a		(i.e., it cannot contact the origin server or otherwise find a
	forward path) or otherwise explicitly allowed (e.g., the max-stale		forward path) or doing so is explicitly allowed (e.g., by the max-
	request directive; see Section 3.2.1).		stale request directive; see Section 3.2.1).
	A cache SHOULD append a Warning header field with the 110 warn-code		A cache SHOULD append a Warning header field with the 110 warn-code
	(see Section 3.6) to stale responses. Likewise, a cache SHOULD add		(see Section 3.6) to stale responses. Likewise, a cache SHOULD add
	the 112 warn-code to stale responses if the cache is disconnected.		the 112 warn-code to stale responses if the cache is disconnected.
	If a cache receives a first-hand response (either an entire response,		If a cache receives a first-hand response (either an entire response,
	or a 304 (Not Modified) response) that it would normally forward to		or a 304 (Not Modified) response) that it would normally forward to
	the requesting client, and the received response is no longer fresh,		the requesting client, and the received response is no longer fresh,
	the cache SHOULD forward it to the requesting client without adding a		the cache SHOULD forward it to the requesting client without adding a
	new Warning (but without removing any existing Warning header		new Warning (but without removing any existing Warning header
	skipping to change at page 17, line 26		skipping to change at page 17, line 26
	If the new response contains an ETag, it identifies the stored		If the new response contains an ETag, it identifies the stored
	response to use. [[TODO-mention-CL: might need language about		response to use. [[TODO-mention-CL: might need language about
	Content-Location here]][[TODO-select-for-combine: Shouldn't this be		Content-Location here]][[TODO-select-for-combine: Shouldn't this be
	the selected response?]]		the selected response?]]
	When the new response's status code is 206 (partial content), a cache		When the new response's status code is 206 (partial content), a cache
	MUST NOT combine it with the old response if either response does not		MUST NOT combine it with the old response if either response does not
	have a validator, and MUST NOT combine it with the old response when		have a validator, and MUST NOT combine it with the old response when
	those validators do not match with the strong comparison function		those validators do not match with the strong comparison function
	(see Section 4 of [Part4]).		(see Section 2.2.2 of [Part4]).
	The stored response header fields are used as those of the updated		The stored response header fields are used as those of the updated
	response, except that		response, except that
	o a cache MUST delete any stored Warning header fields with warn-		o a cache MUST delete any stored Warning header fields with warn-
	code 1xx (see Section 3.6).		code 1xx (see Section 3.6).
	o a cache MUST retain any stored Warning header fields with warn-		o a cache MUST retain any stored Warning header fields with warn-
	code 2xx.		code 2xx.
	skipping to change at page 18, line 12		skipping to change at page 18, line 12
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to caching.		fields related to caching.
	3.1. Age		3.1. Age
	The "Age" header field conveys the sender's estimate of the amount of		The "Age" header field conveys the sender's estimate of the amount of
	time since the response was generated or successfully validated at		time since the response was generated or successfully validated at
	the origin server. Age values are calculated as specified in		the origin server. Age values are calculated as specified in
	Section 2.3.2.		Section 2.3.2.
	Age = "Age" ":" OWS Age-v		Age = delta-seconds
	Age-v = delta-seconds
	Age field-values are non-negative integers, representing time in		Age field-values are non-negative integers, representing time in
	seconds.		seconds.
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	If a cache receives a value larger than the largest positive integer		If a cache receives a value larger than the largest positive integer
	it can represent, or if any of its age calculations overflows, it		it can represent, or if any of its age calculations overflows, it
	MUST transmit an Age header field with a field-value of 2147483648		MUST transmit an Age header field with a field-value of 2147483648
	(2^31). Recipients parsing the Age header field-value SHOULD use an		(2^31). Recipients parsing the Age header field-value SHOULD use an
	skipping to change at page 19, line 5		skipping to change at page 19, line 5
	Note: HTTP/1.0 caches might not implement Cache-Control and might		Note: HTTP/1.0 caches might not implement Cache-Control and might
	only implement Pragma: no-cache (see Section 3.4).		only implement Pragma: no-cache (see Section 3.4).
	A proxy, whether or not it implements a cache, MUST pass cache		A proxy, whether or not it implements a cache, MUST pass cache
	directives through in forwarded messages, regardless of their		directives through in forwarded messages, regardless of their
	significance to that application, since the directives might be		significance to that application, since the directives might be
	applicable to all recipients along the request/response chain. It is		applicable to all recipients along the request/response chain. It is
	not possible to target a directive to a specific cache.		not possible to target a directive to a specific cache.
	Cache-Control = "Cache-Control" ":" OWS Cache-Control-v		Cache-Control = 1#cache-directive
	Cache-Control-v = 1#cache-directive
	cache-directive = cache-request-directive		cache-directive = cache-request-directive
	/ cache-response-directive		/ cache-response-directive
	cache-extension = token [ "=" ( token / quoted-string ) ]		cache-extension = token [ "=" ( token / quoted-string ) ]
	3.2.1. Request Cache-Control Directives		3.2.1. Request Cache-Control Directives
	cache-request-directive =		cache-request-directive =
	"no-cache"		"no-cache"
	skipping to change at page 23, line 13		skipping to change at page 23, line 13
	transaction.		transaction.
	proxy-revalidate		proxy-revalidate
	The proxy-revalidate response directive has the same meaning as		The proxy-revalidate response directive has the same meaning as
	the must-revalidate response directive, except that it does not		the must-revalidate response directive, except that it does not
	apply to private caches.		apply to private caches.
	max-age		max-age
	The max-age response directive indicates that response is to be		The max-age response directive indicates that the response is to
	considered stale after its age is greater than the specified		be considered stale after its age is greater than the specified
	number of seconds.		number of seconds.
	s-maxage		s-maxage
	The s-maxage response directive indicates that, in shared caches,		The s-maxage response directive indicates that, in shared caches,
	the maximum age specified by this directive overrides the maximum		the maximum age specified by this directive overrides the maximum
	age specified by either the max-age directive or the Expires		age specified by either the max-age directive or the Expires
	header field. The s-maxage directive also implies the semantics		header field. The s-maxage directive also implies the semantics
	of the proxy-revalidate response directive.		of the proxy-revalidate response directive.
	skipping to change at page 25, line 6		skipping to change at page 25, line 6
	response is considered stale. See Section 2.3 for further discussion		response is considered stale. See Section 2.3 for further discussion
	of the freshness model.		of the freshness model.
	The presence of an Expires field does not imply that the original		The presence of an Expires field does not imply that the original
	resource will change or cease to exist at, before, or after that		resource will change or cease to exist at, before, or after that
	time.		time.
	The field-value is an absolute date and time as defined by HTTP-date		The field-value is an absolute date and time as defined by HTTP-date
	in Section 6.1 of [Part1]; a sender MUST use the rfc1123-date format.		in Section 6.1 of [Part1]; a sender MUST use the rfc1123-date format.
	Expires = "Expires" ":" OWS Expires-v		Expires = HTTP-date
	Expires-v = HTTP-date
	For example		For example
	Expires: Thu, 01 Dec 1994 16:00:00 GMT		Expires: Thu, 01 Dec 1994 16:00:00 GMT
	Note: If a response includes a Cache-Control field with the max-		Note: If a response includes a Cache-Control field with the max-
	age directive (see Section 3.2.2), that directive overrides the		age directive (see Section 3.2.2), that directive overrides the
	Expires field. Likewise, the s-maxage directive overrides Expires		Expires field. Likewise, the s-maxage directive overrides Expires
	in shared caches.		in shared caches.
	skipping to change at page 25, line 32		skipping to change at page 25, line 31
	the value "0", as in the past (i.e., "already expired").		the value "0", as in the past (i.e., "already expired").
	3.4. Pragma		3.4. Pragma
	The "Pragma" header field is used to include implementation-specific		The "Pragma" header field is used to include implementation-specific
	directives that might apply to any recipient along the request/		directives that might apply to any recipient along the request/
	response chain. All pragma directives specify optional behavior from		response chain. All pragma directives specify optional behavior from
	the viewpoint of the protocol; however, some systems MAY require that		the viewpoint of the protocol; however, some systems MAY require that
	behavior be consistent with the directives.		behavior be consistent with the directives.
	Pragma = "Pragma" ":" OWS Pragma-v		Pragma = 1#pragma-directive
	Pragma-v = 1#pragma-directive		pragma-directive = "no-cache" / extension-pragma
	pragma-directive = "no-cache" / extension-pragma		extension-pragma = token [ "=" ( token / quoted-string ) ]
	extension-pragma = token [ "=" ( token / quoted-string ) ]
	When the no-cache directive is present in a request message, a cache		When the no-cache directive is present in a request message, a cache
	SHOULD forward the request toward the origin server even if it has a		SHOULD forward the request toward the origin server even if it has a
	stored copy of what is being requested. This pragma directive has		stored copy of what is being requested. This pragma directive has
	the same semantics as the no-cache response directive (see		the same semantics as the no-cache response directive (see
	Section 3.2.2) and is defined here for backward compatibility with		Section 3.2.2) and is defined here for backward compatibility with
	HTTP/1.0. A client SHOULD include both header fields when a no-cache		HTTP/1.0. A client SHOULD include both header fields when a no-cache
	request is sent to a server not known to be HTTP/1.1 compliant. A		request is sent to a server not known to be HTTP/1.1 compliant. A
	cache SHOULD treat "Pragma: no-cache" as if the client had sent		cache SHOULD treat "Pragma: no-cache" as if the client had sent
	"Cache-Control: no-cache".		"Cache-Control: no-cache".
	skipping to change at page 26, line 21		skipping to change at page 26, line 20
	Caches use this information, in part, to determine whether a stored		Caches use this information, in part, to determine whether a stored
	response can be used to satisfy a given request; see Section 2.7.		response can be used to satisfy a given request; see Section 2.7.
	determines, while the response is fresh, whether a cache is permitted		determines, while the response is fresh, whether a cache is permitted
	to use the response to reply to a subsequent request without		to use the response to reply to a subsequent request without
	validation; see Section 2.7.		validation; see Section 2.7.
	In uncacheable or stale responses, the Vary field value advises the		In uncacheable or stale responses, the Vary field value advises the
	user agent about the criteria that were used to select the		user agent about the criteria that were used to select the
	representation.		representation.
	Vary = "Vary" ":" OWS Vary-v		Vary = "*" / 1#field-name
	Vary-v = "*" / 1#field-name
	The set of header fields named by the Vary field value is known as		The set of header fields named by the Vary field value is known as
	the selecting header fields.		the selecting header fields.
	A server SHOULD include a Vary header field with any cacheable		A server SHOULD include a Vary header field with any cacheable
	response that is subject to server-driven negotiation. Doing so		response that is subject to server-driven negotiation. Doing so
	allows a cache to properly interpret future requests on that resource		allows a cache to properly interpret future requests on that resource
	and informs the user agent about the presence of negotiation on that		and informs the user agent about the presence of negotiation on that
	resource. A server MAY include a Vary header field with a non-		resource. A server MAY include a Vary header field with a non-
	cacheable response that is subject to server-driven negotiation,		cacheable response that is subject to server-driven negotiation,
	skipping to change at page 27, line 15		skipping to change at page 27, line 13
	transformations applied to the payload of the message.		transformations applied to the payload of the message.
	Warnings can be used for other purposes, both cache-related and		Warnings can be used for other purposes, both cache-related and
	otherwise. The use of a warning, rather than an error status code,		otherwise. The use of a warning, rather than an error status code,
	distinguishes these responses from true failures.		distinguishes these responses from true failures.
	Warning header fields can in general be applied to any message,		Warning header fields can in general be applied to any message,
	however some warn-codes are specific to caches and can only be		however some warn-codes are specific to caches and can only be
	applied to response messages.		applied to response messages.
	Warning = "Warning" ":" OWS Warning-v		Warning = 1#warning-value
	Warning-v = 1#warning-value
	warning-value = warn-code SP warn-agent SP warn-text		warning-value = warn-code SP warn-agent SP warn-text
	[SP warn-date]		[SP warn-date]
	warn-code = 3DIGIT		warn-code = 3DIGIT
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym		warn-agent = ( uri-host [ ":" port ] ) / pseudonym
	; the name or pseudonym of the server adding		; the name or pseudonym of the server adding
	; the Warning header field, for use in debugging		; the Warning header field, for use in debugging
	warn-text = quoted-string		warn-text = quoted-string
	warn-date = DQUOTE HTTP-date DQUOTE		warn-date = DQUOTE HTTP-date DQUOTE
	skipping to change at page 31, line 18		skipping to change at page 31, line 18
	suggestions and comments from individuals including: Shel Kaphan,		suggestions and comments from individuals including: Shel Kaphan,
	Paul Leach, Koen Holtman, David Morris, and Larry Masinter.		Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-13		and Message Parsing", draft-ietf-httpbis-p1-messaging-14
	(work in progress), March 2011.		(work in progress), April 2011.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-13 (work in		Semantics", draft-ietf-httpbis-p2-semantics-14 (work in
	progress), March 2011.		progress), April 2011.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-13 (work in		Requests", draft-ietf-httpbis-p4-conditional-14 (work in
	progress), March 2011.		progress), April 2011.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-13 (work		Partial Responses", draft-ietf-httpbis-p5-range-14 (work
	in progress), March 2011.		in progress), April 2011.
	[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",		and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-13 (work in progress),		draft-ietf-httpbis-p7-auth-14 (work in progress),
	March 2011.		April 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		8.2. Informative References
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	skipping to change at page 32, line 37		skipping to change at page 32, line 37
	Make the specified age calculation algorithm less conservative.		Make the specified age calculation algorithm less conservative.
	(Section 2.3.2)		(Section 2.3.2)
	Remove requirement to consider Content-Location in successful		Remove requirement to consider Content-Location in successful
	responses in order to determine the appropriate response to use.		responses in order to determine the appropriate response to use.
	(Section 2.4)		(Section 2.4)
	Clarify denial of service attack avoidance requirement.		Clarify denial of service attack avoidance requirement.
	(Section 2.5)		(Section 2.5)
			Change ABNF productions for header fields to only define the field
			value. (Section 3)
	Do not mention RFC 2047 encoding and multiple languages in Warning		Do not mention RFC 2047 encoding and multiple languages in Warning
	header fields anymore, as these aspects never were implemented.		header fields anymore, as these aspects never were implemented.
	(Section 3.6)		(Section 3.6)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	Age = "Age:" OWS Age-v		Age = delta-seconds
	Age-v = delta-seconds
	Cache-Control = "Cache-Control:" OWS Cache-Control-v		Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
	Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS
	cache-directive ] )		cache-directive ] )
	Expires = "Expires:" OWS Expires-v		Expires = HTTP-date
	Expires-v = HTTP-date
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	Pragma = "Pragma:" OWS Pragma-v		Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	pragma-directive ] )		pragma-directive ] )
	Vary = "Vary:" OWS Vary-v		Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
	Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name		) )
	] ) )
	Warning = "Warning:" OWS Warning-v		Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
	Warning-v = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value		)
	] )
	cache-directive = cache-request-directive / cache-response-directive		cache-directive = cache-request-directive / cache-response-directive
	cache-extension = token [ "=" ( token / quoted-string ) ]		cache-extension = token [ "=" ( token / quoted-string ) ]
	cache-request-directive = "no-cache" / "no-store" / ( "max-age="		cache-request-directive = "no-cache" / "no-store" / ( "max-age="
	delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / (		delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / (
	"min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" /		"min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" /
	cache-extension		cache-extension
	cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( ","		cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( ","
	OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (		OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (
	"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS		"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS
	skipping to change at page 38, line 43		skipping to change at page 38, line 40
	C.14. Since draft-ietf-httpbis-p6-cache-12		C.14. Since draft-ietf-httpbis-p6-cache-12
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header		o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
	Classification"		Classification"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify		o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify
	'public'"		'public'"
			C.15. Since draft-ietf-httpbis-p6-cache-13
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
			ABNFs for header fields"
	Index		Index
	A		A
	age 6		age 6
	Age header field 18		Age header field 18
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 20, 23		max-age 19, 23
	max-stale 20		max-stale 20
	min-fresh 20		min-fresh 20
	must-revalidate 22		must-revalidate 22
	no-cache 19, 21		no-cache 19, 21
	no-store 19, 22		no-store 19, 22
	no-transform 20, 23		no-transform 20, 23
	only-if-cached 20		only-if-cached 20
	private 21		private 21
	proxy-revalidate 23		proxy-revalidate 23
	public 21		public 21
	skipping to change at page 39, line 30		skipping to change at page 39, line 35
	explicit expiration time 6		explicit expiration time 6
	F		F
	first-hand 6		first-hand 6
	fresh 6		fresh 6
	freshness lifetime 6		freshness lifetime 6
	G		G
	Grammar		Grammar
	Age 18		Age 18
	Age-v 18
	Cache-Control 19		Cache-Control 19
	Cache-Control-v 19
	cache-extension 19		cache-extension 19
	cache-request-directive 19		cache-request-directive 19
	cache-response-directive 21		cache-response-directive 21
	delta-seconds 18		delta-seconds 18
	Expires 25		Expires 25
	Expires-v 25
	extension-pragma 25		extension-pragma 25
	Pragma 25		Pragma 25
	pragma-directive 25		pragma-directive 25
	Pragma-v 25
	Vary 26		Vary 26
	Vary-v 26
	warn-agent 27		warn-agent 27
	warn-code 27		warn-code 27
	warn-date 27		warn-date 27
	warn-text 27		warn-text 27
	Warning 27		Warning 27
	Warning-v 27
	warning-value 27		warning-value 27
	H		H
	Header Fields		Header Fields
	Age 18		Age 18
	Cache-Control 18		Cache-Control 18
	Expires 24		Expires 24
	Pragma 25		Pragma 25
	Vary 26		Vary 26
	Warning 26		Warning 26
	heuristic expiration time 6		heuristic expiration time 6
	M		M
	max-age		max-age
	Cache Directive 20, 23		Cache Directive 19, 23
	max-stale		max-stale
	Cache Directive 20		Cache Directive 20
	min-fresh		min-fresh
	Cache Directive 20		Cache Directive 20
	must-revalidate		must-revalidate
	Cache Directive 22		Cache Directive 22
	N		N
	no-cache		no-cache
	Cache Directive 19, 21		Cache Directive 19, 21
End of changes. 40 change blocks.
	60 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/