draft-ietf-httpbis-p6-cache-04.txt		draft-ietf-httpbis-p6-cache-05.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: March 2, 2009 J. Mogul		Expires: May 20, 2009 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	August 29, 2008		November 16, 2008
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-04		draft-ietf-httpbis-p6-cache-05
	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 49		skipping to change at page 1, line 49
	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 March 2, 2009.		This Internet-Draft will expire on May 20, 2009.
	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. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 6 of the		information initiative since 1990. This document is Part 6 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines
	requirements on HTTP caches and the associated header fields that		requirements on HTTP caches and the associated header fields that
	control cache behavior or indicate cacheable response messages.		control cache behavior 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). The current issues list is
	at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://www.tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix B.4.		The changes in this draft are summarized in Appendix B.6.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7		1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 8		2. Notational Conventions and Generic Grammar . . . . . . . . . . 8
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Cache Correctness . . . . . . . . . . . . . . . . . . . . 8		3.1. Cache Correctness . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 4, line 21		skipping to change at page 4, line 21
	Appendix A. Compatibility with Previous Versions . . . . . . . . 44		Appendix A. Compatibility with Previous Versions . . . . . . . . 44
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 45		publication) . . . . . . . . . . . . . . . . . . . . 45
	B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 45		B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 45
	B.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 45		B.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 45
	B.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 46		B.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 46
	B.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 46		B.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 46
	B.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 46		B.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 46
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		B.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 47
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
	Intellectual Property and Copyright Statements . . . . . . . . . . 52		Intellectual Property and Copyright Statements . . . . . . . . . . 52
	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, and		performance can be improved by the use of response caches, and
	includes a number of elements intended to make caching work as well		includes a number of elements intended to make caching work as well
	as possible. Because these elements interact with each other, it is		as possible. Because these elements interact with each other, it is
	useful to describe the caching design of HTTP separately. This		useful to describe the caching design of HTTP separately. This
	skipping to change at page 8, line 10		skipping to change at page 8, line 10
	REQUIRED level and all the SHOULD level requirements for its		REQUIRED level and all the SHOULD level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the MUST level requirements but not all the SHOULD
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant."
	2. Notational Conventions and Generic Grammar		2. Notational Conventions and Generic Grammar
	This specification uses the ABNF syntax defined in Section 2.1 of		This specification uses the ABNF syntax defined in Section 2.1 of
	[Part1] and the core rules defined in Section 2.2 of [Part1]:		[Part1] and the core rules defined in Section 2.2 of [Part1]:
	[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
	5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
	DIGIT = <DIGIT, defined in [Part1], Section 2.2>		DIGIT = <DIGIT, defined in [Part1], Section 2.2>
	DQUOTE = <DQUOTE, defined in [Part1], Section 2.2>		DQUOTE = <DQUOTE, defined in [Part1], Section 2.2>
	SP = <SP, defined in [Part1], Section 2.2>		SP = <SP, defined in [Part1], Section 2.2>
	quoted-string = <quoted-string, defined in [Part1], Section 2.2>		quoted-string = <quoted-string, defined in [Part1], Section 2.2>
	token = <token, defined in [Part1], Section 2.2>		token = <token, defined in [Part1], Section 2.2>
			OWS = <OWS, defined in [Part1], Section 2.2>
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	field-name = <field-name, defined in [Part1], Section 4.2>		field-name = <field-name, defined in [Part1], Section 4.2>
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
	port = <port, defined in [Part1], Section 3.2.1>		port = <port, defined in [Part1], Section 3.2>
	pseudonym = <pseudonym, defined in [Part1], Section 8.9>		pseudonym = <pseudonym, defined in [Part1], Section 8.9>
	uri-host = <uri-host, defined in [Part1], Section 3.2.1>		uri-host = <uri-host, defined in [Part1], Section 3.2>
	3. Overview		3. Overview
	3.1. Cache Correctness		3.1. Cache Correctness
	A correct cache MUST respond to a request with the most up-to-date		A correct cache MUST respond to a request with the most up-to-date
	response held by the cache that is appropriate to the request (see		response held by the cache that is appropriate to the request (see
	Sections 4.5, 4.6, and 14) which meets one of the following		Sections 4.5, 4.6, and 14) which meets one of the following
	conditions:		conditions:
	skipping to change at page 27, line 16		skipping to change at page 27, line 16
	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.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	16.1. Age		16.1. Age
	The Age response-header field conveys the sender's estimate of the		The response-header field "Age" conveys the sender's estimate of the
	amount of time since the response (or its revalidation) was generated		amount of time since the response (or its revalidation) was generated
	at the origin server. A cached response is "fresh" if its age does		at the origin server. A cached response is "fresh" if its age does
	not exceed its freshness lifetime. Age values are calculated as		not exceed its freshness lifetime. Age values are calculated as
	specified in Section 4.3.		specified in Section 4.3.
	Age = "Age" ":" age-value		Age = "Age" ":" OWS Age-v
	age-value = delta-seconds		Age-v = delta-seconds
	Age values are non-negative decimal integers, representing time in		Age values are non-negative decimal 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 with a value of 2147483648 (2^31). An		MUST transmit an Age header with a value of 2147483648 (2^31). An
	HTTP/1.1 server that includes a cache MUST include an Age header		HTTP/1.1 server that includes a cache MUST include an Age header
	field in every response generated from its own cache. Caches SHOULD		field in every response generated from its own cache. Caches SHOULD
	use an arithmetic type of at least 31 bits of range.		use an arithmetic type of at least 31 bits of range.
	16.2. Cache-Control		16.2. Cache-Control
	The Cache-Control general-header field is used to specify directives		The general-header field "Cache-Control" is used to specify
	that MUST be obeyed by all caching mechanisms along the request/		directives that MUST be obeyed by all caching mechanisms along the
	response chain. The directives specify behavior intended to prevent		request/response chain. The directives specify behavior intended to
	caches from adversely interfering with the request or response.		prevent caches from adversely interfering with the request or
	These directives typically override the default caching algorithms.		response. These directives typically override the default caching
	Cache directives are unidirectional in that the presence of a		algorithms. Cache directives are unidirectional in that the presence
	directive in a request does not imply that the same directive is to		of a directive in a request does not imply that the same directive is
	be given in the response.		to be given in the response.
	Note that HTTP/1.0 caches might not implement Cache-Control and		Note that HTTP/1.0 caches might not implement Cache-Control and
	might only implement Pragma: no-cache (see Section 16.4).		might only implement Pragma: no-cache (see Section 16.4).
	Cache directives MUST be passed through by a proxy or gateway		Cache directives MUST be passed through by a proxy or gateway
	application, regardless of their significance to that application,		application, regardless of their significance to that application,
	since the directives might be applicable to all recipients along the		since the directives might be applicable to all recipients along the
	request/response chain. It is not possible to specify a cache-		request/response chain. It is not possible to specify a cache-
	directive for a specific cache.		directive for a specific cache.
	Cache-Control = "Cache-Control" ":" 1#cache-directive		Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
			Cache-Control-v = 1#cache-directive
	cache-directive = cache-request-directive		cache-directive = cache-request-directive
	| cache-response-directive		/ cache-response-directive
	cache-request-directive =		cache-request-directive =
	"no-cache" ; Section 16.2.1		"no-cache" ; Section 16.2.1
	| "no-store" ; Section 16.2.2		/ "no-store" ; Section 16.2.2
	| "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4		/ "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4
	| "max-stale" [ "=" delta-seconds ] ; Section 16.2.3		/ "max-stale" [ "=" delta-seconds ] ; Section 16.2.3
	| "min-fresh" "=" delta-seconds ; Section 16.2.3		/ "min-fresh" "=" delta-seconds ; Section 16.2.3
	| "no-transform" ; Section 16.2.5		/ "no-transform" ; Section 16.2.5
	| "only-if-cached" ; Section 16.2.4		/ "only-if-cached" ; Section 16.2.4
	| cache-extension ; Section 16.2.6		/ cache-extension ; Section 16.2.6
	cache-response-directive =		cache-response-directive =
	"public" ; Section 16.2.1		"public" ; Section 16.2.1
	| "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1		/ "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
	| "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1		/ "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
	| "no-store" ; Section 16.2.2		/ "no-store" ; Section 16.2.2
	| "no-transform" ; Section 16.2.5		/ "no-transform" ; Section 16.2.5
	| "must-revalidate" ; Section 16.2.4		/ "must-revalidate" ; Section 16.2.4
	| "proxy-revalidate" ; Section 16.2.4		/ "proxy-revalidate" ; Section 16.2.4
	| "max-age" "=" delta-seconds ; Section 16.2.3		/ "max-age" "=" delta-seconds ; Section 16.2.3
	| "s-maxage" "=" delta-seconds ; Section 16.2.3		/ "s-maxage" "=" delta-seconds ; Section 16.2.3
	| cache-extension ; Section 16.2.6		/ cache-extension ; Section 16.2.6
	cache-extension = token [ "=" ( token | quoted-string ) ]		cache-extension = token [ "=" ( token / quoted-string ) ]
	When a directive appears without any 1#field-name parameter, the		When a directive appears without any 1#field-name parameter, the
	directive applies to the entire request or response. When such a		directive applies to the entire request or response. When such a
	directive appears with a 1#field-name parameter, it applies only to		directive appears with a 1#field-name parameter, it applies only to
	the named field or fields, and not to the rest of the request or		the named field or fields, and not to the rest of the request or
	response. This mechanism supports extensibility; implementations of		response. This mechanism supports extensibility; implementations of
	future versions of HTTP might apply these directives to header fields		future versions of HTTP might apply these directives to header fields
	not defined in HTTP/1.1.		not defined in HTTP/1.1.
	The cache-control directives can be broken down into these general		The cache-control directives can be broken down into these general
	skipping to change at page 37, line 24		skipping to change at page 37, line 24
	intermediate cache that has a fresh copy of the entity). See		intermediate cache that has a fresh copy of the entity). See
	Section 4 for further discussion of the expiration model.		Section 4 for further discussion of the expiration 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 format is an absolute date and time as defined by HTTP-date in		The format is an absolute date and time as defined by HTTP-date in
	Section 3.3.1 of [Part1]; it MUST be sent in rfc1123-date format.		Section 3.3.1 of [Part1]; it MUST be sent in rfc1123-date format.
	Expires = "Expires" ":" HTTP-date		Expires = "Expires" ":" OWS Expires-v
			Expires-v = HTTP-date
	An example of its use is		An example of its use is
	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 16.2.3), that directive overrides the		age directive (see Section 16.2.3), that directive overrides the
	Expires field.		Expires field.
	HTTP/1.1 clients and caches MUST treat other invalid date formats,		HTTP/1.1 clients and caches MUST treat other invalid date formats,
	skipping to change at page 38, line 7		skipping to change at page 38, line 7
	sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one		sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
	year in the future.		year in the future.
	The presence of an Expires header field with a date value of some		The presence of an Expires header field with a date value of some
	time in the future on a response that otherwise would by default be		time in the future on a response that otherwise would by default be
	non-cacheable indicates that the response is cacheable, unless		non-cacheable indicates that the response is cacheable, unless
	indicated otherwise by a Cache-Control header field (Section 16.2).		indicated otherwise by a Cache-Control header field (Section 16.2).
	16.4. Pragma		16.4. Pragma
	The Pragma general-header field is used to include implementation-		The general-header field "Pragma" is used to include implementation-
	specific directives that might apply to any recipient along the		specific directives that might apply to any recipient along the
	request/response chain. All pragma directives specify optional		request/response chain. All pragma directives specify optional
	behavior from the viewpoint of the protocol; however, some systems		behavior from the viewpoint of the protocol; however, some systems
	MAY require that behavior be consistent with the directives.		MAY require that behavior be consistent with the directives.
	Pragma = "Pragma" ":" 1#pragma-directive		Pragma = "Pragma" ":" OWS Pragma-v
	pragma-directive = "no-cache" | extension-pragma		Pragma-v = 1#pragma-directive
	extension-pragma = token [ "=" ( token | quoted-string ) ]		pragma-directive = "no-cache" / extension-pragma
			extension-pragma = token [ "=" ( token / quoted-string ) ]
	When the no-cache directive is present in a request message, an		When the no-cache directive is present in a request message, an
	application SHOULD forward the request toward the origin server even		application SHOULD forward the request toward the origin server even
	if it has a cached copy of what is being requested. This pragma		if it has a cached copy of what is being requested. This pragma
	directive has the same semantics as the no-cache cache-directive (see		directive has the same semantics as the no-cache cache-directive (see
	Section 16.2) and is defined here for backward compatibility with		Section 16.2) and is defined here for backward compatibility with
	HTTP/1.0. Clients SHOULD include both header fields when a no-cache		HTTP/1.0. Clients SHOULD include both header fields when a no-cache
	request is sent to a server not known to be HTTP/1.1 compliant.		request is sent to a server not known to be HTTP/1.1 compliant.
	Pragma directives MUST be passed through by a proxy or gateway		Pragma directives MUST be passed through by a proxy or gateway
	skipping to change at page 38, line 42		skipping to change at page 38, line 43
	HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had		HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
	sent "Cache-Control: no-cache". No new Pragma directives will be		sent "Cache-Control: no-cache". No new Pragma directives will be
	defined in HTTP.		defined in HTTP.
	Note: because the meaning of "Pragma: no-cache" as a response-		Note: because the meaning of "Pragma: no-cache" as a response-
	header field is not actually specified, it does not provide a		header field is not actually specified, it does not provide a
	reliable replacement for "Cache-Control: no-cache" in a response.		reliable replacement for "Cache-Control: no-cache" in a response.
	16.5. Vary		16.5. Vary
	The Vary response-header field's value indicates the set of request-		The "Vary" response-header field's value indicates the set of
	header fields that fully determines, while the response is fresh,		request-header fields that fully determines, while the response is
	whether a cache is permitted to use the response to reply to a		fresh, whether a cache is permitted to use the response to reply to a
	subsequent request without revalidation. For uncacheable or stale		subsequent request without revalidation. For uncacheable or stale
	responses, the Vary field value advises the user agent about the		responses, the Vary field value advises the user agent about the
	criteria that were used to select the representation. A Vary field		criteria that were used to select the representation. A Vary field
	value of "*" implies that a cache cannot determine from the request		value of "*" implies that a cache cannot determine from the request
	headers of a subsequent request whether this response is the		headers of a subsequent request whether this response is the
	appropriate representation. See Section 8 for use of the Vary header		appropriate representation. See Section 8 for use of the Vary header
	field by caches.		field by caches.
	Vary = "Vary" ":" ( "*" | 1#field-name )		Vary = "Vary" ":" OWS Vary-v
			Vary-v = "*" / 1#field-name
	An HTTP/1.1 server SHOULD include a Vary header field with any		An HTTP/1.1 server SHOULD include a Vary header field with any
	cacheable response that is subject to server-driven negotiation.		cacheable response that is subject to server-driven negotiation.
	Doing so allows a cache to properly interpret future requests on that		Doing so allows a cache to properly interpret future requests on that
	resource and informs the user agent about the presence of negotiation		resource and informs the user agent about the presence of negotiation
	on that resource. A server MAY include a Vary header field with a		on that resource. A server MAY include a Vary header field with a
	non-cacheable response that is subject to server-driven negotiation,		non-cacheable response that is subject to server-driven negotiation,
	since this might provide the user agent with useful information about		since this might provide the user agent with useful information about
	the dimensions over which the response varies at the time of the		the dimensions over which the response varies at the time of the
	response.		response.
	skipping to change at page 39, line 37		skipping to change at page 39, line 38
	insensitive.		insensitive.
	A Vary field value of "*" signals that unspecified parameters not		A Vary field value of "*" signals that unspecified parameters not
	limited to the request-headers (e.g., the network address of the		limited to the request-headers (e.g., the network address of the
	client), play a role in the selection of the response representation.		client), play a role in the selection of the response representation.
	The "*" value MUST NOT be generated by a proxy server; it may only be		The "*" value MUST NOT be generated by a proxy server; it may only be
	generated by an origin server.		generated by an origin server.
	16.6. Warning		16.6. Warning
	The Warning general-header field is used to carry additional		The general-header field "Warning" is used to carry additional
	information about the status or transformation of a message which		information about the status or transformation of a message which
	might not be reflected in the message. This information is typically		might not be reflected in the message. This information is typically
	used to warn about a possible lack of semantic transparency from		used to warn about a possible lack of semantic transparency from
	caching operations or transformations applied to the entity body of		caching operations or transformations applied to the entity body of
	the message.		the message.
	Warning headers are sent with responses using:		Warning headers are sent with responses using:
	Warning = "Warning" ":" 1#warning-value		Warning = "Warning" ":" OWS Warning-v
			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, for use in debugging		; the Warning header, for use in debugging
	warn-text = quoted-string		warn-text = quoted-string
	warn-date = DQUOTE HTTP-date DQUOTE		warn-date = DQUOTE HTTP-date DQUOTE
	A response MAY carry more than one Warning header.		A response MAY carry more than one Warning header.
	The warn-text SHOULD be in a natural language and character set that		The warn-text SHOULD be in a natural language and character set that
	is most likely to be intelligible to the human user receiving the		is most likely to be intelligible to the human user receiving the
	response. This decision MAY be based on any available knowledge,		response. This decision MAY be based on any available knowledge,
	skipping to change at page 43, line 27		skipping to change at page 43, line 29
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		IEC 8859-1:1998, 1998.
	[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-04		and Message Parsing", draft-ietf-httpbis-p1-messaging-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[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-04 (work in		Semantics", draft-ietf-httpbis-p2-semantics-05 (work in
	progress), August 2008.		progress), November 2008.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] 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 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-04		and Content Negotiation", draft-ietf-httpbis-p3-payload-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[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-04 (work in		Requests", draft-ietf-httpbis-p4-conditional-05 (work in
	progress), August 2008.		progress), November 2008.
	[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-04 (work		Partial Responses", draft-ietf-httpbis-p5-range-05 (work
	in progress), August 2008.		in progress), November 2008.
	[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-04 (work in progress),		draft-ietf-httpbis-p7-auth-05 (work in progress),
	August 2008.		November 2008.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)		[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	Part Three: Message Header Extensions for Non-ASCII Text",		Part Three: Message Header Extensions for Non-ASCII Text",
	RFC 2047, November 1996.		RFC 2047, November 1996.
	[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.
	20.2. Informative References		20.2. Informative References
	skipping to change at page 45, line 30		skipping to change at page 45, line 31
	Appendix B. Change Log (to be removed by RFC Editor before publication)		Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1. Since RFC2616		B.1. Since RFC2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	B.2. Since draft-ietf-httpbis-p6-cache-00		B.2. Since draft-ietf-httpbis-p6-cache-00
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer"		o <http://tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer"
	(<http://purl.org/NET/http-errata#trailer-hop>)		(<http://purl.org/NET/http-errata#trailer-hop>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/12>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/12>: "Invalidation
	"Invalidation after Update or Delete"		after Update or Delete"
	(<http://purl.org/NET/http-errata#invalidupd>)		(<http://purl.org/NET/http-errata#invalidupd>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative		o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	and Informative references"		Informative references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date		o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
	reference typo"		typo"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/49>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/49>: "Connection
	"Connection header text"		header text"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
	"Informative references"		references"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
			Reference"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
	"ISO-8859-1 Reference"		to-date references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
	up-to-date references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in		o <http://tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in
	13.2.2"		13.2.2"
	Other changes:		Other changes:
	o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress		o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress
	on <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)		on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
	B.3. Since draft-ietf-httpbis-p6-cache-01		B.3. Since draft-ietf-httpbis-p6-cache-01
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path		o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
	not used"		used"
	Other changes:		Other changes:
	o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work		o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work
	in progress on		in progress on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
	<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	B.4. Since draft-ietf-httpbis-p6-cache-02		B.4. Since draft-ietf-httpbis-p6-cache-02
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Registration
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header registrations for headers
	defined in this document.		defined in this document.
	B.5. Since draft-ietf-httpbis-p6-cache-03		B.5. Since draft-ietf-httpbis-p6-cache-03
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary		o <http://tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary header
	header classification"		classification"
			B.6. Since draft-ietf-httpbis-p6-cache-04
			Ongoing work on ABNF conversion
			(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Use "/" instead of "|" for alternatives.
			o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
			whitespace ("OWS") and required whitespace ("RWS").
			o Rewrite ABNFs to spell out whitespace rules, factor out header
			value format definitions.
	Index		Index
	A		A
	age 7		age 7
	Age header 27		Age header 27
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 32-33		max-age 32-33
	max-stale 32		max-stale 32
	min-fresh 32		min-fresh 32
	must-revalidate 34		must-revalidate 34
	no-cache 29		no-cache 29
	no-store 30		no-store 30
	no-transform 35		no-transform 35
	skipping to change at page 47, line 34		skipping to change at page 48, line 6
	explicit expiration time 7		explicit expiration time 7
	F		F
	first-hand 6		first-hand 6
	fresh 7		fresh 7
	freshness lifetime 7		freshness lifetime 7
	G		G
	Grammar		Grammar
	Age 27		Age 27
	age-value 27		Age-v 27
	Cache-Control 28		Cache-Control 28
			Cache-Control-v 28
	cache-directive 28		cache-directive 28
	cache-extension 28		cache-extension 28
	cache-request-directive 28		cache-request-directive 28
	cache-response-directive 28		cache-response-directive 28
	delta-seconds 27		delta-seconds 27
	Expires 37		Expires 37
			Expires-v 37
	extension-pragma 38		extension-pragma 38
	Pragma 38		Pragma 38
	pragma-directive 38		pragma-directive 38
	Vary 38		Pragma-v 38
			Vary 39
			Vary-v 39
	warn-agent 40		warn-agent 40
	warn-code 40		warn-code 40
	warn-date 40		warn-date 40
	warn-text 40		warn-text 40
	Warning 40		Warning 40
			Warning-v 40
	warning-value 40		warning-value 40
	H		H
	Headers		Headers
	Age 27		Age 27
	Cache-Control 27		Cache-Control 27
	Expires 37		Expires 37
	Pragma 38		Pragma 38
	Vary 38		Vary 38
	Warning 39		Warning 39
	heuristic expiration time 7		heuristic expiration time 7
End of changes. 54 change blocks.
	92 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/