draft-ietf-httpbis-p3-payload-18.txt		draft-ietf-httpbis-p3-payload-19.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) Y. Lafon, Ed.
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track W3C
	Expires: July 7, 2012 J. Mogul		Expires: September 13, 2012 J. Reschke, Ed.
	HP
	H. Frystyk
	Microsoft
	L. Masinter
	Adobe
	P. Leach
	Microsoft
	T. Berners-Lee
	W3C/MIT
	Y. Lafon, Ed.
	W3C
	J. Reschke, Ed.
	greenbytes		greenbytes
	January 4, 2012		March 12, 2012
	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-18		draft-ietf-httpbis-p3-payload-19
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext 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.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 1, line 49		skipping to change at page 1, line 37
	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.19.		The changes in this draft are summarized in Appendix E.20.
	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
	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 July 7, 2012.		This Internet-Draft will expire on September 13, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 9		skipping to change at page 2, line 46
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Conformance and Error Handling . . . . . . . . . . . . . . 5		1.2. Conformance and Error Handling . . . . . . . . . . . . . . 5
	1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6		1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6		1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
	1.3.2. ABNF Rules defined in other Parts of the		1.3.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 6		Specification . . . . . . . . . . . . . . . . . . . . 6
	2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6		2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6		2.1. Character Encodings (charset) . . . . . . . . . . . . . . 7
	2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7		2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8		2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8
	2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8
	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9		2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9
	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10
	2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10		2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
	3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11		3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11
	3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11
	4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Representation Header Fields . . . . . . . . . . . . . . . 12		4.1. Representation Header Fields . . . . . . . . . . . . . . . 12
	4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12		4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13
	5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13		5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14		5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
	5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15		5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
	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 . . . . . . . . . . . . . . . . . . . . . . 19
	6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19		6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20		6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21		6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
	6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22		6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
	6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23		6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23
	6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25		6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	7.1. Header Field Registration . . . . . . . . . . . . . . . . 25		7.1. Header Field Registration . . . . . . . . . . . . . . . . 25
	7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25		7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 26
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26		8.1. Privacy Issues Connected to Accept Header Fields . . . . . 27
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 27		10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
	10.2. Informative References . . . . . . . . . . . . . . . . . . 28		10.2. Informative References . . . . . . . . . . . . . . . . . . 29
	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 . . . . . . . . . . . . . . . 31
	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 . . . . . . . . . . . . . . . 32
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32		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 . . . . . . . . . . . . . . . . 33
	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) . . . . . . . . . . . . . . . . . . . . 35
	E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34		E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 35
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36		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 . . . . . . . . . . 37
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 37
	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 . . . . . . . . . . 38
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38		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 . . . . . . . . . . 39
	E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38		E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 39
	E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39		E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 40
	E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39		E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 40
	E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39		E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 40
	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		E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 41
	E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 40		E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 41
	E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 40		E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		E.20. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . . 41
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	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 5, line 35		skipping to change at page 5, line 35
	This specification uses a number of terms to refer to the roles		This specification uses a number of terms to refer to the roles
	played by participants in, and objects of, the HTTP communication.		played by participants in, and objects of, the HTTP communication.
	content negotiation		content negotiation
	The mechanism for selecting the appropriate representation when		The mechanism for selecting the appropriate representation when
	servicing a request. The representation in any response can be		servicing a request. The representation in any response can be
	negotiated (including error responses).		negotiated (including error responses).
			selected representation
			The current representation of the target resource that would have
			been selected in a successful response if the same request had
			used the method GET and excluded any conditional request header
			fields.
	1.2. Conformance and Error Handling		1.2. Conformance and Error Handling
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document defines conformance criteria for several roles in HTTP		This document defines conformance criteria for several roles in HTTP
	communication, including Senders, Recipients, Clients, Servers, User-		communication, including Senders, Recipients, Clients, Servers, User-
	Agents, Origin Servers, Intermediaries, Proxies and Gateways. See		Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
	Section 2 of [Part1] for definitions of these terms.		Section 2 of [Part1] for definitions of these terms.
	skipping to change at page 6, line 18		skipping to change at page 6, line 26
	define specific error handling mechanisms, except in cases where it		define specific error handling mechanisms, except in cases where it
	has direct impact on security. This is because different uses of the		has direct impact on security. This is because different uses of the
	protocol require different error handling strategies; for example, a		protocol require different error handling strategies; for example, a
	Web browser may wish to transparently recover from a response where		Web browser may wish to transparently recover from a response where
	the Location header field doesn't parse according to the ABNF,		the Location header field doesn't parse according to the ABNF,
	whereby in a systems control protocol using HTTP, this type of error		whereby in a systems control protocol using HTTP, this type of error
	recovery could lead to dangerous consequences.		recovery could lead to dangerous consequences.
	1.3. Syntax Notation		1.3. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the Augmented Backus-Naur Form (ABNF)
	[Part1] (which extends the syntax defined in [RFC5234] with a list		notation of [RFC5234] with the list rule extension defined in Section
	rule). Appendix D shows the collected ABNF, with the list rule		1.2 of [Part1]. Appendix D shows the collected ABNF with the list
	expanded.		rule expanded.
	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), and VCHAR (any visible US-ASCII		sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	1.3.1. Core Rules		1.3.1. Core Rules
	The core rules below are defined in [Part1]:		The core rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.4>
	word = <word, defined in [Part1], Section 3.2.3>		word = <word, defined in [Part1], Section 3.2.4>
	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 5.3>		qvalue = <qvalue, defined in [Part1], Section 4.3.1>
	2. Protocol Parameters		2. Protocol Parameters
	2.1. Character Encodings (charset)		2.1. Character Encodings (charset)
	HTTP uses charset names to indicate the character encoding of a		HTTP uses charset names to indicate the character encoding of a
	textual representation.		textual representation.
	A character encoding is identified by a case-insensitive token. The		A character encoding is identified by a case-insensitive token. The
	complete set of tokens is defined by the IANA Character Set registry		complete set of tokens is defined by the IANA Character Set registry
	skipping to change at page 7, line 46		skipping to change at page 8, line 4
	content-coding = token		content-coding = token
	All content-coding values are case-insensitive. HTTP/1.1 uses		All content-coding values are case-insensitive. HTTP/1.1 uses
	content-coding values in the Accept-Encoding (Section 6.3) and		content-coding values in the Accept-Encoding (Section 6.3) and
	Content-Encoding (Section 6.5) header fields. Although the value		Content-Encoding (Section 6.5) header fields. Although the value
	describes the content-coding, what is more important is that it		describes the content-coding, what is more important is that it
	indicates what decoding mechanism will be required to remove the		indicates what decoding mechanism will be required to remove the
	encoding.		encoding.
	compress		compress
			See Section 4.2.1 of [Part1].
	See Section 5.1.2.1 of [Part1].
	deflate		deflate
	See Section 5.1.2.2 of [Part1].		See Section 4.2.2 of [Part1].
	gzip		gzip
	See Section 5.1.2.3 of [Part1].		See Section 4.2.3 of [Part1].
	2.2.1. Content Coding Registry		2.2.1. Content Coding Registry
	The HTTP Content Coding Registry defines the name space for the		The HTTP Content Coding Registry defines the name space for the
	content coding names.		content coding names.
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	Names of content codings MUST NOT overlap with names of transfer		Names of content codings MUST NOT overlap with names of transfer
	codings (Section 5.1 of [Part1]), unless the encoding transformation		codings (Section 4 of [Part1]), unless the encoding transformation is
	is identical (as it is the case for the compression codings defined		identical (as is the case for the compression codings defined in
	in Section 5.1.2 of [Part1]).		Section 4.2 of [Part1]).
	Values to be added to this name space require a specification (see		Values to be added to this name space require IETF Review (see
	"Specification Required" in Section 4.1 of [RFC5226]), and MUST		Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
	conform to the purpose of content coding defined in this section.		coding defined in this section.
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	2.3. Media Types		2.3. Media Types
	HTTP uses Internet Media Types [RFC2046] in the Content-Type		HTTP uses Internet Media Types [RFC2046] in the Content-Type
	(Section 6.8) and Accept (Section 6.1) header fields in order to		(Section 6.8) and Accept (Section 6.1) header fields in order to
	provide open and extensible data typing and type negotiation.		provide open and extensible data typing and type negotiation.
	skipping to change at page 9, line 50		skipping to change at page 10, line 8
	line breaks applies only to text media in the payload body; a bare CR		line breaks applies only to text media in the payload body; a bare CR
	or LF MUST NOT be substituted for CRLF within any of the HTTP control		or LF MUST NOT be substituted for CRLF within any of the HTTP control
	structures (such as header fields and multipart boundaries).		structures (such as header fields and multipart boundaries).
	If a representation is encoded with a content-coding, the underlying		If a representation is encoded with a content-coding, the underlying
	data MUST be in a form defined above prior to being encoded.		data MUST be in a form defined above prior to being encoded.
	2.3.2. Multipart Types		2.3.2. Multipart Types
	MIME provides for a number of "multipart" types -- encapsulations of		MIME provides for a number of "multipart" types -- encapsulations of
	one or more representations within a single message-body. All		one or more representations within a single message body. All
	multipart types share a common syntax, as defined in Section 5.1.1 of		multipart types share a common syntax, as defined in Section 5.1.1 of
	[RFC2046], and MUST include a boundary parameter as part of the media		[RFC2046], and MUST include a boundary parameter as part of the media
	type value. The message body is itself a protocol element and MUST		type value. The message body is itself a protocol element and MUST
	therefore use only CRLF to represent line breaks between body-parts.		therefore use only CRLF to represent line breaks between body-parts.
	In general, HTTP treats a multipart message-body no differently than		In general, HTTP treats a multipart message body no differently than
	any other media type: strictly as payload. HTTP does not use the		any other media type: strictly as payload. HTTP does not use the
	multipart boundary as an indicator of message-body length. In all		multipart boundary as an indicator of message body length. In all
	other respects, an HTTP user agent SHOULD follow the same or similar		other respects, an HTTP user agent SHOULD follow the same or similar
	behavior as a MIME user agent would upon receipt of a multipart type.		behavior as a MIME user agent would upon receipt of a multipart type.
	The MIME header fields within each body-part of a multipart message-		The MIME header fields within each body-part of a multipart message
	body do not have any significance to HTTP beyond that defined by		body do not have any significance to HTTP beyond that defined by
	their MIME semantics.		their MIME semantics.
	If an application receives an unrecognized multipart subtype, the		If an application receives an unrecognized multipart subtype, the
	application MUST treat it as being equivalent to "multipart/mixed".		application MUST treat it as being equivalent to "multipart/mixed".
	Note: The "multipart/form-data" type has been specifically defined		Note: The "multipart/form-data" type has been specifically defined
	for carrying form data suitable for processing via the POST		for carrying form data suitable for processing via the POST
	request method, as described in [RFC2388].		request method, as described in [RFC2388].
	skipping to change at page 11, line 10		skipping to change at page 11, line 12
	en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN		en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
	See [RFC5646] for further information.		See [RFC5646] for further information.
	3. Payload		3. Payload
	HTTP messages MAY transfer a payload if not otherwise restricted by		HTTP messages MAY transfer a payload if not otherwise restricted by
	the request method or response status code. The payload consists of		the request method or response status code. The payload consists of
	metadata, in the form of header fields, and data, in the form of the		metadata, in the form of header fields, and data, in the form of the
	sequence of octets in the message-body after any transfer-coding has		sequence of octets in the message body after any transfer-coding has
	been decoded.		been decoded.
	A "payload" in HTTP is always a partial or complete representation of		A "payload" in HTTP is always a partial or complete representation of
	some resource. We use separate terms for payload and representation		some resource. We use separate terms for payload and representation
	because some messages contain only the associated representation's		because some messages contain only the associated representation's
	header fields (e.g., responses to HEAD) or only some part(s) of the		header fields (e.g., responses to HEAD) or only some part(s) of the
	representation (e.g., the 206 status code).		representation (e.g., the 206 status code).
	3.1. Payload Header Fields		3.1. Payload Header Fields
	HTTP header fields that specifically define the payload, rather than		HTTP header fields that specifically define the payload, rather than
	the associated representation, are referred to as "payload header		the associated representation, are referred to as "payload header
	fields". The following payload header fields are defined by		fields". The following payload header fields are defined by
	HTTP/1.1:		HTTP/1.1:
	+-------------------+------------------------+		+-------------------+--------------------------+
	| Header Field Name | Defined in... |		| Header Field Name | Defined in... |
	+-------------------+------------------------+		+-------------------+--------------------------+
	| Content-Length | Section 8.2 of [Part1] |		| Content-Length | Section 3.3.2 of [Part1] |
	| Content-Range | Section 5.2 of [Part5] |		| Content-Range | Section 5.2 of [Part5] |
	+-------------------+------------------------+		+-------------------+--------------------------+
	3.2. Payload Body		3.2. Payload Body
	A payload body is only present in a message when a message-body is		A payload body is only present in a message when a message body is
	present, as described in Section 3.3 of [Part1]. The payload body is		present, as described in Section 3.3 of [Part1]. The payload body is
	obtained from the message-body by decoding any Transfer-Encoding that		obtained from the message body by decoding any Transfer-Encoding that
	might have been applied to ensure safe and proper transfer of the		might have been applied to ensure safe and proper transfer of the
	message.		message.
	4. Representation		4. Representation
	A "representation" is information in a format that can be readily		A "representation" is information in a format that can be readily
	communicated from one party to another. A resource representation is		communicated from one party to another. A resource representation is
	information that reflects the state of that resource, as observed at		information that reflects the state of that resource, as observed at
	some point in the past (e.g., in a response to GET) or to be desired		some point in the past (e.g., in a response to GET) or to be desired
	at some point in the future (e.g., in a PUT request).		at some point in the future (e.g., in a PUT request).
	skipping to change at page 12, line 18		skipping to change at page 12, line 20
	contrast, contains either a representation that describes the		contrast, contains either a representation that describes the
	successful action or a representation of the target resource, with		successful action or a representation of the target resource, with
	the latter indicated by a Content-Location header field with the same		the latter indicated by a Content-Location header field with the same
	value as the effective request URI. Likewise, response messages with		value as the effective request URI. Likewise, response messages with
	an error status code usually contain a representation that describes		an error status code usually contain a representation that describes
	the error and what next steps are suggested for resolving it.		the error and what next steps are suggested for resolving it.
	4.1. Representation Header Fields		4.1. Representation Header Fields
	Representation header fields define metadata about the representation		Representation header fields define metadata about the representation
	data enclosed in the message-body or, if no message-body is present,		data enclosed in the message body or, if no message body is present,
	about the representation that would have been transferred in a 200		about the representation that would have been transferred in a 200
	response to a simultaneous GET request with the same effective		response to a simultaneous GET request with the same effective
	request URI.		request URI.
	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] |
			+-------------------+------------------------+
			Additional header fields define metadata about the selected
			representation, which might differ from the representation included
			in the message for responses to some state-changing methods. The
			following header fields are defined as selected representation
			metadata:
			+-------------------+------------------------+
			| Header Field Name | Defined in... |
			+-------------------+------------------------+
			| ETag | Section 2.3 of [Part4] |
	| Last-Modified | Section 2.2 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 17		skipping to change at page 15, line 32
	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		Server-driven negotiation allows the user agent to specify its
	preferences, but it cannot expect responses to always honour them.		preferences, but it cannot expect responses to always honor them.
	For example, the origin server might not implement server-driven		For example, the origin server might not implement server-driven
	negotiation, or it might decide that sending a response that doesn't		negotiation, or it might decide that sending a response that doesn't
	conform to them is better than sending a 406 (Not Acceptable)		conform to them is better than sending a 406 (Not Acceptable)
	response.		response.
	Many of the mechanisms for expressing preferences use quality values		Many of the mechanisms for expressing preferences use quality values
	to declare relative preference. See Section 5.3 of [Part1] for more		to declare relative preference. See Section 4.3.1 of [Part1] for
	information.		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.10 of [Part2]). However, an origin server is		User-Agent (Section 10.10 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.
	Note: In practice, User-Agent based negotiation is fragile,		Note: In practice, User-Agent based negotiation is fragile,
	because new clients might not be recognized.		because new clients might not be recognized.
	The Vary header field (Section 3.5 of [Part6]) can be used to express		The Vary header field (Section 3.5 of [Part6]) can be used to express
	the parameters the server uses to select a representation that is		the parameters the server uses to select a representation that is
	skipping to change at page 17, line 10		skipping to change at page 17, line 26
	The asterisk "*" character is used to group media types into ranges,		The asterisk "*" character is used to group media types into ranges,
	with "*/*" indicating all media types and "type/*" indicating all		with "*/*" indicating all media types and "type/*" indicating all
	subtypes of that type. The media-range MAY include media type		subtypes of that type. The media-range MAY include media type
	parameters that are applicable to that range.		parameters that are applicable to that range.
	Each media-range MAY be followed by one or more accept-params,		Each media-range MAY be followed by one or more accept-params,
	beginning with the "q" parameter for indicating a relative quality		beginning with the "q" parameter for indicating a relative quality
	factor. The first "q" parameter (if any) separates the media-range		factor. The first "q" parameter (if any) separates the media-range
	parameter(s) from the accept-params. Quality factors allow the user		parameter(s) from the accept-params. Quality factors allow the user
	or user agent to indicate the relative degree of preference for that		or user agent to indicate the relative degree of preference for that
	media-range, using the qvalue scale from 0 to 1 (Section 5.3 of		media-range, using the qvalue scale from 0 to 1 (Section 4.3.1 of
	[Part1]). The default value is q=1.		[Part1]). The default value is q=1.
	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".
	skipping to change at page 20, line 14		skipping to change at page 20, line 30
	field.		field.
	2. If the representation has no content-coding, then it is		2. If the representation has no content-coding, then it is
	acceptable by default unless specifically excluded by the Accept-		acceptable by default unless specifically excluded by the Accept-
	Encoding field stating either "identity;q=0" or "*;q=0" without a		Encoding field stating either "identity;q=0" or "*;q=0" without a
	more specific entry for "identity".		more specific entry for "identity".
	3. If the representation's content-coding is one of the content-		3. If the representation's content-coding is one of the content-
	codings listed in the Accept-Encoding field, then it is		codings listed in the Accept-Encoding field, then it is
	acceptable unless it is accompanied by a qvalue of 0. (As		acceptable unless it is accompanied by a qvalue of 0. (As
	defined in Section 5.3 of [Part1], a qvalue of 0 means "not		defined in Section 4.3.1 of [Part1], a qvalue of 0 means "not
	acceptable".)		acceptable".)
	4. If multiple content-codings are acceptable, then the acceptable		4. 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.
	An Accept-Encoding header field with a combined field-value that is		An Accept-Encoding header field with a combined field-value that is
	empty implies that the user agent does not want any content-coding in		empty implies that the user agent does not want any content-coding in
	response. If an Accept-Encoding header field is present in a request		response. If an Accept-Encoding header field is present in a request
	and none of the available representations for the response have a		and none of the available representations for the response have a
	content-coding that is listed as acceptable, the origin server SHOULD		content-coding that is listed as acceptable, the origin server SHOULD
	skipping to change at page 23, line 39		skipping to change at page 24, line 6
	The "Content-Location" header field supplies a URI that can be used		The "Content-Location" header field supplies a URI that can be used
	as a specific identifier for the representation in this message. In		as a specific identifier for the representation in this message. In
	other words, if one were to perform a GET on this URI at the time of		other words, if one were to perform a GET on this URI at the time of
	this message's generation, then a 200 response would contain the same		this message's generation, then a 200 response would contain the same
	representation that is enclosed as payload in this message.		representation that is enclosed as payload in this message.
	Content-Location = absolute-URI / partial-URI		Content-Location = absolute-URI / partial-URI
	The Content-Location value is not a replacement for the effective		The Content-Location value is not a replacement for the effective
	Request URI (Section 4.3 of [Part1]). It is representation metadata.		Request URI (Section 5.5 of [Part1]). It is representation metadata.
	It has the same syntax and semantics as the header field of the same		It has the same syntax and semantics as the header field of the same
	name defined for MIME body parts in Section 4 of [RFC2557]. However,		name defined for MIME body parts in Section 4 of [RFC2557]. However,
	its appearance in an HTTP message has some special implications for		its appearance in an HTTP message has some special implications for
	HTTP recipients.		HTTP recipients.
	If Content-Location is included in a response message and its value		If Content-Location is included in a response message and its value
	is the same as the effective request URI, then the response payload		is the same as the effective request URI, then the response payload
	SHOULD be considered the current representation of that resource.		SHOULD be considered a current representation of that resource. For
	For a GET or HEAD request, this is the same as the default semantics		a GET or HEAD request, this is the same as the default semantics when
	when no Content-Location is provided by the server. For a state-		no Content-Location is provided by the server. For a state-changing
	changing request like PUT or POST, it implies that the server's		request like PUT or POST, it implies that the server's response
	response contains the new representation of that resource, thereby		contains the new representation of that resource, thereby
	distinguishing it from representations that might only report about		distinguishing it from representations that might only report about
	the action (e.g., "It worked!"). This allows authoring applications		the action (e.g., "It worked!"). This allows authoring applications
	to update their local copies without the need for a subsequent GET		to update their local copies without the need for a subsequent GET
	request.		request.
	If Content-Location is included in a response message and its value		If Content-Location is included in a response message and its value
	differs from the effective request URI, then the origin server is		differs from the effective request URI, then the origin server is
	informing recipients that this representation has its own, presumably		informing recipients that this representation has its own, presumably
	more specific, identifier. For a GET or HEAD request, this is an		more specific, identifier. For a GET or HEAD request, this is an
	indication that the effective request URI identifies a resource that		indication that the effective request URI identifies a resource that
	is subject to content negotiation and the representation selected for		is subject to content negotiation and the selected representation for
	this response can also be found at the identified URI. For other		this response can also be found at the identified URI. For other
	methods, such a Content-Location indicates that this representation		methods, such a Content-Location indicates that this representation
	contains a report on the action's status and the same report is		contains a report on the action's status and the same report is
	available (for future access with GET) at the given URI. For		available (for future access with GET) at the given URI. For
	example, a purchase transaction made via a POST request might include		example, a purchase transaction made via a POST request might include
	a receipt document as the payload of the 200 response; the Content-		a receipt document as the payload of the 200 response; the Content-
	Location value provides an identifier for retrieving a copy of that		Location value provides an identifier for retrieving a copy of that
	same receipt in the future.		same receipt in the future.
	If Content-Location is included in a request message, then it MAY be		If Content-Location is included in a request message, then it MAY be
	skipping to change at page 26, line 7		skipping to change at page 26, line 31
	7.2. Content Coding Registry		7.2. Content Coding Registry
	The registration procedure for HTTP Content Codings is now defined by		The registration procedure for HTTP Content Codings is now defined by
	Section 2.2.1 of this document.		Section 2.2.1 of this document.
	The HTTP Content Codings Registry located at		The HTTP Content Codings Registry located at
	<http://www.iana.org/assignments/http-parameters> shall be updated		<http://www.iana.org/assignments/http-parameters> shall be updated
	with the registration below:		with the registration below:
	+----------+-----------------------------------------+--------------+		+----------+------------------------------------------+-------------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+----------+-----------------------------------------+--------------+		+----------+------------------------------------------+-------------+
	| compress | UNIX "compress" program method | Section |		| compress | UNIX "compress" program method | Section |
	| | | 5.1.2.1 of |		| | | 4.2.1 of |
	| | | [Part1] |		| | | [Part1] |
	| deflate | "deflate" compression mechanism | Section |		| deflate | "deflate" compression mechanism | Section |
	| | ([RFC1951]) used inside the "zlib" data | 5.1.2.2 of |		| | ([RFC1951]) used inside the "zlib" data | 4.2.2 of |
	| | format ([RFC1950]) | [Part1] |		| | format ([RFC1950]) | [Part1] |
	| gzip | Same as GNU zip [RFC1952] | Section |		| gzip | Same as GNU zip [RFC1952] | Section |
	| | | 5.1.2.3 of |		| | | 4.2.3 of |
	| | | [Part1] |		| | | [Part1] |
	| identity | reserved (synonym for "no encoding" in | Section 6.3 |		| identity | reserved (synonym for "no encoding" in | Section 6.3 |
	| | Accept-Encoding header field) | |		| | Accept-Encoding header field) | |
	+----------+-----------------------------------------+--------------+		+----------+------------------------------------------+-------------+
	8. Security Considerations		8. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	8.1. Privacy Issues Connected to Accept Header Fields		8.1. Privacy Issues Connected to Accept Header Fields
	Accept headers fields can reveal information about the user to all		Accept header fields can reveal information about the user to all
	servers which are accessed. The Accept-Language header field in		servers which are accessed. The Accept-Language header field in
	particular can reveal information the user would consider to be of a		particular can reveal information the user would consider to be of a
	private nature, because the understanding of particular languages is		private nature, because the understanding of particular languages is
	often strongly correlated to the membership of a particular ethnic		often strongly correlated to the membership of a particular ethnic
	group. User agents which offer the option to configure the contents		group. User agents which offer the option to configure the contents
	of an Accept-Language header field to be sent in every request are		of an Accept-Language header field to be sent in every request are
	strongly encouraged to let the configuration process include a		strongly encouraged to let the configuration process include a
	message which makes the user aware of the loss of privacy involved.		message which makes the user aware of the loss of privacy involved.
	An approach that limits the loss of privacy would be for a user agent		An approach that limits the loss of privacy would be for a user agent
	skipping to change at page 27, line 20		skipping to change at page 27, line 43
	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
	See Section 11 of [Part1].		See Section 9 of [Part1].
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		"HTTP/1.1, part 1: URIs, Connections, and Message
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
	and Message Parsing", draft-ietf-httpbis-p1-messaging-18		progress), March 2012.
	(work in progress), January 2012.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		"HTTP/1.1, part 2: Message Semantics",
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		draft-ietf-httpbis-p2-semantics-19 (work in progress),
	Semantics", draft-ietf-httpbis-p2-semantics-18 (work in		March 2012.
	progress), January 2012.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		"HTTP/1.1, part 4: Conditional Requests",
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		draft-ietf-httpbis-p4-conditional-19 (work in progress),
	Requests", draft-ietf-httpbis-p4-conditional-18 (work in		March 2012.
	progress), January 2012.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		"HTTP/1.1, part 5: Range Requests and Partial Responses",
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		draft-ietf-httpbis-p5-range-19 (work in progress),
	Partial Responses", draft-ietf-httpbis-p5-range-18 (work		March 2012.
	in progress), January 2012.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		draft-ietf-httpbis-p6-cache-19 (work in progress),
	6: Caching", draft-ietf-httpbis-p6-cache-18 (work in		March 2012.
	progress), January 2012.
	[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.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
	Randers-Pehrson, "GZIP file format specification version		Randers-Pehrson, "GZIP file format specification version
	4.3", RFC 1952, May 1996.		4.3", RFC 1952, May 1996.
	skipping to change at page 30, line 4		skipping to change at page 30, line 21
	RFC 6151, March 2011.		RFC 6151, March 2011.
	[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field		[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
	in the Hypertext Transfer Protocol (HTTP)", RFC 6266,		in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
	June 2011.		June 2011.
	Appendix A. Differences between HTTP and MIME		Appendix A. Differences between HTTP and MIME
	HTTP/1.1 uses many of the constructs defined for Internet Mail		HTTP/1.1 uses many of the constructs defined for Internet Mail
	([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME		([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
			[RFC2045]) to allow a message body to be transmitted in an open
	[RFC2045]) to allow a message-body to be transmitted in an open
	variety of representations and with extensible mechanisms. However,		variety of representations and with extensible mechanisms. However,
	RFC 2045 discusses mail, and HTTP has a few features that are		RFC 2045 discusses mail, and HTTP has a few features that are
	different from those described in MIME. These differences were		different from those described in MIME. These differences were
	carefully chosen to optimize performance over binary connections, to		carefully chosen to optimize performance over binary connections, to
	allow greater freedom in the use of new media types, to make date		allow greater freedom in the use of new media types, to make date
	comparisons easier, and to acknowledge the practice of some early		comparisons easier, and to acknowledge the practice of some early
	HTTP servers and clients.		HTTP servers and clients.
	This appendix describes specific areas where HTTP differs from MIME.		This appendix describes specific areas where HTTP differs from MIME.
	Proxies and gateways to strict MIME environments SHOULD be aware of		Proxies and gateways to strict MIME environments SHOULD be aware of
	skipping to change at page 30, line 27		skipping to change at page 30, line 43
	necessary. Proxies and gateways from MIME environments to HTTP also		necessary. Proxies and gateways from MIME environments to HTTP also
	need to be aware of the differences because some conversions might be		need to be aware of the differences because some conversions might be
	required.		required.
	A.1. MIME-Version		A.1. MIME-Version
	HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages		HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
	MAY include a single MIME-Version header field to indicate what		MAY include a single MIME-Version header field to indicate what
	version of the MIME protocol was used to construct the message. Use		version of the MIME protocol was used to construct the message. Use
	of the MIME-Version header field indicates that the message is in		of the MIME-Version header field indicates that the message is in
	full compliance with the MIME protocol (as defined in [RFC2045]).		full conformance with the MIME protocol (as defined in [RFC2045]).
	Proxies/gateways are responsible for ensuring full compliance (where		Proxies/gateways are responsible for ensuring full conformance (where
	possible) when exporting HTTP messages to strict MIME environments.		possible) when exporting HTTP messages to strict MIME environments.
	MIME-Version = 1*DIGIT "." 1*DIGIT		MIME-Version = 1*DIGIT "." 1*DIGIT
	MIME version "1.0" is the default for use in HTTP/1.1. However,		MIME version "1.0" is the default for use in HTTP/1.1. However,
	HTTP/1.1 message parsing and semantics are defined by this document		HTTP/1.1 message parsing and semantics are defined by this document
	and not the MIME specification.		and not the MIME specification.
	A.2. Conversion to Canonical Form		A.2. Conversion to Canonical Form
	skipping to change at page 32, line 7		skipping to change at page 32, line 22
	Proxies and gateways from HTTP to MIME-compliant protocols are		Proxies and gateways from HTTP to MIME-compliant protocols are
	responsible for ensuring that the message is in the correct format		responsible for ensuring that the message is in the correct format
	and encoding for safe transport on that protocol, where "safe		and encoding for safe transport on that protocol, where "safe
	transport" is defined by the limitations of the protocol being used.		transport" is defined by the limitations of the protocol being used.
	Such a proxy or gateway SHOULD label the data with an appropriate		Such a proxy or gateway SHOULD label the data with an appropriate
	Content-Transfer-Encoding if doing so will improve the likelihood of		Content-Transfer-Encoding if doing so will improve the likelihood of
	safe transport over the destination protocol.		safe transport over the destination protocol.
	A.6. Introduction of Transfer-Encoding		A.6. Introduction of Transfer-Encoding
	HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.6		HTTP/1.1 introduces the Transfer-Encoding header field (Section 3.3.1
	of [Part1]). Proxies/gateways MUST remove any transfer-coding prior		of [Part1]). Proxies/gateways MUST remove any transfer-coding prior
	to forwarding a message via a MIME-compliant protocol.		to forwarding a message via a MIME-compliant protocol.
	A.7. MHTML and Line Length Limitations		A.7. MHTML and Line Length Limitations
	HTTP implementations which share code with MHTML [RFC2557]		HTTP implementations which share code with MHTML [RFC2557]
	implementations need to be aware of MIME line length limitations.		implementations need to be aware of MIME line length limitations.
	Since HTTP does not have this limitation, HTTP does not fold long		Since HTTP does not have this limitation, HTTP does not fold long
	lines. MHTML messages being transported by HTTP follow all		lines. MHTML messages being transported by HTTP follow all
	conventions of MHTML, including line length limitations and folding,		conventions of MHTML, including line length limitations and folding,
	skipping to change at page 32, line 41		skipping to change at page 33, line 9
	the base HTTP/1.1 specification.		the base HTTP/1.1 specification.
	A number of other header fields, such as Content-Disposition and		A number of other header fields, such as Content-Disposition and
	Title, from SMTP and MIME are also often implemented (see [RFC6266]		Title, from SMTP and MIME are also often implemented (see [RFC6266]
	and [RFC2076]).		and [RFC2076]).
	Appendix C. Changes from RFC 2616		Appendix C. Changes from RFC 2616
	Clarify contexts that charset is used in. (Section 2.1)		Clarify contexts that charset is used in. (Section 2.1)
			Registration of Content Codings now requires IETF Review
			(Section 2.2.1)
	Remove the default character encoding for text media types; the		Remove the default character encoding for text media types; the
	default now is whatever the media type definition says.		default now is whatever the media type definition says.
	(Section 2.3.1)		(Section 2.3.1)
	Change ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	value. (Section 6)		value. (Section 6)
	Remove definition of Content-MD5 header field because it was		Remove definition of Content-MD5 header field because it was
	inconsistently implemented with respect to partial responses, and		inconsistently implemented with respect to partial responses, and
	also because of known deficiencies in the hash algorithm itself (see		also because of known deficiencies in the hash algorithm itself (see
	skipping to change at page 33, line 4		skipping to change at page 33, line 23
	default now is whatever the media type definition says.		default now is whatever the media type definition says.
	(Section 2.3.1)		(Section 2.3.1)
	Change ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	value. (Section 6)		value. (Section 6)
	Remove definition of Content-MD5 header field because it was		Remove definition of Content-MD5 header field because it was
	inconsistently implemented with respect to partial responses, and		inconsistently implemented with respect to partial responses, and
	also because of known deficiencies in the hash algorithm itself (see		also because of known deficiencies in the hash algorithm itself (see
	[RFC6151] for details). (Section 6)		[RFC6151] for details). (Section 6)
	Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2)		Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2)
	Remove base URI setting semantics for Content-Location due to poor		Remove base URI setting semantics for Content-Location due to poor
	implementation support, which was caused by too many broken servers		implementation support, which was caused by too many broken servers
	emitting bogus Content-Location header fields, and also the		emitting bogus Content-Location header fields, and also the
	potentially undesirable effect of potentially breaking relative links		potentially undesirable effect of potentially breaking relative links
	in content-negotiated resources. (Section 6.7)		in content-negotiated resources. (Section 6.7)
	Remove discussion of Content-Disposition header field, it is now
	defined by [RFC6266]. (Appendix B)
	Remove reference to non-existant identity transfer-coding value		Remove reference to non-existant identity transfer-coding value
	tokens. (Appendix A.5)		tokens. (Appendix A.5)
			Remove discussion of Content-Disposition header field, it is now
			defined by [RFC6266]. (Appendix B)
	Appendix D. Collected ABNF		Appendix D. Collected ABNF
	Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [		Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
	OWS media-range [ accept-params ] ] ) ]		OWS media-range [ accept-params ] ] ) ]
	Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="		Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
	qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="		qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
	qvalue ] ] )		qvalue ] ] )
	Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )		Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )
	*( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]		*( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
	Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q="		Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q="
	skipping to change at page 33, line 33		skipping to change at page 34, line 4
	qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="		qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
	qvalue ] ] )		qvalue ] ] )
	Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )		Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )
	*( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]		*( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
	Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q="		Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q="
	qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]		qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
	] )		] )
	Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS		Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
	content-coding ] )		content-coding ] )
	Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS		Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
	language-tag ] )		language-tag ] )
	Content-Location = absolute-URI / partial-URI		Content-Location = absolute-URI / partial-URI
	Content-Type = media-type		Content-Type = media-type
	MIME-Version = 1*DIGIT "." 1*DIGIT		MIME-Version = 1*DIGIT "." 1*DIGIT
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	accept-ext = OWS ";" OWS token [ "=" word ]		accept-ext = OWS ";" OWS token [ "=" word ]
	accept-params = OWS ";" OWS "q=" qvalue *accept-ext		accept-params = OWS ";" OWS "q=" qvalue *accept-ext
	attribute = token		attribute = token
	charset = token		charset = token
	codings = content-coding / "identity" / "*"		codings = content-coding / "identity" / "*"
	content-coding = token		content-coding = token
	language-range = <language-range, defined in [RFC4647], Section 2.1>		language-range = <language-range, defined in [RFC4647], Section 2.1>
	language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>		language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
	media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS		media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
	";" 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 5.3>		qvalue = <qvalue, defined in [Part1], Section 4.3.1>
	subtype = token		subtype = token
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.4>
	type = token		type = token
	value = word		value = word
	word = <word, defined in [Part1], Section 3.2.3>		word = <word, defined in [Part1], Section 3.2.4>
	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
	; Content-Type defined but not used		; Content-Type defined but not used
	skipping to change at page 40, line 42		skipping to change at page 41, line 26
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document		o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
	HTTP's error-handling philosophy"		HTTP's error-handling philosophy"
	E.19. Since draft-ietf-httpbis-p3-payload-17		E.19. Since draft-ietf-httpbis-p3-payload-17
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended		o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
	maturity level vs normative references"		maturity level vs normative references"
			E.20. Since draft-ietf-httpbis-p3-payload-18
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/330>: "is ETag a
			representation header field?"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/338>: "Content-
			Location doesn't constrain the cardinality of representations"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA
			policy definitions consistent"
	Index		Index
	A		A
	Accept header field 16		Accept header field 16
	Accept-Charset header field 18		Accept-Charset header field 19
	Accept-Encoding header field 19		Accept-Encoding header field 19
	Accept-Language header field 20		Accept-Language header field 21
	C		C
	Coding Format		Coding Format
	compress 7		compress 7
	deflate 7		deflate 8
	gzip 8		gzip 8
	compress (Coding Format) 7		compress (Coding Format) 7
	content negotiation 5		content negotiation 5
	Content-Encoding header field 21		Content-Encoding header field 22
	Content-Language header field 22		Content-Language header field 23
	Content-Location header field 23		Content-Location header field 23
			Content-Transfer-Encoding header field 32
	Content-Type header field 25		Content-Type header field 25
	D		D
	deflate (Coding Format) 7		deflate (Coding Format) 8
	G		G
	Grammar		Grammar
	Accept 16		Accept 17
	Accept-Charset 18		Accept-Charset 19
	Accept-Encoding 19		Accept-Encoding 19
	accept-ext 16		accept-ext 17
	Accept-Language 20		Accept-Language 21
	accept-params 16		accept-params 17
	attribute 8		attribute 9
	charset 7		charset 7
	codings 19		codings 19
	content-coding 7		content-coding 7
	Content-Encoding 21		Content-Encoding 22
	Content-Language 22		Content-Language 23
	Content-Location 23		Content-Location 23
	Content-Type 25		Content-Type 25
	language-range 20		language-range 21
	language-tag 10		language-tag 10
	media-range 16		media-range 17
	media-type 8		media-type 8
	MIME-Version 30		MIME-Version 30
	parameter 8		parameter 9
	subtype 8		subtype 8
	type 8		type 8
	value 8		value 9
	gzip (Coding Format) 8		gzip (Coding Format) 8
	H		H
	Header Fields		Header Fields
	Accept 16		Accept 16
	Accept-Charset 18		Accept-Charset 19
	Accept-Encoding 19		Accept-Encoding 19
	Accept-Language 20		Accept-Language 21
	Content-Encoding 21		Content-Encoding 22
	Content-Language 22		Content-Language 23
	Content-Location 23		Content-Location 23
			Content-Transfer-Encoding 32
	Content-Type 25		Content-Type 25
	MIME-Version 30		MIME-Version 30
	M		M
	MIME-Version header field 30		MIME-Version header field 30
	P		P
	payload 11		payload 11
	R		R
	representation 11		representation 11
			S
			selected representation 5
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Jim Gettys
	Alcatel-Lucent Bell Labs
	21 Oak Knoll Road
	Carlisle, MA 01741
	USA
	EMail: jg@freedesktop.org
	URI: http://gettys.wordpress.com/
	Jeffrey C. Mogul
	Hewlett-Packard Company
	HP Labs, Large Scale Systems Group
	1501 Page Mill Road, MS 1177
	Palo Alto, CA 94304
	USA
	EMail: JeffMogul@acm.org
	Henrik Frystyk Nielsen
	Microsoft Corporation
	1 Microsoft Way
	Redmond, WA 98052
	USA
	EMail: henrikn@microsoft.com
	Larry Masinter
	Adobe Systems Incorporated
	345 Park Ave
	San Jose, CA 95110
	USA
	EMail: LMM@acm.org
	URI: http://larry.masinter.net/
	Paul J. Leach
	Microsoft Corporation
	1 Microsoft Way
	Redmond, WA 98052
	EMail: paulle@microsoft.com
	Tim Berners-Lee
	World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32
	32 Vassar Street
	Cambridge, MA 02139
	USA
	EMail: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/
	Yves Lafon (editor)		Yves Lafon (editor)
	World Wide Web Consortium		World Wide Web Consortium
	W3C / ERCIM		W3C / ERCIM
	2004, rte des Lucioles		2004, rte des Lucioles
	Sophia-Antipolis, AM 06902		Sophia-Antipolis, AM 06902
	France		France
	EMail: ylafon@w3.org		EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/		URI: http://www.raubacapeu.net/people/yves/
End of changes. 90 change blocks.
	227 lines changed or deleted		197 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/