draft-ietf-httpbis-p3-payload-13.txt		draft-ietf-httpbis-p3-payload-14.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: September 15, 2011 J. Mogul		Expires: October 20, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 14, 2011		April 18, 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-13		draft-ietf-httpbis-p3-payload-14
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. 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. Part 3 defines
	HTTP message content, metadata, and content negotiation.		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). The current issues list is		group mailing list (ietf-http-wg@w3.org), which is archived at
	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
			The current issues list is at
			<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix E.14.		The changes in this draft are summarized in Appendix E.15.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 2, line 15		skipping to change at page 2, line 17
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 15, 2011.		This Internet-Draft will expire on October 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 4		skipping to change at page 3, line 7
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6		2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6
	2.1.1. Missing 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 . . . . . . . . . . . . . . . . . . . 10		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9
	2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10		2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
	3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11		3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11
	3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12		3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11
	4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Representation Header Fields . . . . . . . . . . . . . . . 12		4.1. Representation Header Fields . . . . . . . . . . . . . . . 12
	4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13		4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12
	5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14		5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15		5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
	5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16		5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
	6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19		6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19		6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21		6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
	6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22		6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21
	6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23		6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22
	6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24		6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23
	6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25		6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
	6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		7.1. Header Field Registration . . . . . . . . . . . . . . . . 24
	7.1. Header Field Registration . . . . . . . . . . . . . . . . 27		7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25
	7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26
	8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 29		10.2. Informative References . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . . 31		Appendix A. Differences between HTTP and MIME . . . . . . . . . . 31
	Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34		Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34
	Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 34
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 37		publication) . . . . . . . . . . . . . . . . . . . . 36
	E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37		E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 36
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 37
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 37
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 37
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 38
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 38
	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39		E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 38
	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40		E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 39
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 39
	E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41		E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 39
	E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41		E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 40
	E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42		E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 41
	E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42		E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 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 7, line 14		skipping to change at page 7, line 14
	HTTP uses charset in two contexts: within an Accept-Charset request		HTTP uses charset in two contexts: within an Accept-Charset request
	header field (in which the charset value is an unquoted token) and as		header field (in which the charset value is an unquoted token) and as
	the value of a parameter in a Content-Type header field (within a		the value of a parameter in a Content-Type header field (within a
	request or response), in which case the parameter value of the		request or response), in which case the parameter value of the
	charset parameter can be quoted.		charset parameter can be quoted.
	Implementors need to be aware of IETF character set requirements		Implementors need to be aware of IETF character set requirements
	[RFC3629] [RFC2277].		[RFC3629] [RFC2277].
	2.1.1. Missing Charset
	Some HTTP/1.0 software has interpreted a Content-Type header field
	without charset parameter incorrectly to mean "recipient should
	guess". Senders wishing to defeat this behavior MAY include a
	charset parameter even when the charset is ISO-8859-1 ([ISO-8859-1])
	and SHOULD do so when it is known that it will not confuse the
	recipient.
	Unfortunately, some older HTTP/1.0 clients did not deal properly with
	an explicit charset parameter. HTTP/1.1 recipients MUST respect the
	charset label provided by the sender; and those user agents that have
	a provision to "guess" a charset MUST use the charset from the
	content-type field if they support that charset, rather than the
	recipient's preference, when initially displaying a document. See
	Section 2.3.1.
	2.2. Content Codings		2.2. Content Codings
	Content coding values indicate an encoding transformation that has		Content coding values indicate an encoding transformation that has
	been or can be applied to a representation. Content codings are		been or can be applied to a representation. Content codings are
	primarily used to allow a representation to be compressed or		primarily used to allow a representation to be compressed or
	otherwise usefully transformed without losing the identity of its		otherwise usefully transformed without losing the identity of its
	underlying media type and without loss of information. Frequently,		underlying media type and without loss of information. Frequently,
	the representation is stored in coded form, transmitted directly, and		the representation is stored in coded form, transmitted directly, and
	only decoded by the recipient.		only decoded by the recipient.
	skipping to change at page 8, line 49		skipping to change at page 8, line 33
	Values to be added to this name space require a specification (see		Values to be added to this name space require a specification (see
	"Specification Required" in Section 4.1 of [RFC5226]), and MUST		"Specification Required" in Section 4.1 of [RFC5226]), and MUST
	conform to the purpose of content coding defined in this section.		conform to the purpose of content 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.9) 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.
	media-type = type "/" subtype *( OWS ";" OWS parameter )		media-type = type "/" subtype *( OWS ";" OWS parameter )
	type = token		type = token
	subtype = token		subtype = token
	The type/subtype MAY be followed by parameters in the form of		The type/subtype MAY be followed by parameters in the form of
	attribute/value pairs.		attribute/value pairs.
	parameter = attribute "=" value		parameter = attribute "=" value
	skipping to change at page 10, line 12		skipping to change at page 9, line 43
	multi-byte character encodings, HTTP allows the use of whatever octet		multi-byte character encodings, HTTP allows the use of whatever octet
	sequences are defined by that character encoding to represent the		sequences are defined by that character encoding to represent the
	equivalent of CR and LF for line breaks. This flexibility regarding		equivalent of CR and LF for line breaks. This flexibility regarding
	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.
	The "charset" parameter is used with some media types to define the
	character encoding (Section 2.1) of the data. When no explicit
	charset parameter is provided by the sender, media subtypes of the
	"text" type are defined to have a default charset value of
	"ISO-8859-1" when received via HTTP. Data in character encodings
	other than "ISO-8859-1" or its subsets MUST be labeled with an
	appropriate charset value. See Section 2.1.1 for compatibility
	problems.
	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
	skipping to change at page 11, line 48		skipping to change at page 11, line 22
	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 9.2 of [Part1] |		| Content-Length | Section 9.2 of [Part1] |
	| Content-MD5 | Section 6.8 |
	| 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.
	skipping to change at page 13, line 11		skipping to change at page 12, line 23
	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.9 |		| Content-Type | Section 6.8 |
	| Expires | Section 3.3 of [Part6] |		| Expires | Section 3.3 of [Part6] |
	| Last-Modified | Section 6.6 of [Part4] |		| Last-Modified | Section 2.1 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 17, line 7		skipping to change at page 16, line 20
	fields related to the payload of messages.		fields related to the payload of messages.
	6.1. Accept		6.1. Accept
	The "Accept" header field can be used by user agents to specify		The "Accept" header field can be used by user agents to specify
	response media types that are acceptable. Accept header fields can		response media types that are acceptable. Accept header fields can
	be used to indicate that the request is specifically limited to a		be used to indicate that the request is specifically limited to a
	small set of desired types, as in the case of a request for an in-		small set of desired types, as in the case of a request for an in-
	line image.		line image.
	Accept = "Accept" ":" OWS Accept-v		Accept = #( media-range [ accept-params ] )
	Accept-v = #( media-range [ accept-params ] )
	media-range = ( "*/*"		media-range = ( "*/*"
	/ ( type "/" "*" )		/ ( type "/" "*" )
	/ ( type "/" subtype )		/ ( type "/" subtype )
	) *( OWS ";" OWS parameter )		) *( OWS ";" OWS parameter )
	accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )		accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )
	accept-ext = OWS ";" OWS token [ "=" word ]		accept-ext = OWS ";" OWS token [ "=" word ]
	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
	skipping to change at page 18, line 19		skipping to change at page 17, line 29
	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".
	Media ranges can be overridden by more specific media ranges or		Media ranges can be overridden by more specific media ranges or
	specific media types. If more than one media range applies to a		specific media types. If more than one media range applies to a
	given type, the most specific reference has precedence. For example,		given type, the most specific reference has precedence. For example,
	Accept: text/*, text/html, text/html;level=1, */*		Accept: text/*, text/plain, text/plain;format=flowed, */*
	have the following precedence:		have the following precedence:
	1. text/html;level=1		1. text/plain;format=flowed
	2. text/html		2. text/plain
	3. text/*		3. text/*
	4. */*		4. */*
	The media type quality factor associated with a given type is		The media type quality factor associated with a given type is
	determined by finding the media range with the highest precedence		determined by finding the media range with the highest precedence
	which matches that type. For example,		which matches that type. For example,
	Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,		Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
	skipping to change at page 19, line 16		skipping to change at page 18, line 30
	6.2. Accept-Charset		6.2. Accept-Charset
	The "Accept-Charset" header field can be used by user agents to		The "Accept-Charset" header field can be used by user agents to
	indicate what character encodings are acceptable in a response		indicate what character encodings are acceptable in a response
	payload. This field allows clients capable of understanding more		payload. This field allows clients capable of understanding more
	comprehensive or special-purpose character encodings to signal that		comprehensive or special-purpose character encodings to signal that
	capability to a server which is capable of representing documents in		capability to a server which is capable of representing documents in
	those character encodings.		those character encodings.
	Accept-Charset = "Accept-Charset" ":" OWS		Accept-Charset = 1#( ( charset / "*" )
	Accept-Charset-v
	Accept-Charset-v = 1#( ( charset / "*" )
	[ OWS ";" OWS "q=" qvalue ] )		[ OWS ";" OWS "q=" qvalue ] )
	Character encoding values (a.k.a., charsets) are described in		Character encoding values (a.k.a., charsets) are described in
	Section 2.1. Each charset MAY be given an associated quality value		Section 2.1. Each charset MAY be given an associated quality value
	which represents the user's preference for that charset. The default		which represents the user's preference for that charset. The default
	value is q=1. An example is		value is q=1. An example is
	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 (including ISO-8859-1) which is not		matches every character encoding which is not mentioned elsewhere in
	mentioned elsewhere in the Accept-Charset field. If no "*" is		the Accept-Charset field. If no "*" is present in an Accept-Charset
	present in an Accept-Charset field, then all character encodings not		field, then all character encodings not explicitly mentioned get a
	explicitly mentioned get a quality value of 0, except for ISO-8859-1,		quality value of 0.
	which gets a quality value of 1 if not explicitly mentioned.
	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, and if the server cannot send a response which is
	acceptable according to the Accept-Charset header field, then the		acceptable according to the Accept-Charset header field, then the
	server SHOULD send an error response with the 406 (Not Acceptable)		server SHOULD send an error response with the 406 (Not Acceptable)
	status code, though the sending of an unacceptable response is also		status code, though the sending of an unacceptable response is also
	allowed.		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 = "Accept-Encoding" ":" OWS		Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] )
	Accept-Encoding-v		codings = ( content-coding / "*" )
	Accept-Encoding-v =
	#( codings [ OWS ";" OWS "q=" qvalue ] )
	codings = ( content-coding / "*" )
	Each codings value MAY be given an associated quality value which		Each codings value MAY be given an associated quality value which
	represents the preference for that encoding. The default value is		represents the preference for that encoding. The default value is
	q=1.		q=1.
	Examples of its use are:		Examples of its use are:
	Accept-Encoding: compress, gzip		Accept-Encoding: compress, gzip
	Accept-Encoding:		Accept-Encoding:
	Accept-Encoding: *		Accept-Encoding: *
	skipping to change at page 21, line 26		skipping to change at page 20, line 30
	Note: Most HTTP/1.0 applications do not recognize or obey qvalues		Note: Most HTTP/1.0 applications do not recognize or obey qvalues
	associated with content-codings. This means that qvalues will not		associated with content-codings. This means that qvalues will not
	work and are not permitted with x-gzip or x-compress.		work and are not permitted with x-gzip or x-compress.
	6.4. Accept-Language		6.4. Accept-Language
	The "Accept-Language" header field can be used by user agents to		The "Accept-Language" header field can be used by user agents to
	indicate the set of natural languages that are preferred in the		indicate the set of natural languages that are preferred in the
	response. Language tags are defined in Section 2.4.		response. Language tags are defined in Section 2.4.
	Accept-Language = "Accept-Language" ":" OWS		Accept-Language =
	Accept-Language-v
	Accept-Language-v =
	1#( language-range [ OWS ";" OWS "q=" qvalue ] )		1#( language-range [ OWS ";" OWS "q=" qvalue ] )
	language-range =		language-range =
	<language-range, defined in [RFC4647], Section 2.1>		<language-range, defined in [RFC4647], Section 2.1>
	Each language-range can be given an associated quality value which		Each language-range can be given an associated quality value which
	represents an estimate of the user's preference for the languages		represents an estimate of the user's preference for the languages
	specified by that range. The quality value defaults to "q=1". For		specified by that range. The quality value defaults to "q=1". For
	example,		example,
	Accept-Language: da, en-gb;q=0.8, en;q=0.7		Accept-Language: da, en-gb;q=0.8, en;q=0.7
	would mean: "I prefer Danish, but will accept British English and		would mean: "I prefer Danish, but will accept British English and
	skipping to change at page 22, line 32		skipping to change at page 21, line 34
	6.5. Content-Encoding		6.5. Content-Encoding
	The "Content-Encoding" header field indicates what content-codings		The "Content-Encoding" header field indicates what content-codings
	have been applied to the representation, and thus what decoding		have been applied to the representation, and thus what decoding
	mechanisms must be applied in order to obtain the media-type		mechanisms must be applied in order to obtain the media-type
	referenced by the Content-Type header field. Content-Encoding is		referenced by the Content-Type header field. Content-Encoding is
	primarily used to allow a representation to be compressed without		primarily used to allow a representation to be compressed without
	losing the identity of its underlying media type.		losing the identity of its underlying media type.
	Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v		Content-Encoding = 1#content-coding
	Content-Encoding-v = 1#content-coding
	Content codings are defined in Section 2.2. An example of its use is		Content codings are defined in Section 2.2. An example of its use is
	Content-Encoding: gzip		Content-Encoding: gzip
	The content-coding is a characteristic of the representation.		The content-coding is a characteristic of the representation.
	Typically, the representation body is stored with this encoding and		Typically, the representation body is stored with this encoding and
	is only decoded before rendering or analogous usage. However, a		is only decoded before rendering or analogous usage. However, a
	transforming proxy MAY modify the content-coding if the new coding is		transforming proxy MAY modify the content-coding if the new coding is
	known to be acceptable to the recipient, unless the "no-transform"		known to be acceptable to the recipient, unless the "no-transform"
	skipping to change at page 23, line 18		skipping to change at page 22, line 18
	applied. Additional information about the encoding parameters MAY be		applied. Additional information about the encoding parameters MAY be
	provided by other header fields not defined by this specification.		provided by other header fields not defined by this specification.
	6.6. Content-Language		6.6. Content-Language
	The "Content-Language" header field describes the natural language(s)		The "Content-Language" header field describes the natural language(s)
	of the intended audience for the representation. Note that this		of the intended audience for the representation. Note that this
	might not be equivalent to all the languages used within the		might not be equivalent to all the languages used within the
	representation.		representation.
	Content-Language = "Content-Language" ":" OWS Content-Language-v		Content-Language = 1#language-tag
	Content-Language-v = 1#language-tag
	Language tags are defined in Section 2.4. The primary purpose of		Language tags are defined in Section 2.4. The primary purpose of
	Content-Language is to allow a user to identify and differentiate		Content-Language is to allow a user to identify and differentiate
	representations according to the user's own preferred language.		representations according to the user's own preferred language.
	Thus, if the body content is intended only for a Danish-literate		Thus, if the body content is intended only for a Danish-literate
	audience, the appropriate field is		audience, the appropriate field is
	Content-Language: da		Content-Language: da
	If no Content-Language is specified, the default is that the content		If no Content-Language is specified, the default is that the content
	skipping to change at page 24, line 13		skipping to change at page 23, line 13
	limited to textual documents.		limited to textual documents.
	6.7. Content-Location		6.7. Content-Location
	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 = "Content-Location" ":" OWS		Content-Location = absolute-URI / partial-URI
	Content-Location-v
	Content-Location-v =
	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 4.3 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
	skipping to change at page 25, line 33		skipping to change at page 24, line 30
	might be saved for use in other contexts, such as within source links		might be saved for use in other contexts, such as within source links
	or other metadata.		or other metadata.
	A cache cannot assume that a representation with a Content-Location		A cache cannot assume that a representation with a Content-Location
	different from the URI used to retrieve it can be used to respond to		different from the URI used to retrieve it can be used to respond to
	later requests on that Content-Location URI.		later requests on that Content-Location URI.
	If the Content-Location value is a partial URI, the partial URI is		If the Content-Location value is a partial URI, the partial URI is
	interpreted relative to the effective request URI.		interpreted relative to the effective request URI.
	6.8. Content-MD5		6.8. Content-Type
	The "Content-MD5" header field, as defined in [RFC1864], is an MD5
	digest of the payload body that provides an end-to-end message
	integrity check (MIC) of the payload body (the message-body after any
	transfer-coding is decoded). Note that a MIC is good for detecting
	accidental modification of the payload body in transit, but is not
	proof against malicious attacks.
	Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	The Content-MD5 header field MAY be generated by an origin server or
	client to function as an integrity check of the payload body. Only
	origin servers or user agents MAY generate the Content-MD5 header
	field; proxies MUST NOT generate it, as this would defeat its value
	as an end-to-end integrity check. Any recipient MAY check that the
	digest value in this header field matches a corresponding digest
	calculated on payload body as received.
	The MD5 digest is computed based on the content of the payload body,
	including any content-coding, but not including any transfer-coding
	applied to the message-body because such transfer-codings might be
	applied or removed anywhere along the request/response chain. If the
	message is received with a transfer-coding, that encoding MUST be
	decoded prior to checking the Content-MD5 value against the received
	payload.
	HTTP extends RFC 1864 to permit the digest to be computed for MIME
	composite media-types (e.g., multipart/* and message/rfc822), but
	this does not change how the digest is computed as defined in the
	preceding paragraph.
	There are several consequences of this. The payload for composite
	types MAY contain many body-parts, each with its own MIME and HTTP
	header fields (including Content-MD5, Content-Transfer-Encoding, and
	Content-Encoding header fields). If a body-part has a Content-
	Transfer-Encoding or Content-Encoding header field, it is assumed
	that the content of the body-part has had the encoding applied, and
	the body-part is included in the Content-MD5 digest as is -- i.e.,
	after the application. The Transfer-Encoding header field is not
	allowed within body-parts.
	Conversion of all line breaks to CRLF MUST NOT be done before
	computing or checking the digest: the line break convention used in
	the text actually transmitted MUST be left unaltered when computing
	the digest.
	Note: While the definition of Content-MD5 is exactly the same for
	HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
	in which the application of Content-MD5 to HTTP entity-bodies
	differs from its application to MIME entity-bodies. One is that
	HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
	does use Transfer-Encoding and Content-Encoding. Another is that
	HTTP more frequently uses binary content types than MIME, so it is
	worth noting that, in such cases, the byte order used to compute
	the digest is the transmission byte order defined for the type.
	Lastly, HTTP allows transmission of text types with any of several
	line break conventions and not just the canonical form using CRLF.
	6.9. Content-Type
	The "Content-Type" header field indicates the media type of the		The "Content-Type" header field indicates the media type of the
	representation. In the case of responses to the HEAD method, the		representation. In the case of responses to the HEAD method, the
	media type is that which would have been sent had the request been a		media type is that which would have been sent had the request been a
	GET.		GET.
	Content-Type = "Content-Type" ":" OWS Content-Type-v		Content-Type = media-type
	Content-Type-v = media-type
	Media types are defined in Section 2.3. An example of the field is		Media types are defined in Section 2.3. An example of the field is
	Content-Type: text/html; charset=ISO-8859-4		Content-Type: text/html; charset=ISO-8859-4
	Further discussion of Content-Type is provided in Section 4.2.		Further discussion of Content-Type is provided in Section 4.2.
	7. IANA Considerations		7. IANA Considerations
	7.1. Header Field Registration		7.1. Header Field Registration
	skipping to change at page 27, line 30		skipping to change at page 25, line 15
	+-------------------+----------+----------+--------------+		+-------------------+----------+----------+--------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+--------------+		+-------------------+----------+----------+--------------+
	| Accept | http | standard | Section 6.1 |		| Accept | http | standard | Section 6.1 |
	| Accept-Charset | http | standard | Section 6.2 |		| Accept-Charset | http | standard | Section 6.2 |
	| Accept-Encoding | http | standard | Section 6.3 |		| Accept-Encoding | http | standard | Section 6.3 |
	| Accept-Language | http | standard | Section 6.4 |		| Accept-Language | http | standard | Section 6.4 |
	| Content-Encoding | http | standard | Section 6.5 |		| Content-Encoding | http | standard | Section 6.5 |
	| Content-Language | http | standard | Section 6.6 |		| Content-Language | http | standard | Section 6.6 |
	| Content-Location | http | standard | Section 6.7 |		| Content-Location | http | standard | Section 6.7 |
	| Content-MD5 | http | standard | Section 6.8 |		| Content-Type | http | standard | Section 6.8 |
	| Content-Type | http | standard | Section 6.9 |
	| MIME-Version | http | standard | Appendix A.1 |		| MIME-Version | http | standard | Appendix A.1 |
	+-------------------+----------+----------+--------------+		+-------------------+----------+----------+--------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	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.
	skipping to change at page 29, line 20		skipping to change at page 26, line 46
	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		10. References
	10.1. Normative References		10.1. Normative References
	[ISO-8859-1] International Organization for Standardization,		[Part1] Fielding, R., Ed., Gettys, J.,
	"Information technology -- 8-bit single-byte coded		Mogul, J., Frystyk, H., Masinter,
	graphic character sets -- Part 1: Latin alphabet No.		L., Leach, P., Berners-Lee, T.,
	1", ISO/IEC 8859-1:1998, 1998.		Lafon, Y., Ed., and J. Reschke,
			Ed., "HTTP/1.1, part 1: URIs,
			Connections, and Message Parsing",
			draft-ietf-httpbis-p1-messaging-14
			(work in progress), April 2011.
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Mogul, J., Frystyk, H., Masinter,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,		L., Leach, P., Berners-Lee, T.,
	Connections, and Message Parsing",		Lafon, Y., Ed., and J. Reschke,
	draft-ietf-httpbis-p1-messaging-13 (work in progress),		Ed., "HTTP/1.1, part 2: Message
	March 2011.		Semantics",
			draft-ietf-httpbis-p2-semantics-14
			(work in progress), April 2011.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Mogul, J., Frystyk, H., Masinter,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message		L., Leach, P., Berners-Lee, T.,
	Semantics", draft-ietf-httpbis-p2-semantics-13 (work in		Lafon, Y., Ed., and J. Reschke,
	progress), March 2011.		Ed., "HTTP/1.1, part 4:
			Conditional Requests", draft-ietf-
			httpbis-p4-conditional-14 (work in
			progress), April 2011.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Mogul, J., Frystyk, H., Masinter,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:		L., Leach, P., Berners-Lee, T.,
	Conditional Requests",		Lafon, Y., Ed., and J. Reschke,
	draft-ietf-httpbis-p4-conditional-13 (work in		Ed., "HTTP/1.1, part 5: Range
	progress), March 2011.		Requests and Partial Responses",
			draft-ietf-httpbis-p5-range-14
			(work in progress), April 2011.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Mogul, J., Frystyk, H., Masinter,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range		L., Leach, P., Berners-Lee, T.,
	Requests and Partial Responses",		Lafon, Y., Ed., Nottingham, M.,
	draft-ietf-httpbis-p5-range-13 (work in progress),		Ed., and J. Reschke, Ed.,
	March 2011.		"HTTP/1.1, part 6: Caching",
			draft-ietf-httpbis-p6-cache-14
			(work in progress), April 2011.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,		Compressed Data Format
	Ed., Nottingham, M., Ed., and J. Reschke, Ed.,		Specification version 3.3",
	"HTTP/1.1, part 6: Caching",		RFC 1950, May 1996.
	draft-ietf-httpbis-p6-cache-13 (work in progress),
	March 2011.
	[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",		RFC 1950 is an Informational RFC,
	RFC 1864, October 1995.		thus it might be less stable than
			this specification. On the other
			hand, this downward reference was
			present since the publication of
			RFC 2068 in 1997 ([RFC2068]),
			therefore it is unlikely to cause
			problems in practice. See also
			[BCP97].
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[RFC1951] Deutsch, P., "DEFLATE Compressed
	Format Specification version 3.3", RFC 1950, May 1996.		Data Format Specification version
			1.3", RFC 1951, May 1996.
	RFC 1950 is an Informational RFC, thus it might be less		RFC 1951 is an Informational RFC,
	stable than this specification. On the other hand,		thus it might be less stable than
	this downward reference was present since the		this specification. On the other
	publication of RFC 2068 in 1997 ([RFC2068]), therefore		hand, this downward reference was
	it is unlikely to cause problems in practice. See also		present since the publication of
	[BCP97].		RFC 2068 in 1997 ([RFC2068]),
			therefore it is unlikely to cause
			problems in practice. See also
			[BCP97].
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format		[RFC1952] Deutsch, P., Gailly, J-L., Adler,
	Specification version 1.3", RFC 1951, May 1996.		M., Deutsch, L., and G. Randers-
			Pehrson, "GZIP file format
			specification version 4.3",
			RFC 1952, May 1996.
	RFC 1951 is an Informational RFC, thus it might be less		RFC 1952 is an Informational RFC,
	stable than this specification. On the other hand,		thus it might be less stable than
	this downward reference was present since the		this specification. On the other
	publication of RFC 2068 in 1997 ([RFC2068]), therefore		hand, this downward reference was
	it is unlikely to cause problems in practice. See also		present since the publication of
	[BCP97].		RFC 2068 in 1997 ([RFC2068]),
			therefore it is unlikely to cause
			problems in practice. See also
			[BCP97].
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and		[RFC2045] Freed, N. and N. Borenstein,
	G. Randers-Pehrson, "GZIP file format specification		"Multipurpose Internet Mail
	version 4.3", RFC 1952, May 1996.		Extensions (MIME) Part One: Format
			of Internet Message Bodies",
			RFC 2045, November 1996.
	RFC 1952 is an Informational RFC, thus it might be less		[RFC2046] Freed, N. and N. Borenstein,
	stable than this specification. On the other hand,		"Multipurpose Internet Mail
	this downward reference was present since the		Extensions (MIME) Part Two: Media
	publication of RFC 2068 in 1997 ([RFC2068]), therefore		Types", RFC 2046, November 1996.
	it is unlikely to cause problems in practice. See also
	[BCP97].
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC2119] Bradner, S., "Key words for use in
	Mail Extensions (MIME) Part One: Format of Internet		RFCs to Indicate Requirement
	Message Bodies", RFC 2045, November 1996.		Levels", BCP 14, RFC 2119,
			March 1997.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC4647] Phillips, A., Ed. and M. Davis,
	Mail Extensions (MIME) Part Two: Media Types",		Ed., "Matching of Language Tags",
	RFC 2046, November 1996.		BCP 47, RFC 4647, September 2006.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC5234] Crocker, D., Ed. and P. Overell,
	Requirement Levels", BCP 14, RFC 2119, March 1997.		"Augmented BNF for Syntax
			Specifications: ABNF", STD 68,
			RFC 5234, January 2008.
	[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of		[RFC5646] Phillips, A., Ed. and M. Davis,
	Language Tags", BCP 47, RFC 4647, September 2006.		Ed., "Tags for Identifying
			Languages", BCP 47, RFC 5646,
			September 2009.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for		10.2. Informative References
	Syntax Specifications: ABNF", STD 68, RFC 5234,
	January 2008.
	[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for		[BCP97] Klensin, J. and S. Hartman,
	Identifying Languages", BCP 47, RFC 5646,		"Handling Normative References to
	September 2009.		Standards-Track Documents",
			BCP 97, RFC 4897, June 2007.
	10.2. Informative References		[RFC1945] Berners-Lee, T., Fielding, R., and
			H. Nielsen, "Hypertext Transfer
			Protocol -- HTTP/1.0", RFC 1945,
			May 1996.
	[BCP97] Klensin, J. and S. Hartman, "Handling Normative		[RFC2049] Freed, N. and N. Borenstein,
	References to Standards-Track Documents", BCP 97,		"Multipurpose Internet Mail
	RFC 4897, June 2007.		Extensions (MIME) Part Five:
			Conformance Criteria and
			Examples", RFC 2049,
			November 1996.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,		[RFC2068] Fielding, R., Gettys, J., Mogul,
	"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,		J., Nielsen, H., and T. Berners-
	May 1996.		Lee, "Hypertext Transfer Protocol
			-- HTTP/1.1", RFC 2068,
			January 1997.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC2076] Palme, J., "Common Internet
	Mail Extensions (MIME) Part Five: Conformance Criteria		Message Headers", RFC 2076,
	and Examples", RFC 2049, November 1996.		February 1997.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and		[RFC2277] Alvestrand, H., "IETF Policy on
	T. Berners-Lee, "Hypertext Transfer Protocol --		Character Sets and Languages",
	HTTP/1.1", RFC 2068, January 1997.		BCP 18, RFC 2277, January 1998.
	[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,		[RFC2295] Holtman, K. and A. Mutz,
	February 1997.		"Transparent Content Negotiation
			in HTTP", RFC 2295, March 1998.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2388] Masinter, L., "Returning Values
	Languages", BCP 18, RFC 2277, January 1998.		from Forms: multipart/form-data",
			RFC 2388, August 1998.
	[RFC2295] Holtman, K. and A. Mutz, "Transparent Content		[RFC2557] Palme, F., Hopmann, A., Shelness,
	Negotiation in HTTP", RFC 2295, March 1998.		N., and E. Stefferud, "MIME
			Encapsulation of Aggregate
			Documents, such as HTML (MHTML)",
			RFC 2557, March 1999.
	[RFC2388] Masinter, L., "Returning Values from Forms: multipart/		[RFC2616] Fielding, R., Gettys, J., Mogul,
	form-data", RFC 2388, August 1998.		J., Frystyk, H., Masinter, L.,
			Leach, P., and T. Berners-Lee,
			"Hypertext Transfer Protocol --
			HTTP/1.1", RFC 2616, June 1999.
	[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,		[RFC3629] Yergeau, F., "UTF-8, a
	"MIME Encapsulation of Aggregate Documents, such as		transformation format of ISO
	HTML (MHTML)", RFC 2557, March 1999.		10646", STD 63, RFC 3629,
			November 2003.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC3864] Klyne, G., Nottingham, M., and J.
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Mogul, "Registration Procedures
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		for Message Header Fields",
			BCP 90, RFC 3864, September 2004.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC4288] Freed, N. and J. Klensin, "Media
	10646", STD 63, RFC 3629, November 2003.		Type Specifications and
			Registration Procedures", BCP 13,
			RFC 4288, December 2005.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC5226] Narten, T. and H. Alvestrand,
	Procedures for Message Header Fields", BCP 90,		"Guidelines for Writing an IANA
	RFC 3864, September 2004.		Considerations Section in RFCs",
			BCP 26, RFC 5226, May 2008.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications		[RFC5322] Resnick, P., "Internet Message
	and Registration Procedures", BCP 13, RFC 4288,		Format", RFC 5322, October 2008.
	December 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing		[RFC6151] Turner, S. and L. Chen, "Updated
	an IANA Considerations Section in RFCs", BCP 26,		Security Considerations for the
	RFC 5226, May 2008.		MD5 Message-Digest and the HMAC-
			MD5 Algorithms", RFC 6151,
			March 2011.
	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,		[draft-ietf-httpbis-content-disp] Reschke, J., "Use of the Content-
	October 2008.		Disposition Header Field in the
			Hypertext Transfer Protocol
			(HTTP)",
			draft-ietf-httpbis-content-disp-09
			(work in progress), March 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
	skipping to change at page 33, line 8		skipping to change at page 31, line 44
	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 compliance with the MIME protocol (as defined in [RFC2045]).
	Proxies/gateways are responsible for ensuring full compliance (where		Proxies/gateways are responsible for ensuring full compliance (where
	possible) when exporting HTTP messages to strict MIME environments.		possible) when exporting HTTP messages to strict MIME environments.
	MIME-Version = "MIME-Version" ":" OWS MIME-Version-v		MIME-Version = 1*DIGIT "." 1*DIGIT
	MIME-Version-v = 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
	MIME requires that an Internet mail body-part be converted to		MIME requires that an Internet mail body-part be converted to
	canonical form prior to being transferred, as described in Section 4		canonical form prior to being transferred, as described in Section 4
	of [RFC2049]. Section 2.3.1 of this document describes the forms		of [RFC2049]. Section 2.3.1 of this document describes the forms
	skipping to change at page 35, line 12		skipping to change at page 33, line 49
	[RFC1945] and [RFC2068] document protocol elements used by some		[RFC1945] and [RFC2068] document protocol elements used by some
	existing HTTP implementations, but not consistently and correctly		existing HTTP implementations, but not consistently and correctly
	across most HTTP/1.1 applications. Implementors are advised to be		across most HTTP/1.1 applications. Implementors are advised to be
	aware of these features, but cannot rely upon their presence in, or		aware of these features, but cannot rely upon their presence in, or
	interoperability with, other HTTP/1.1 applications. Some of these		interoperability with, other HTTP/1.1 applications. Some of these
	describe proposed experimental features, and some describe features		describe proposed experimental features, and some describe features
	that experimental deployment found lacking that are now addressed in		that experimental deployment found lacking that are now addressed in
	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 [RFC2076]).		Title, from SMTP and MIME are also often implemented (see
			[draft-ietf-httpbis-content-disp] 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)
			Remove the default character encoding for text media types; the
			default now is whatever the media type definition says.
			(Section 2.3.1)
			Change ABNF productions for header fields to only define the field
			value. (Section 6)
			Remove definition of Content-MD5 header field because it was
			inconsistently implemented with respect to partial responses, and
			also because of known deficiencies in the hash algorithm itself (see
			[RFC6151] for details). (Section 6)
			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 [draft-ietf-httpbis-content-disp]. (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)
	Appendix D. Collected ABNF		Appendix D. Collected ABNF
	Accept = "Accept:" OWS Accept-v		Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
	Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v		OWS media-range [ accept-params ] ] ) ]
	Accept-Charset-v = *( "," 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 = "Accept-Encoding:" OWS Accept-Encoding-v		Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )
	Accept-Encoding-v = [ ( "," / ( 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 = "Accept-Language:" OWS Accept-Language-v
	Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q="
	qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]		qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
	] )		] )
	Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
	OWS media-range [ accept-params ] ] ) ]
	Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v		Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
	Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS
	content-coding ] )		content-coding ] )
	Content-Language = "Content-Language:" OWS Content-Language-v		Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
	Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS
	language-tag ] )		language-tag ] )
	Content-Location = "Content-Location:" OWS Content-Location-v		Content-Location = absolute-URI / partial-URI
	Content-Location-v = absolute-URI / partial-URI		Content-Type = media-type
	Content-MD5 = "Content-MD5:" OWS Content-MD5-v
	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	Content-Type = "Content-Type:" OWS Content-Type-v
	Content-Type-v = media-type
	MIME-Version = "MIME-Version:" OWS MIME-Version-v		MIME-Version = 1*DIGIT "." 1*DIGIT
	MIME-Version-v = 1*DIGIT "." 1*DIGIT
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	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 / "*" )		codings = ( content-coding / "*" )
	skipping to change at page 37, line 4		skipping to change at page 35, line 39
	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 1.2.2>
	type = token		type = token
	value = word		value = word
	word = <word, defined in [Part1], Section 1.2.2>		word = <word, defined in [Part1], Section 1.2.2>
	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-MD5 defined but not used
	; Content-Type defined but not used		; Content-Type defined but not used
	; MIME-Version defined but not used		; MIME-Version defined but not used
	Appendix E. Change Log (to be removed by RFC Editor before publication)		Appendix E. Change Log (to be removed by RFC Editor before publication)
	E.1. Since RFC 2616		E.1. Since RFC 2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	E.2. Since draft-ietf-httpbis-p3-payload-00		E.2. Since draft-ietf-httpbis-p3-payload-00
	skipping to change at page 42, line 30		skipping to change at page 41, line 25
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header		o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
	Classification"		Classification"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/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/277>: "potentially		o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially
	misleading MAY in media-type def"		misleading MAY in media-type def"
			E.15. Since draft-ietf-httpbis-p3-payload-13
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/20>: "Default
			charsets for text media types"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
			and partial responses"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
			ABNFs for header fields"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing
			undefined parameter in media range example"
	Index		Index
	A		A
	Accept header field 16		Accept header field 16
	Accept-Charset header field 19		Accept-Charset header field 18
	Accept-Encoding header field 19		Accept-Encoding header field 19
	Accept-Language header field 21		Accept-Language header field 20
	C		C
	Coding Format		Coding Format
	compress 7		compress 7
	deflate 8		deflate 7
	gzip 8		gzip 7
	identity 8		identity 7
	compress (Coding Format) 7		compress (Coding Format) 7
	content negotiation 5		content negotiation 5
	Content-Encoding header field 22		Content-Encoding header field 21
	Content-Language header field 23		Content-Language header field 22
	Content-Location header field 24		Content-Location header field 23
	Content-MD5 header field 25		Content-Type header field 24
	Content-Type header field 26
	D		D
	deflate (Coding Format) 8		deflate (Coding Format) 7
	G		G
	Grammar		Grammar
	Accept 17		Accept 16
	Accept-Charset 19		Accept-Charset 18
	Accept-Charset-v 19		Accept-Encoding 19
	Accept-Encoding 20		accept-ext 16
	Accept-Encoding-v 20		Accept-Language 20
	accept-ext 17		accept-params 16
	Accept-Language 21		attribute 8
	Accept-Language-v 21
	accept-params 17
	Accept-v 17
	attribute 9
	charset 6		charset 6
	codings 20		codings 19
	content-coding 7		content-coding 7
	Content-Encoding 22		Content-Encoding 21
	Content-Encoding-v 22		Content-Language 22
	Content-Language 23		Content-Location 23
	Content-Language-v 23		Content-Type 24
	Content-Location 24		language-range 20
	Content-Location-v 24		language-tag 10
	Content-MD5 25		media-range 16
	Content-MD5-v 25		media-type 8
	Content-Type 26		MIME-Version 31
	Content-Type-v 26		parameter 8
	language-range 21		subtype 8
	language-tag 11		type 8
	media-range 17		value 8
	media-type 9		gzip (Coding Format) 7
	MIME-Version 33
	MIME-Version-v 33
	parameter 9
	subtype 9
	type 9
	value 9
	gzip (Coding Format) 8
	H		H
	Header Fields		Header Fields
	Accept 16		Accept 16
	Accept-Charset 19		Accept-Charset 18
	Accept-Encoding 19		Accept-Encoding 19
	Accept-Language 21		Accept-Language 20
	Content-Encoding 22		Content-Encoding 21
	Content-Language 23		Content-Language 22
	Content-Location 24		Content-Location 23
	Content-MD5 25		Content-Type 24
	Content-Type 26		MIME-Version 31
	MIME-Version 32
	I		I
	identity (Coding Format) 8		identity (Coding Format) 7
	M		M
	MIME-Version header field 32		MIME-Version header field 31
	P		P
	payload 11		payload 10
	R		R
	representation 12		representation 11
	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
End of changes. 100 change blocks.
	384 lines changed or deleted		348 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/