draft-ietf-httpbis-p3-payload-09.txt		draft-ietf-httpbis-p3-payload-10.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track Alcatel-Lucent
	Expires: September 9, 2010 J. Mogul		Expires: January 13, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 8, 2010		July 12, 2010
	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-09		draft-ietf-httpbis-p3-payload-10
	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). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related		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.10.		The changes in this draft are summarized in Appendix E.11.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 3, line 14		skipping to change at page 3, line 4
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . . 7		2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7
	2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8		2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8
	2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8		2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8
	2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9		2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9
	2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9		2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10		2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10
	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11
	2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11		2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 12
	3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12		3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12
	3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13		3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13		3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 14
	4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14		4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14
	4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14		4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15
	4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16		4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
	5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19		5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
	5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19		5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20
	5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21		5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22		5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
	5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23		5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
	5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23		5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24
	5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24		5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25
	5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26		5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	6.1. Message Header Registration . . . . . . . . . . . . . . . 26		6.1. Message Header Registration . . . . . . . . . . . . . . . 26
	6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27		6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27		7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28
	7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28		7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 28		9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	9.2. Informative References . . . . . . . . . . . . . . . . . . 30		9.2. Informative References . . . . . . . . . . . . . . . . . . 31
	Appendix A. Differences Between HTTP Entities and RFC 2045		Appendix A. Differences Between HTTP Entities and RFC 2045
	Entities . . . . . . . . . . . . . . . . . . . . . . 31		Entities . . . . . . . . . . . . . . . . . . . . . . 32
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32		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 . . . . . . . . . . . . . 33		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33
	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 . . . . . . . . . . . . . . . . . 34		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34
	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34		B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35
	Appendix C. Compatibility with Previous Versions . . . . . . . . 35		Appendix C. Compatibility with Previous Versions . . . . . . . . 35
	C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35		C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35
	C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35		C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 38		publication) . . . . . . . . . . . . . . . . . . . . 38
	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38		E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 41
	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40		E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41
	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41		E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 41		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	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 may influence content selection, and the various selection		that may influence content selection, and the various selection
	algorithms that are collectively referred to as HTTP content		algorithms that are collectively referred to as HTTP content
	negotiation.		negotiation.
	skipping to change at page 6, line 13		skipping to change at page 6, line 13
	does not necessarily imply that the resource is subject to content		does not necessarily imply that the resource is subject to content
	negotiation.		negotiation.
	1.2. Requirements		1.2. Requirements
	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].
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	of the MUST or REQUIRED level requirements for the protocols it		of the "MUST" or "REQUIRED" level requirements for the protocols it
	implements. An implementation that satisfies all the MUST or		implements. An implementation that satisfies all the "MUST" or
	REQUIRED level and all the SHOULD level requirements for its		"REQUIRED" level and all the "SHOULD" level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the "MUST" level requirements but not all the "SHOULD"
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant".
	1.3. Syntax Notation		1.3. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the ABNF syntax defined in Section 1.2 of
	[Part1] (which extends the syntax defined in [RFC5234] with a list		[Part1] (which extends the syntax defined in [RFC5234] with a list
	rule). Appendix D shows the collected ABNF, with the list rule		rule). Appendix D shows the collected ABNF, with the list rule
	expanded.		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
	skipping to change at page 6, line 41		skipping to change at page 6, line 41
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible USASCII character),		sequence of data), SP (space), VCHAR (any visible USASCII character),
	and WSP (whitespace).		and WSP (whitespace).
	1.3.1. Core Rules		1.3.1. Core Rules
	The core rules below are defined in Section 1.2.2 of [Part1]:		The core rules below are defined in Section 1.2.2 of [Part1]:
	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>		quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
			word = <word, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	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.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	Content-Length = <Content-Length, defined in [Part1], Section 9.2>		Content-Length = <Content-Length, defined in [Part1], Section 9.2>
	header-field = <header-field, defined in [Part1], Section 3.2>		header-field = <header-field, defined in [Part1], Section 3.2>
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	skipping to change at page 9, line 30		skipping to change at page 9, line 30
	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
			codings (Section 6.2 of [Part1]), unless the encoding transformation
			is identical (as it is the case for the compression codings defined
			in Section 6.2.2 of [Part1]).
	Values to be added to this name space require expert review and a		Values to be added to this name space require expert review and a
	specification (see "Expert Review" and "Specification Required" in		specification (see "Expert Review" and "Specification Required" in
	Section 4.1 of [RFC5226]), and MUST conform to the purpose of content		Section 4.1 of [RFC5226]), and MUST 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
	skipping to change at page 10, line 7		skipping to change at page 10, line 10
	media-type = type "/" subtype *( OWS ";" OWS parameter )		media-type = type "/" subtype *( OWS ";" OWS parameter )
	type = token		type = token
	subtype = token		subtype = token
	Parameters MAY follow the type/subtype in the form of attribute/value		Parameters MAY follow the type/subtype in the form of attribute/value
	pairs.		pairs.
	parameter = attribute "=" value		parameter = attribute "=" value
	attribute = token		attribute = token
	value = token / quoted-string		value = word
	The type, subtype, and parameter attribute names are case-		The type, subtype, and parameter attribute names are case-
	insensitive. Parameter values might or might not be case-sensitive,		insensitive. Parameter values might or might not be case-sensitive,
	depending on the semantics of the parameter name. The presence or		depending on the semantics of the parameter name. The presence or
	absence of a parameter might be significant to the processing of a		absence of a parameter might be significant to the processing of a
	media-type, depending on its definition within the media type		media-type, depending on its definition within the media type
	registry.		registry.
	A parameter value that matches the token production may be		A parameter value that matches the token production may be
	transmitted as either a token or within a quoted-string. The quoted		transmitted as either a token or within a quoted-string. The quoted
	skipping to change at page 13, line 32		skipping to change at page 13, line 48
	When an entity-body is included with a message, the data type of that		When an entity-body is included with a message, the data type of that
	body is determined via the header fields Content-Type and Content-		body is determined via the header fields Content-Type and Content-
	Encoding. These define a two-layer, ordered encoding model:		Encoding. These define a two-layer, ordered encoding model:
	entity-body := Content-Encoding( Content-Type( data ) )		entity-body := Content-Encoding( Content-Type( data ) )
	Content-Type specifies the media type of the underlying data. Any		Content-Type specifies the media type of the underlying data. Any
	HTTP/1.1 message containing an entity-body SHOULD include a Content-		HTTP/1.1 message containing an entity-body SHOULD include a Content-
	Type header field defining the media type of that body, unless that		Type header field defining the media type of that body, unless that
	information is unknown. If the Content-Type header field is not		information is unknown.
	present, it indicates that the sender does not know the media type of
	the data; recipients MAY either assume that it is "application/		If the Content-Type header field is not present, it indicates that
	octet-stream" ([RFC2046], Section 4.5.1) or examine the content to		the sender does not know the media type of the data; recipients MAY
	determine its type.		either assume that it is "application/octet-stream" ([RFC2046],
			Section 4.5.1) or examine the content to determine its type.
			In practice, currently-deployed servers sometimes provide a Content-
			Type header which does not correctly convey the intended
			interpretation of the content sent, with the result that some clients
			will examine the response body's content and override the specified
			type.
			Client that do so risk drawing incorrect conclusions, which may
			expose additional security risks (e.g., "privilege escalation").
			Implementers are encouraged to provide a means of disabling such
			"content sniffing" when it is used.
	Content-Encoding may be used to indicate any additional content		Content-Encoding may be used to indicate any additional content
	codings applied to the data, usually for the purpose of data		codings applied to the data, usually for the purpose of data
	compression, that are a property of the requested resource. There is		compression, that are a property of the requested resource. There is
	no default encoding.		no default encoding.
	3.2.2. Entity Length		3.2.2. Entity Length
	The entity-length of a message is the length of the message-body		The entity-length of a message is the length of the message-body
	before any transfer-codings have been applied. Section 3.4 of		before any transfer-codings have been applied. Section 3.4 of
	skipping to change at page 17, line 14		skipping to change at page 17, line 38
	Accept = "Accept" ":" OWS Accept-v		Accept = "Accept" ":" OWS Accept-v
	Accept-v = #( 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		accept-ext = OWS ";" OWS token
	[ "=" ( token / quoted-string ) ]		[ "=" 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
	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
	skipping to change at page 22, line 32		skipping to change at page 23, line 10
	the identity of its underlying media type.		the identity of its underlying media type.
	Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v		Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v
	Content-Encoding-v = 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 entity identified by		The content-coding is a characteristic of the entity identified by
	the request-target. Typically, the entity-body is stored with this		the Effective Request URI (Section 4.3 of [Part1]). Typically, the
	encoding and is only decoded before rendering or analogous usage.		entity-body is stored with this encoding and is only decoded before
	However, a non-transparent proxy MAY modify the content-coding if the		rendering or analogous usage. However, a non-transparent proxy MAY
	new coding is known to be acceptable to the recipient, unless the		modify the content-coding if the new coding is known to be acceptable
	"no-transform" cache-control directive is present in the message.		to the recipient, unless the "no-transform" cache-control directive
			is present in the message.
	If the content-coding of an entity is not "identity", then the		If the content-coding of an entity is not "identity", then the
	response MUST include a Content-Encoding entity-header (Section 5.5)		response MUST include a Content-Encoding entity-header (Section 5.5)
	that lists the non-identity content-coding(s) used.		that lists the non-identity content-coding(s) used.
	If the content-coding of an entity in a request message is not		If the content-coding of an entity in a request message is not
	acceptable to the origin server, the server SHOULD respond with a		acceptable to the origin server, the server SHOULD respond with a
	status code of 415 (Unsupported Media Type).		status code of 415 (Unsupported Media Type).
	If multiple encodings have been applied to an entity, the content		If multiple encodings have been applied to an entity, the content
	skipping to change at page 24, line 14		skipping to change at page 24, line 40
	resource has multiple entities associated with it, and those entities		resource has multiple entities associated with it, and those entities
	actually have separate locations by which they might be individually		actually have separate locations by which they might be individually
	accessed, the server SHOULD provide a Content-Location for the		accessed, the server SHOULD provide a Content-Location for the
	particular variant which is returned.		particular variant which is returned.
	Content-Location = "Content-Location" ":" OWS		Content-Location = "Content-Location" ":" OWS
	Content-Location-v		Content-Location-v
	Content-Location-v =		Content-Location-v =
	absolute-URI / partial-URI		absolute-URI / partial-URI
	The Content-Location value is not a replacement for the original		The Content-Location value is not a replacement for the Effective
	requested URI; it is only a statement of the location of the resource		Request URI (Section 4.3 of [Part1]); it is only a statement of the
	corresponding to this particular entity at the time of the request.		location of the resource corresponding to this particular entity at
	Future requests MAY specify the Content-Location URI as the request-		the time of the request. Future requests MAY may be addressed to the
	target if the desire is to identify the source of that particular		Content-Location URI if the desire is to identify the source of that
	entity.		particular entity.
	Section 6.1 of [Part2] describes how clients may process the Content-		Section 6.1 of [Part2] describes how clients may process the Content-
	Location header field.		Location header field.
	A cache cannot assume that an entity with a Content-Location		A cache cannot assume that an entity 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. However, the Content-		later requests on that Content-Location URI. However, the Content-
	Location can be used to differentiate between multiple entities		Location can be used to differentiate between multiple entities
	retrieved from a single requested resource, as described in Section		retrieved from a single requested resource, as described in Section
	2.6 of [Part6].		2.7 of [Part6].
	If the Content-Location is a relative URI, the relative URI is		If the Content-Location is a relative URI, the relative URI is
	interpreted relative to the request-target.		interpreted relative to the Effective Request URI.
	The meaning of the Content-Location header in requests is undefined;		The meaning of the Content-Location header in requests is undefined;
	servers are free to ignore it in those cases.		servers are free to ignore it in those cases.
	5.8. Content-MD5		5.8. Content-MD5
	The "Content-MD5" entity-header field, as defined in [RFC1864], is an		The "Content-MD5" entity-header field, as defined in [RFC1864], is an
	MD5 digest of the entity-body that provides an end-to-end message		MD5 digest of the entity-body that provides an end-to-end message
	integrity check (MIC) of the entity-body. Note that a MIC is good		integrity check (MIC) of the entity-body. Note that a MIC is good
	for detecting accidental modification of the entity-body in transit,		for detecting accidental modification of the entity-body in transit,
	skipping to change at page 27, line 14		skipping to change at page 27, line 33
	6.2. Content Coding Registry		6.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> should be updated		<http://www.iana.org/assignments/http-parameters> should be updated
	with the registration below:		with the registration below:
	+----------+-----------------------------------+--------------------+		+----------+-----------------------------------------+--------------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+----------+-----------------------------------+--------------------+		+----------+-----------------------------------------+--------------+
	| compress | UNIX "compress" program method | Section 6.2.2.1 of |		| compress | UNIX "compress" program method | Section |
	| | | [Part1] |		| | | 6.2.2.1 of |
	| deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 of |		| | | [Part1] |
	| | "deflate" compression | [Part1] |		| deflate | "deflate" compression mechanism | Section |
	| gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 of |		| | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of |
	| | | [Part1] |		| | format ([RFC1950]) | [Part1] |
	| identity | No transformation | Section 2.2 |		| gzip | Same as GNU zip [RFC1952] | Section |
	+----------+-----------------------------------+--------------------+		| | | 6.2.2.3 of |
			| | | [Part1] |
			| identity | No transformation | Section 2.2 |
			+----------+-----------------------------------------+--------------+
	7. Security Considerations		7. 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.
	7.1. Privacy Issues Connected to Accept Headers		7.1. Privacy Issues Connected to Accept Headers
	skipping to change at page 28, line 36		skipping to change at page 29, line 11
	standard, but since it is widely implemented, we are documenting its		standard, but since it is widely implemented, we are documenting its
	use and risks for implementors. See Section 5 of [RFC2183] for		use and risks for implementors. See Section 5 of [RFC2183] for
	details.		details.
	8. Acknowledgments		8. Acknowledgments
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[ISO-8859-1]		[ISO-8859-1] International Organization for Standardization,
	International Organization for Standardization,		"Information technology -- 8-bit single-byte coded
	"Information technology -- 8-bit single-byte coded graphic		graphic character sets -- Part 1: Latin alphabet No.
	character sets -- Part 1: Latin alphabet No. 1", ISO/		1", ISO/IEC 8859-1:1998, 1998.
	IEC 8859-1:1998, 1998.
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-09		Connections, and Message Parsing",
	(work in progress), March 2010.		draft-ietf-httpbis-p1-messaging-10 (work in progress),
			July 2010.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-09 (work in		Semantics", draft-ietf-httpbis-p2-semantics-10 (work in
	progress), March 2010.		progress), July 2010.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:
	Requests", draft-ietf-httpbis-p4-conditional-09 (work in		Conditional Requests",
	progress), March 2010.		draft-ietf-httpbis-p4-conditional-10 (work in
			progress), July 2010.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
	Partial Responses", draft-ietf-httpbis-p5-range-09 (work		Requests and Partial Responses",
	in progress), March 2010.		draft-ietf-httpbis-p5-range-10 (work in progress),
			July 2010.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
	6: Caching", draft-ietf-httpbis-p6-cache-09 (work in		"HTTP/1.1, part 6: Caching",
	progress), March 2010.		draft-ietf-httpbis-p6-cache-10 (work in progress),
			July 2010.
	[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",		[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
	RFC 1864, October 1995.		RFC 1864, October 1995.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Specification version 3.3", RFC 1950, May 1996.		Format Specification version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus it may be less		RFC 1950 is an Informational RFC, thus it may be less
	stable than this specification. On the other hand, this		stable than this specification. On the other hand,
	downward reference was present since the publication of		this downward reference was present since the
	RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to		publication of RFC 2068 in 1997 ([RFC2068]), therefore
	cause problems in practice. See also [BCP97].		it is unlikely to cause problems in practice. See also
			[BCP97].
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	Randers-Pehrson, "GZIP file format specification version		Specification version 1.3", RFC 1951, May 1996.
	4.3", RFC 1952, May 1996.
	RFC 1952 is an Informational RFC, thus it may be less		RFC 1951 is an Informational RFC, thus it may be less
	stable than this specification. On the other hand, this		stable than this specification. On the other hand,
	downward reference was present since the publication of		this downward reference was present since the
	RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to		publication of RFC 2068 in 1997 ([RFC2068]), therefore
	cause problems in practice. See also [BCP97].		it is unlikely to cause problems in practice. See also
			[BCP97].
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
	Extensions (MIME) Part One: Format of Internet Message		G. Randers-Pehrson, "GZIP file format specification
	Bodies", RFC 2045, November 1996.		version 4.3", RFC 1952, May 1996.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		RFC 1952 is an Informational RFC, thus it may be less
	Extensions (MIME) Part Two: Media Types", RFC 2046,		stable than this specification. On the other hand,
	November 1996.		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].
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Mail Extensions (MIME) Part One: Format of Internet
			Message Bodies", RFC 2045, November 1996.
	[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
	Tags", BCP 47, RFC 4647, September 2006.		Mail Extensions (MIME) Part Two: Media Types",
			RFC 2046, November 1996.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying		[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of
	Languages", BCP 47, RFC 5646, September 2009.		Language Tags", BCP 47, RFC 4647, September 2006.
			[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
			Syntax Specifications: ABNF", STD 68, RFC 5234,
			January 2008.
			[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
			Identifying Languages", BCP 47, RFC 5646,
			September 2009.
	9.2. Informative References		9.2. Informative References
	[BCP97] Klensin, J. and S. Hartman, "Handling Normative References		[BCP97] Klensin, J. and S. Hartman, "Handling Normative
	to Standards-Track Documents", BCP 97, RFC 4897,		References to Standards-Track Documents", BCP 97,
	June 2007.		RFC 4897, June 2007.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.		"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
			May 1996.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
	Extensions (MIME) Part Five: Conformance Criteria and		Mail Extensions (MIME) Part Five: Conformance Criteria
	Examples", RFC 2049, November 1996.		and Examples", RFC 2049, November 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		T. Berners-Lee, "Hypertext Transfer Protocol --
	RFC 2068, January 1997.		HTTP/1.1", RFC 2068, January 1997.
	[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,		[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
	February 1997.		February 1997.
	[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating		[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
	Presentation Information in Internet Messages: The		Presentation Information in Internet Messages: The
	Content-Disposition Header Field", RFC 2183, August 1997.		Content-Disposition Header Field", RFC 2183,
			August 1997.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	Languages", BCP 18, RFC 2277, January 1998.		Languages", BCP 18, RFC 2277, January 1998.
	[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation		[RFC2295] Holtman, K. and A. Mutz, "Transparent Content
	in HTTP", RFC 2295, March 1998.		Negotiation in HTTP", RFC 2295, March 1998.
	[RFC2388] Masinter, L., "Returning Values from Forms: multipart/		[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
	form-data", RFC 2388, August 1998.		form-data", RFC 2388, August 1998.
	[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,		[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
	"MIME Encapsulation of Aggregate Documents, such as HTML		"MIME Encapsulation of Aggregate Documents, such as
	(MHTML)", RFC 2557, March 1999.		HTML (MHTML)", RFC 2557, March 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", RFC 3629, STD 63, November 2003.		10646", RFC 3629, STD 63, November 2003.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90,
	September 2004.		RFC 3864, September 2004.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
	Registration Procedures", BCP 13, RFC 4288, December 2005.		and Registration Procedures", BCP 13, RFC 4288,
			December 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		an IANA Considerations Section in RFCs", BCP 26,
	May 2008.		RFC 5226, May 2008.
	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	Appendix A. Differences Between HTTP Entities and RFC 2045 Entities		Appendix A. Differences Between HTTP Entities and RFC 2045 Entities
	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 entities to be transmitted in an open variety of		[RFC2045]) to allow entities to be transmitted in an open variety of
	representations and with extensible mechanisms. However, RFC 2045		representations and with extensible mechanisms. However, RFC 2045
	discusses mail, and HTTP has a few features that are different from		discusses mail, and HTTP has a few features that are different from
	those described in RFC 2045. These differences were carefully chosen		those described in RFC 2045. These differences were carefully chosen
	to optimize performance over binary connections, to allow greater		to optimize performance over binary connections, to allow greater
	skipping to change at page 34, line 34		skipping to change at page 35, line 21
	derived from the definition of Content-Disposition in [RFC2183].		derived from the definition of Content-Disposition in [RFC2183].
	content-disposition = "Content-Disposition" ":" OWS		content-disposition = "Content-Disposition" ":" OWS
	content-disposition-v		content-disposition-v
	content-disposition-v = disposition-type		content-disposition-v = disposition-type
	*( OWS ";" OWS disposition-parm )		*( OWS ";" OWS disposition-parm )
	disposition-type = "attachment" / disp-extension-token		disposition-type = "attachment" / disp-extension-token
	disposition-parm = filename-parm / disp-extension-parm		disposition-parm = filename-parm / disp-extension-parm
	filename-parm = "filename" "=" quoted-string		filename-parm = "filename" "=" quoted-string
	disp-extension-token = token		disp-extension-token = token
	disp-extension-parm = token "=" ( token / quoted-string )		disp-extension-parm = token "=" word
	An example is		An example is
	Content-Disposition: attachment; filename="fname.ext"		Content-Disposition: attachment; filename="fname.ext"
	The receiving user agent SHOULD NOT respect any directory path		The receiving user agent SHOULD NOT respect any directory path
	information present in the filename-parm parameter, which is the only		information present in the filename-parm parameter, which is the only
	parameter believed to apply to HTTP implementations at this time.		parameter believed to apply to HTTP implementations at this time.
	The filename SHOULD be treated as a terminal component only.		The filename SHOULD be treated as a terminal component only.
	skipping to change at page 36, line 38		skipping to change at page 37, line 25
	Expires = <Expires, defined in [Part6], Section 3.3>		Expires = <Expires, defined in [Part6], Section 3.3>
	Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>		Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
	MIME-Version = "MIME-Version:" OWS MIME-Version-v		MIME-Version = "MIME-Version:" OWS MIME-Version-v
	MIME-Version-v = 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 [ "=" ( token / quoted-string ) ]		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 / "*" )
	content-coding = token		content-coding = token
	content-disposition = "Content-Disposition:" OWS		content-disposition = "Content-Disposition:" OWS
	content-disposition-v		content-disposition-v
	content-disposition-v = disposition-type *( OWS ";" OWS		content-disposition-v = disposition-type *( OWS ";" OWS
	disposition-parm )		disposition-parm )
	disp-extension-parm = token "=" ( token / quoted-string )		disp-extension-parm = token "=" word
	disp-extension-token = token		disp-extension-token = token
	disposition-parm = filename-parm / disp-extension-parm		disposition-parm = filename-parm / disp-extension-parm
	disposition-type = "attachment" / disp-extension-token		disposition-type = "attachment" / disp-extension-token
	entity-body = *OCTET		entity-body = *OCTET
	entity-header = Content-Encoding / Content-Language / Content-Length		entity-header = Content-Encoding / Content-Language / Content-Length
	/ Content-Location / Content-MD5 / Content-Range / Content-Type /		/ Content-Location / Content-MD5 / Content-Range / Content-Type /
	Expires / Last-Modified / extension-header		Expires / Last-Modified / extension-header
	extension-header = header-field		extension-header = header-field
	skipping to change at page 37, line 35		skipping to change at page 38, line 22
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>		quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	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 = token / quoted-string		value = word
			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
	; MIME-Version defined but not used		; MIME-Version defined but not used
	; content-disposition defined but not used		; content-disposition defined but not used
	; entity-body defined but not used		; entity-body defined but not used
	skipping to change at page 41, line 47		skipping to change at page 42, line 25
	E.10. Since draft-ietf-httpbis-p3-payload-08		E.10. Since draft-ietf-httpbis-p3-payload-08
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content		o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content
	Negotiation for media types"		Negotiation for media types"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-
	Language: which RFC4647 filtering?"		Language: which RFC4647 filtering?"
			E.11. Since draft-ietf-httpbis-p3-payload-09
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
			for content/transfer encodings"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
			Sniffing"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
			"word" when talking about header structure"
			Partly resolved issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
			requested resource's URI"
	Index		Index
	A		A
	Accept header 16		Accept header 17
	Accept-Charset header 19		Accept-Charset header 19
	Accept-Encoding header 19		Accept-Encoding header 20
	Accept-Language header 21		Accept-Language header 21
	Alternates header 35		Alternates header 36
	C		C
	Coding Format		Coding Format
	compress 8		compress 8
	deflate 8		deflate 8
	gzip 9		gzip 9
	identity 9		identity 9
	compress (Coding Format) 8		compress (Coding Format) 8
	content negotiation 5		content negotiation 5
	Content-Base header 35		Content-Base header 36
	Content-Disposition header 34		Content-Disposition header 35
	Content-Encoding header 22		Content-Encoding header 22
	Content-Language header 23		Content-Language header 23
	Content-Location header 23		Content-Location header 24
	Content-MD5 header 24		Content-MD5 header 25
	Content-Type header 26		Content-Type header 26
	Content-Version header 35		Content-Version header 36
	D		D
	deflate (Coding Format) 8		deflate (Coding Format) 8
	Derived-From header 35		Derived-From header 36
	E		E
	entity 5		entity 5
	G		G
	Grammar		Grammar
	Accept 17		Accept 17
	Accept-Charset 19		Accept-Charset 19
	Accept-Charset-v 19		Accept-Charset-v 19
	Accept-Encoding 19		Accept-Encoding 20
	Accept-Encoding-v 19		Accept-Encoding-v 20
	accept-ext 17		accept-ext 17
	Accept-Language 21		Accept-Language 21
	Accept-Language-v 21		Accept-Language-v 21
	accept-params 17		accept-params 17
	Accept-v 17		Accept-v 17
	attribute 10		attribute 10
	charset 7		charset 7
	codings 19		codings 20
	content-coding 8		content-coding 8
	content-disposition 34		content-disposition 35
	content-disposition-v 34		content-disposition-v 35
	Content-Encoding 22		Content-Encoding 22
	Content-Encoding-v 22		Content-Encoding-v 22
	Content-Language 23		Content-Language 23
	Content-Language-v 23		Content-Language-v 23
	Content-Location 24		Content-Location 24
	Content-Location-v 24		Content-Location-v 24
	Content-MD5 24		Content-MD5 25
	Content-MD5-v 24		Content-MD5-v 25
	Content-Type 26		Content-Type 26
	Content-Type-v 26		Content-Type-v 26
	disp-extension-parm 34		disp-extension-parm 35
	disp-extension-token 34		disp-extension-token 35
	disposition-parm 34		disposition-parm 35
	disposition-type 34		disposition-type 35
	entity-body 13		entity-body 13
	entity-header 12		entity-header 13
	extension-header 12		extension-header 13
	filename-parm 34		filename-parm 35
	language-range 21		language-range 21
	language-tag 12		language-tag 12
	media-range 17		media-range 17
	media-type 9		media-type 9
	MIME-Version 32		MIME-Version 32
	MIME-Version-v 32		MIME-Version-v 32
	parameter 10		parameter 10
	subtype 9		subtype 9
	type 9		type 9
	value 10		value 10
	gzip (Coding Format) 9		gzip (Coding Format) 9
	H		H
	Headers		Headers
	Accept 16		Accept 17
	Accept-Charset 19		Accept-Charset 19
	Accept-Encoding 19		Accept-Encoding 20
	Accept-Language 21		Accept-Language 21
	Alternate 35		Alternate 36
	Content-Base 35		Content-Base 36
	Content-Disposition 34		Content-Disposition 35
	Content-Encoding 22		Content-Encoding 22
	Content-Language 23		Content-Language 23
	Content-Location 23		Content-Location 24
	Content-MD5 24		Content-MD5 25
	Content-Type 26		Content-Type 26
	Content-Version 35		Content-Version 36
	Derived-From 35		Derived-From 36
	Link 35		Link 36
	MIME-Version 32		MIME-Version 32
	Public 35		Public 36
	URI 35		URI 36
	I		I
	identity (Coding Format) 9		identity (Coding Format) 9
	L		L
	Link header 35		Link header 36
	M		M
	MIME-Version header 32		MIME-Version header 32
	P		P
	Public header 35		Public header 36
	R		R
	representation 5		representation 5
	U		U
	URI header 35		URI header 36
	V		V
	variant 5		variant 5
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
	Fax: +1-949-706-5305		Fax: +1-949-706-5305
	Email: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Jim Gettys		Jim Gettys
	One Laptop per Child		Alcatel-Lucent Bell Labs
	21 Oak Knoll Road		21 Oak Knoll Road
	Carlisle, MA 01741		Carlisle, MA 01741
	USA		USA
	Email: jg@laptop.org		EMail: jg@freedesktop.org
	URI: http://www.laptop.org/		URI: http://gettys.wordpress.com/
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Hewlett-Packard Company		Hewlett-Packard Company
	HP Labs, Large Scale Systems Group		HP Labs, Large Scale Systems Group
	1501 Page Mill Road, MS 1177		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94304		Palo Alto, CA 94304
	USA		USA
	Email: JeffMogul@acm.org		EMail: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: henrikn@microsoft.com		EMail: henrikn@microsoft.com
	Larry Masinter		Larry Masinter
	Adobe Systems, Incorporated		Adobe Systems, Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	Email: LMM@acm.org		EMail: LMM@acm.org
	URI: http://larry.masinter.net/		URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		EMail: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		EMail: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		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/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	Phone: +49 251 2807760		Phone: +49 251 2807760
	Fax: +49 251 2807761		Fax: +49 251 2807761
	Email: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 110 change blocks.
	238 lines changed or deleted		295 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/