draft-ietf-httpbis-p3-payload-15.txt		draft-ietf-httpbis-p3-payload-16.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: January 12, 2012 J. Mogul		Expires: February 25, 2012 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
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	July 11, 2011		August 24, 2011
	HTTP/1.1, part 3: Message Payload and Content Negotiation		HTTP/1.1, part 3: Message Payload and Content Negotiation
	draft-ietf-httpbis-p3-payload-15		draft-ietf-httpbis-p3-payload-16
	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, hypertext 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 3 of the		information initiative since 1990. This document is Part 3 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 3 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	HTTP message content, metadata, and content negotiation.
			Part 3 defines HTTP message content, metadata, and content
			negotiation.
	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), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<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 E.16.		The changes in this draft are summarized in Appendix E.17.
	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 January 12, 2012.		This Internet-Draft will expire on February 25, 2012.
	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 3, line 34		skipping to change at page 3, line 36
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
	6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18		6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19		6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20		6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
	6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21		6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21
	6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22		6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22
	6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23		6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23
	6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24		6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	7.1. Header Field Registration . . . . . . . . . . . . . . . . 24		7.1. Header Field Registration . . . . . . . . . . . . . . . . 25
	7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25		7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 25		8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26		8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 26		10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
	10.2. Informative References . . . . . . . . . . . . . . . . . . 28		10.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. Differences between HTTP and MIME . . . . . . . . . . 29		Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 31		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 31		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32
	Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32		Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 34		publication) . . . . . . . . . . . . . . . . . . . . 34
	E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34		E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 35		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36
	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37		E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37
	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37		E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 37		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38
	E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38		E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38
	E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38		E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38
	E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39		E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39
	E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39		E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39
	E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39		E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39
	E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40		E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40
			E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 message payloads (a.k.a., content),		This document defines HTTP/1.1 message payloads (a.k.a., content),
	the associated metadata header fields that define how the payload is		the associated metadata header fields that define how the payload is
	intended to be interpreted by a recipient, the request header fields		intended to be interpreted by a recipient, the request header fields
	that might influence content selection, and the various selection		that might influence content selection, and the various selection
	algorithms that are collectively referred to as HTTP content		algorithms that are collectively referred to as HTTP content
	negotiation.		negotiation.
	skipping to change at page 6, line 21		skipping to change at page 6, line 21
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible USASCII character),		sequence of data), SP (space), VCHAR (any visible USASCII character),
	and WSP (whitespace).		and WSP (whitespace).
	1.3.1. Core Rules		1.3.1. Core Rules
	The core rules below are defined in Section 1.2.2 of [Part1]:		The core rules below are defined in [Part1]:
	token = <token, defined in [Part1], Section 1.2.2>
	word = <word, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
			token = <token, defined in [Part1], Section 3.2.3>
			word = <word, defined in [Part1], Section 3.2.3>
	1.3.2. ABNF Rules defined in other Parts of the Specification		1.3.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	qvalue = <qvalue, defined in [Part1], Section 6.4>		qvalue = <qvalue, defined in [Part1], Section 6.4>
	2. Protocol Parameters		2. Protocol Parameters
	skipping to change at page 12, line 25		skipping to change at page 12, line 25
	The following header fields are defined as representation metadata:		The following header fields are defined as representation metadata:
	+-------------------+------------------------+		+-------------------+------------------------+
	| Header Field Name | Defined in... |		| Header Field Name | Defined in... |
	+-------------------+------------------------+		+-------------------+------------------------+
	| Content-Encoding | Section 6.5 |		| Content-Encoding | Section 6.5 |
	| Content-Language | Section 6.6 |		| Content-Language | Section 6.6 |
	| Content-Location | Section 6.7 |		| Content-Location | Section 6.7 |
	| Content-Type | Section 6.8 |		| Content-Type | Section 6.8 |
	| Expires | Section 3.3 of [Part6] |		| Expires | Section 3.3 of [Part6] |
	| Last-Modified | Section 2.1 of [Part4] |		| Last-Modified | Section 2.2 of [Part4] |
	+-------------------+------------------------+		+-------------------+------------------------+
	4.2. Representation Data		4.2. Representation Data
	The representation body associated with an HTTP message is either		The representation body associated with an HTTP message is either
	provided as the payload body of the message or referred to by the		provided as the payload body of the message or referred to by the
	message semantics and the effective request URI. The representation		message semantics and the effective request URI. The representation
	data is in a format and encoding defined by the representation		data is in a format and encoding defined by the representation
	metadata header fields.		metadata header fields.
	skipping to change at page 15, line 8		skipping to change at page 15, line 8
	can be both very inefficient (given that only a small percentage		can be both very inefficient (given that only a small percentage
	of responses have multiple representations) and a potential		of responses have multiple representations) and a potential
	violation of the user's privacy.		violation of the user's privacy.
	3. It complicates the implementation of an origin server and the		3. It complicates the implementation of an origin server and the
	algorithms for generating responses to a request.		algorithms for generating responses to a request.
	4. It might limit a public cache's ability to use the same response		4. It might limit a public cache's ability to use the same response
	for multiple user's requests.		for multiple user's requests.
			Server-driven negotiation allows the user agent to specify its
			preferences, but it cannot expect responses to always honour them.
			For example, the origin server might not implement server-driven
			negotiation, or it might decide that sending a response that doesn't
			conform to them is better than sending a 406 (Not Acceptable)
			response.
			Many of the mechanisms for expressing preferences use quality values
			to declare relative preference. See Section 6.4 of [Part1] for more
			information.
	HTTP/1.1 includes the following header fields for enabling server-		HTTP/1.1 includes the following header fields for enabling server-
	driven negotiation through description of user agent capabilities and		driven negotiation through description of user agent capabilities and
	user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2),		user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2),
	Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and		Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and
	User-Agent (Section 9.9 of [Part2]). However, an origin server is		User-Agent (Section 9.9 of [Part2]). However, an origin server is
	not limited to these dimensions and MAY vary the response based on		not limited to these dimensions and MAY vary the response based on
	any aspect of the request, including aspects of the connection (e.g.,		any aspect of the request, including aspects of the connection (e.g.,
	IP address) or information within extension header fields not defined		IP address) or information within extension header fields not defined
	by this specification.		by this specification.
	skipping to change at page 17, line 4		skipping to change at page 17, line 15
	Note: Use of the "q" parameter name to separate media type		Note: Use of the "q" parameter name to separate media type
	parameters from Accept extension parameters is due to historical		parameters from Accept extension parameters is due to historical
	practice. Although this prevents any media type parameter named		practice. Although this prevents any media type parameter named
	"q" from being used with a media range, such an event is believed		"q" from being used with a media range, such an event is believed
	to be unlikely given the lack of any "q" parameters in the IANA		to be unlikely given the lack of any "q" parameters in the IANA
	media type registry and the rare usage of any media type		media type registry and the rare usage of any media type
	parameters in Accept. Future media types are discouraged from		parameters in Accept. Future media types are discouraged from
	registering any parameter named "q".		registering any parameter named "q".
	The example		The example
	Accept: audio/*; q=0.2, audio/basic		Accept: audio/*; q=0.2, audio/basic
	SHOULD be interpreted as "I prefer audio/basic, but send me any audio		SHOULD be interpreted as "I prefer audio/basic, but send me any audio
	type if it is the best available after an 80% mark-down in quality".		type if it is the best available after an 80% mark-down in quality".
	If no Accept header field is present, then it is assumed that the		If no Accept header field is present, then it is assumed that the
	client accepts all media types. If an Accept header field is		client accepts all media types. If an Accept header field is present
	present, and if the server cannot send a response which is acceptable		in a request, but the server cannot send a response which is
	according to the combined Accept field value, then the server SHOULD		acceptable, then the server can either send a response in another
	send a 406 (Not Acceptable) response.		format, or a 406 (Not Acceptable) response.
	A more elaborate example is		A more elaborate example is
	Accept: text/plain; q=0.5, text/html,		Accept: text/plain; q=0.5, text/html,
	text/x-dvi; q=0.8, text/x-c		text/x-dvi; q=0.8, text/x-c
	Verbally, this would be interpreted as "text/html and text/x-c are		Verbally, this would be interpreted as "text/html and text/x-c are
	the preferred media types, but if they do not exist, then send the		the preferred media types, but if they do not exist, then send the
	text/x-dvi representation, and if that does not exist, send the text/		text/x-dvi representation, and if that does not exist, send the text/
	plain representation".		plain representation".
	skipping to change at page 18, line 48		skipping to change at page 19, line 8
	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8		Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
	The special value "*", if present in the Accept-Charset field,		The special value "*", if present in the Accept-Charset field,
	matches every character encoding which is not mentioned elsewhere in		matches every character encoding which is not mentioned elsewhere in
	the Accept-Charset field. If no "*" is present in an Accept-Charset		the Accept-Charset field. If no "*" is present in an Accept-Charset
	field, then all character encodings not explicitly mentioned get a		field, then all character encodings not explicitly mentioned get a
	quality value of 0.		quality value of 0.
	If no Accept-Charset header field is present, the default is that any		If no Accept-Charset header field is present, the default is that any
	character encoding is acceptable. If an Accept-Charset header field		character encoding is acceptable. If an Accept-Charset header field
	is present, and if the server cannot send a response which is		is present in a request, but the server cannot send a response which
	acceptable according to the Accept-Charset header field, then the		is acceptable, then the server can either use another character
	server SHOULD send an error response with the 406 (Not Acceptable)		encoding, or send a 406 (Not Acceptable) response.
	status code, though the sending of an unacceptable response is also
	allowed.
	6.3. Accept-Encoding		6.3. Accept-Encoding
	The "Accept-Encoding" header field can be used by user agents to		The "Accept-Encoding" header field can be used by user agents to
	indicate what response content-codings (Section 2.2) are acceptable		indicate what response content-codings (Section 2.2) are acceptable
	in the response.		in the response.
	Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] )		Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] )
	codings = ( content-coding / "*" )		codings = ( content-coding / "*" )
	skipping to change at page 19, line 48		skipping to change at page 20, line 7
	3. If multiple content-codings are acceptable, then the acceptable		3. If multiple content-codings are acceptable, then the acceptable
	content-coding with the highest non-zero qvalue is preferred.		content-coding with the highest non-zero qvalue is preferred.
	4. The "identity" content-coding is always acceptable, unless		4. The "identity" content-coding is always acceptable, unless
	specifically refused because the Accept-Encoding field includes		specifically refused because the Accept-Encoding field includes
	"identity;q=0", or because the field includes "*;q=0" and does		"identity;q=0", or because the field includes "*;q=0" and does
	not explicitly include the "identity" content-coding. If the		not explicitly include the "identity" content-coding. If the
	Accept-Encoding field-value is empty, then only the "identity"		Accept-Encoding field-value is empty, then only the "identity"
	encoding is acceptable.		encoding is acceptable.
	If an Accept-Encoding field is present in a request, and if the		If an Accept-Encoding field is present in a request, but the server
	server cannot send a response which is acceptable according to the		cannot send a response which is acceptable, then the server SHOULD
	Accept-Encoding header field, then the server SHOULD send an error		send a response without any encoding (i.e., the "identity" encoding).
	response with the 406 (Not Acceptable) status code.
	If no Accept-Encoding field is present in a request, the server MAY		If no Accept-Encoding field is present in a request, the server MAY
	assume that the client will accept any content coding. In this case,		assume that the client will accept any content coding. In this case,
	if "identity" is one of the available content-codings, then the		if "identity" is one of the available content-codings, then the
	server SHOULD use the "identity" content-coding, unless it has		server SHOULD use the "identity" content-coding, unless it has
	additional information that a different content-coding is meaningful		additional information that a different content-coding is meaningful
	to the client.		to the client.
	Note: If the request does not include an Accept-Encoding field,		Note: If the request does not include an Accept-Encoding field,
	and if the "identity" content-coding is unavailable, then content-		and if the "identity" content-coding is unavailable, then content-
	skipping to change at page 26, line 42		skipping to change at page 26, line 50
	identifier. In environments where proxies are used to enhance		identifier. In environments where proxies are used to enhance
	privacy, user agents ought to be conservative in offering accept		privacy, user agents ought to be conservative in offering accept
	header configuration options to end users. As an extreme privacy		header configuration options to end users. As an extreme privacy
	measure, proxies could filter the accept header fields in relayed		measure, proxies could filter the accept header fields in relayed
	requests. General purpose user agents which provide a high degree of		requests. General purpose user agents which provide a high degree of
	header configurability SHOULD warn users about the loss of privacy		header configurability SHOULD warn users about the loss of privacy
	which can be involved.		which can be involved.
	9. Acknowledgments		9. Acknowledgments
	10. References		See Section 12 of [Part1].
			10. References
	10.1. Normative References		10.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-15		and Message Parsing", draft-ietf-httpbis-p1-messaging-16
	(work in progress), July 2011.		(work in progress), August 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-15 (work in		Semantics", draft-ietf-httpbis-p2-semantics-16 (work in
	progress), July 2011.		progress), August 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-15 (work in		Requests", draft-ietf-httpbis-p4-conditional-16 (work in
	progress), July 2011.		progress), August 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-15 (work		Partial Responses", draft-ietf-httpbis-p5-range-16 (work
	in progress), July 2011.		in progress), August 2011.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] 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.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-15 (work in		6: Caching", draft-ietf-httpbis-p6-cache-16 (work in
	progress), July 2011.		progress), August 2011.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950, May 1996.		Specification version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus it might be less		RFC 1950 is an Informational RFC, thus it might be less
	stable than this specification. On the other hand, this		stable than this specification. On the other hand, this
	downward reference was present since the publication of		downward reference was present since the publication of
	RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to		RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
	cause problems in practice. See also [BCP97].		cause problems in practice. See also [BCP97].
	skipping to change at page 33, line 52		skipping to change at page 34, line 17
	";" OWS parameter )		";" OWS parameter )
	media-type = type "/" subtype *( OWS ";" OWS parameter )		media-type = type "/" subtype *( OWS ";" OWS parameter )
	parameter = attribute "=" value		parameter = attribute "=" value
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	qvalue = <qvalue, defined in [Part1], Section 6.4>		qvalue = <qvalue, defined in [Part1], Section 6.4>
	subtype = token		subtype = token
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 3.2.3>
	type = token		type = token
	value = word		value = word
	word = <word, defined in [Part1], Section 1.2.2>		word = <word, defined in [Part1], Section 3.2.3>
	ABNF diagnostics:		ABNF diagnostics:
	; Accept defined but not used		; Accept defined but not used
	; Accept-Charset defined but not used		; Accept-Charset defined but not used
	; Accept-Encoding defined but not used		; Accept-Encoding defined but not used
	; Accept-Language defined but not used		; Accept-Language defined but not used
	; Content-Encoding defined but not used		; Content-Encoding defined but not used
	; Content-Language defined but not used		; Content-Language defined but not used
	; Content-Location defined but not used		; Content-Location defined but not used
	skipping to change at page 40, line 9		skipping to change at page 40, line 21
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle		o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
	ABNFs for header fields"		ABNFs for header fields"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing		o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing
	undefined parameter in media range example"		undefined parameter in media range example"
	E.16. Since draft-ietf-httpbis-p3-payload-14		E.16. Since draft-ietf-httpbis-p3-payload-14
	None.		None.
			E.17. Since draft-ietf-httpbis-p3-payload-15
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
			requirements on Accept re: 406"
	Index		Index
	A		A
	Accept header field 16		Accept header field 16
	Accept-Charset header field 18		Accept-Charset header field 18
	Accept-Encoding header field 19		Accept-Encoding header field 19
	Accept-Language header field 20		Accept-Language header field 20
	C		C
	Coding Format		Coding Format
End of changes. 35 change blocks.
	47 lines changed or deleted		69 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/