draft-ietf-httpbis-p3-payload-11.txt		draft-ietf-httpbis-p3-payload-12.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 Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: February 5, 2011 J. Mogul		Expires: April 28, 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
	August 4, 2010		October 25, 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-11		draft-ietf-httpbis-p3-payload-12
	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/3> 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.12.		The changes in this draft are summarized in Appendix E.13.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 5, 2011.		This Internet-Draft will expire on April 28, 2011.
	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
	skipping to change at page 3, line 37		skipping to change at page 3, line 37
	6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21		6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22		6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
	6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23		6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
	6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24		6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24
	6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25		6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25
	6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27		6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	7.1. Header Field Registration . . . . . . . . . . . . . . . . 27		7.1. Header Field Registration . . . . . . . . . . . . . . . . 27
	7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27		7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28		8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28
	8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . . 31		10.2. Informative References . . . . . . . . . . . . . . . . . . 31
	Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32		Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 34		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 35		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35
	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35		Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
			Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
	Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
	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) . . . . . . . . . . . . . . . . . . . . 37
	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38		E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
	E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41		E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40
	E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41		E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40
	E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42		E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41
	E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 42		E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42
			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 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.
	This document is currently disorganized in order to minimize the		This document is currently disorganized in order to minimize the
	changes between drafts and enable reviewers to see the smaller errata		changes between drafts and enable reviewers to see the smaller errata
	changes. The next draft will reorganize the sections to better		changes. A future draft will reorganize the sections to better
	reflect the content. In particular, the sections on entities will be		reflect the content. In particular, the sections on entities will be
	renamed payload and moved to the first half of the document, while		renamed payload and moved to the first half of the document, while
	the sections on content negotiation and associated request header		the sections on content negotiation and associated request header
	fields will be moved to the second half. The current mess reflects		fields will be moved to the second half. The current mess reflects
	how widely dispersed these topics and associated requirements had		how widely dispersed these topics and associated requirements had
	become in [RFC2616].		become in [RFC2616].
	1.1. Terminology		1.1. Terminology
	This specification uses a number of terms to refer to the roles		This specification uses a number of terms to refer to the roles
	skipping to change at page 6, line 23		skipping to change at page 6, line 23
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible USASCII character),		sequence of data), SP (space), VCHAR (any visible USASCII character),
	and WSP (whitespace).		and WSP (whitespace).
	1.3.1. Core Rules		1.3.1. Core Rules
	The core rules below are defined in Section 1.2.2 of [Part1]:		The core rules below are defined in Section 1.2.2 of [Part1]:
	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>		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>
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	qvalue = <qvalue, defined in [Part1], Section 6.4>		qvalue = <qvalue, defined in [Part1], Section 6.4>
	Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>		Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
	Content-Range = <Content-Range, defined in [Part5], Section 5.2>		Content-Range = <Content-Range, defined in [Part5], Section 5.2>
	Expires = <Expires, defined in [Part6], Section 3.3>		Expires = <Expires, defined in [Part6], Section 3.3>
	2. Protocol Parameters		2. Protocol Parameters
	skipping to change at page 7, line 37		skipping to change at page 7, line 35
	charset = token		charset = token
	Although HTTP allows an arbitrary token to be used as a charset		Although HTTP allows an arbitrary token to be used as a charset
	value, any token that has a predefined value within the IANA		value, any token that has a predefined value within the IANA
	Character Set registry MUST represent the character set defined by		Character Set registry MUST represent the character set defined by
	that registry. Applications SHOULD limit their use of character sets		that registry. Applications SHOULD limit their use of character sets
	to those defined by the IANA registry.		to those defined by the IANA registry.
	HTTP uses charset in two contexts: within an Accept-Charset request		HTTP uses charset in two contexts: within an Accept-Charset request
	header (in which the charset value is an unquoted token) and as the		header field (in which the charset value is an unquoted token) and as
	value of a parameter in a Content-Type header (within a request or		the value of a parameter in a Content-Type header field (within a
	response), in which case the parameter value of the charset parameter		request or response), in which case the parameter value of the
	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		2.1.1. Missing Charset
	Some HTTP/1.0 software has interpreted a Content-Type header without		Some HTTP/1.0 software has interpreted a Content-Type header field
	charset parameter incorrectly to mean "recipient should guess".		without charset parameter incorrectly to mean "recipient should
	Senders wishing to defeat this behavior MAY include a charset		guess". Senders wishing to defeat this behavior MAY include a
	parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and		charset parameter even when the charset is ISO-8859-1 ([ISO-8859-1])
	SHOULD do so when it is known that it will not confuse the recipient.		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		Unfortunately, some older HTTP/1.0 clients did not deal properly with
	an explicit charset parameter. HTTP/1.1 recipients MUST respect the		an explicit charset parameter. HTTP/1.1 recipients MUST respect the
	charset label provided by the sender; and those user agents that have		charset label provided by the sender; and those user agents that have
	a provision to "guess" a charset MUST use the charset from the		a provision to "guess" a charset MUST use the charset from the
	content-type field if they support that charset, rather than the		content-type field if they support that charset, rather than the
	recipient's preference, when initially displaying a document. See		recipient's preference, when initially displaying a document. See
	Section 2.3.1.		Section 2.3.1.
	2.2. Content Codings		2.2. Content Codings
	skipping to change at page 8, line 48		skipping to change at page 8, line 48
	See Section 6.2.2.2 of [Part1].		See Section 6.2.2.2 of [Part1].
	gzip		gzip
	See Section 6.2.2.3 of [Part1].		See Section 6.2.2.3 of [Part1].
	identity		identity
	The default (identity) encoding; the use of no transformation		The default (identity) encoding; the use of no transformation
	whatsoever. This content-coding is used only in the Accept-		whatsoever. This content-coding is used only in the Accept-
	Encoding header, and SHOULD NOT be used in the Content-Encoding		Encoding header field, and SHOULD NOT be used in the Content-
	header.		Encoding header field.
	2.2.1. Content Coding Registry		2.2.1. Content Coding Registry
	The HTTP Content Coding Registry defines the name space for the		The HTTP Content Coding Registry defines the name space for the
	content coding names.		content coding names.
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	skipping to change at page 17, line 18		skipping to change at page 17, line 18
	server-driven negotiation.		server-driven negotiation.
	6. Header Field Definitions		6. Header Field Definitions
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to the payload of messages.		fields related to the payload of messages.
	6.1. Accept		6.1. Accept
	The "Accept" request-header field can be used by user agents to		The "Accept" request-header field can be used by user agents to
	specify response media types that are acceptable. Accept headers can		specify response media types that are acceptable. Accept header
	be used to indicate that the request is specifically limited to a		fields can be used to indicate that the request is specifically
	small set of desired types, as in the case of a request for an in-		limited to a small set of desired types, as in the case of a request
	line image.		for an in-line image.
	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 [ "=" word ]
	[ "=" 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 19, line 50		skipping to change at page 19, line 50
	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 set (including ISO-8859-1) which is not		matches every character set (including ISO-8859-1) which is not
	mentioned elsewhere in the Accept-Charset field. If no "*" is		mentioned elsewhere in the Accept-Charset field. If no "*" is
	present in an Accept-Charset field, then all character sets not		present in an Accept-Charset field, then all character sets not
	explicitly mentioned get a quality value of 0, except for ISO-8859-1,		explicitly mentioned get a quality value of 0, except for ISO-8859-1,
	which gets a quality value of 1 if not explicitly mentioned.		which gets a quality value of 1 if not explicitly mentioned.
	If no Accept-Charset header is present, the default is that any		If no Accept-Charset header field is present, the default is that any
	character set is acceptable. If an Accept-Charset header is present,		character set is acceptable. If an Accept-Charset header field is
	and if the server cannot send a response which is acceptable		present, and if the server cannot send a response which is acceptable
	according to the Accept-Charset header, then the server SHOULD send		according to the Accept-Charset header field, then the server SHOULD
	an error response with the 406 (Not Acceptable) status code, though		send an error response with the 406 (Not Acceptable) status code,
	the sending of an unacceptable response is also allowed.		though the sending of an unacceptable response is also allowed.
	6.3. Accept-Encoding		6.3. Accept-Encoding
	The "Accept-Encoding" request-header field can be used by user agents		The "Accept-Encoding" request-header field can be used by user agents
	to indicate what response content-codings (Section 2.2) are		to indicate what response content-codings (Section 2.2) are
	acceptable in the response.		acceptable in the response.
	Accept-Encoding = "Accept-Encoding" ":" OWS		Accept-Encoding = "Accept-Encoding" ":" OWS
	Accept-Encoding-v		Accept-Encoding-v
	Accept-Encoding-v =		Accept-Encoding-v =
	skipping to change at page 21, line 8		skipping to change at page 21, line 8
	4. The "identity" content-coding is always acceptable, unless		4. The "identity" content-coding is always acceptable, unless
	specifically refused because the Accept-Encoding field includes		specifically refused because the Accept-Encoding field includes
	"identity;q=0", or because the field includes "*;q=0" and does		"identity;q=0", or because the field includes "*;q=0" and does
	not explicitly include the "identity" content-coding. If the		not explicitly include the "identity" content-coding. If the
	Accept-Encoding field-value is empty, then only the "identity"		Accept-Encoding field-value is empty, then only the "identity"
	encoding is acceptable.		encoding is acceptable.
	If an Accept-Encoding field is present in a request, and if the		If an Accept-Encoding field is present in a request, and if the
	server cannot send a response which is acceptable according to the		server cannot send a response which is acceptable according to the
	Accept-Encoding header, then the server SHOULD send an error response		Accept-Encoding header field, then the server SHOULD send an error
	with the 406 (Not Acceptable) status code.		response with the 406 (Not Acceptable) status code.
	If no Accept-Encoding field is present in a request, the server MAY		If no Accept-Encoding field is present in a request, the server MAY
	assume that the client will accept any content coding. In this case,		assume that the client will accept any content coding. In this case,
	if "identity" is one of the available content-codings, then the		if "identity" is one of the available content-codings, then the
	server SHOULD use the "identity" content-coding, unless it has		server SHOULD use the "identity" content-coding, unless it has
	additional information that a different content-coding is meaningful		additional information that a different content-coding is meaningful
	to the client.		to the client.
	Note: If the request does not include an Accept-Encoding field,		Note: If the request does not include an Accept-Encoding field,
	and if the "identity" content-coding is unavailable, then content-		and if the "identity" content-coding is unavailable, then content-
	skipping to change at page 22, line 13		skipping to change at page 22, line 13
	other types of English". (see also Section 2.3 of [RFC4647])		other types of English". (see also Section 2.3 of [RFC4647])
	For matching, Section 3 of [RFC4647] defines several matching		For matching, Section 3 of [RFC4647] defines several matching
	schemes. Implementations can offer the most appropriate matching		schemes. Implementations can offer the most appropriate matching
	scheme for their requirements.		scheme for their requirements.
	Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is		Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
	identical to the matching scheme that was previously defined in		identical to the matching scheme that was previously defined in
	Section 14.4 of [RFC2616].		Section 14.4 of [RFC2616].
	It might be contrary to the privacy expectations of the user to send		It might be contrary to the privacy expectations of the user to send
	an Accept-Language header with the complete linguistic preferences of		an Accept-Language header field with the complete linguistic
	the user in every request. For a discussion of this issue, see		preferences of the user in every request. For a discussion of this
	Section 8.1.		issue, see Section 8.1.
	As intelligibility is highly dependent on the individual user, it is		As intelligibility is highly dependent on the individual user, it is
	recommended that client applications make the choice of linguistic		recommended that client applications make the choice of linguistic
	preference available to the user. If the choice is not made		preference available to the user. If the choice is not made
	available, then the Accept-Language header field MUST NOT be given in		available, then the Accept-Language header field MUST NOT be given in
	the request.		the request.
	Note: When making the choice of linguistic preference available to		Note: When making the choice of linguistic preference available to
	the user, we remind implementors of the fact that users are not		the user, we remind implementors of the fact that users are not
	familiar with the details of language matching as described above,		familiar with the details of language matching as described above,
	skipping to change at page 26, line 28		skipping to change at page 26, line 28
	decoded prior to checking the Content-MD5 value against the received		decoded prior to checking the Content-MD5 value against the received
	payload.		payload.
	HTTP extends RFC 1864 to permit the digest to be computed for MIME		HTTP extends RFC 1864 to permit the digest to be computed for MIME
	composite media-types (e.g., multipart/* and message/rfc822), but		composite media-types (e.g., multipart/* and message/rfc822), but
	this does not change how the digest is computed as defined in the		this does not change how the digest is computed as defined in the
	preceding paragraph.		preceding paragraph.
	There are several consequences of this. The payload for composite		There are several consequences of this. The payload for composite
	types MAY contain many body-parts, each with its own MIME and HTTP		types MAY contain many body-parts, each with its own MIME and HTTP
	headers (including Content-MD5, Content-Transfer-Encoding, and		header fields (including Content-MD5, Content-Transfer-Encoding, and
	Content-Encoding headers). If a body-part has a Content-Transfer-		Content-Encoding header fields). If a body-part has a Content-
	Encoding or Content-Encoding header, it is assumed that the content		Transfer-Encoding or Content-Encoding header field, it is assumed
	of the body-part has had the encoding applied, and the body-part is		that the content of the body-part has had the encoding applied, and
	included in the Content-MD5 digest as is -- i.e., after the		the body-part is included in the Content-MD5 digest as is -- i.e.,
	application. The Transfer-Encoding header field is not allowed		after the application. The Transfer-Encoding header field is not
	within body-parts.		allowed within body-parts.
	Conversion of all line breaks to CRLF MUST NOT be done before		Conversion of all line breaks to CRLF MUST NOT be done before
	computing or checking the digest: the line break convention used in		computing or checking the digest: the line break convention used in
	the text actually transmitted MUST be left unaltered when computing		the text actually transmitted MUST be left unaltered when computing
	the digest.		the digest.
	Note: While the definition of Content-MD5 is exactly the same for		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		HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
	in which the application of Content-MD5 to HTTP entity-bodies		in which the application of Content-MD5 to HTTP entity-bodies
	differs from its application to MIME entity-bodies. One is that		differs from its application to MIME entity-bodies. One is that
	skipping to change at page 27, line 29		skipping to change at page 27, line 29
	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
	The Message Header Field Registry located at <http://www.iana.org/		The Message Header Field Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> shall be		assignments/message-headers/message-header-index.html> shall be
	updated with the permanent registrations below (see [RFC3864]):		updated with the permanent registrations below (see [RFC3864]):
	+---------------------+----------+----------+--------------+		+-------------------+----------+----------+--------------+
	| 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-Disposition | http | standard | Appendix B.1 |		| 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-MD5 | http | standard | Section 6.8 |		| Content-Type | http | standard | Section 6.9 |
	| 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.
	The HTTP Content Codings Registry located at		The HTTP Content Codings Registry located at
	skipping to change at page 28, line 32		skipping to change at page 28, line 30
	+----------+-----------------------------------------+--------------+		+----------+-----------------------------------------+--------------+
	8. Security Considerations		8. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	8.1. Privacy Issues Connected to Accept Headers		8.1. Privacy Issues Connected to Accept Header Fields
	Accept request-headers can reveal information about the user to all		Accept request-headers fields can reveal information about the user
	servers which are accessed. The Accept-Language header in particular		to all servers which are accessed. The Accept-Language header field
	can reveal information the user would consider to be of a private		in particular can reveal information the user would consider to be of
	nature, because the understanding of particular languages is often		a private nature, because the understanding of particular languages
	strongly correlated to the membership of a particular ethnic group.		is often strongly correlated to the membership of a particular ethnic
	User agents which offer the option to configure the contents of an		group. User agents which offer the option to configure the contents
	Accept-Language header to be sent in every request are strongly		of an Accept-Language header field to be sent in every request are
	encouraged to let the configuration process include a message which		strongly encouraged to let the configuration process include a
	makes the user aware of the loss of privacy involved.		message which makes the user aware of the loss of privacy involved.
	An approach that limits the loss of privacy would be for a user agent		An approach that limits the loss of privacy would be for a user agent
	to omit the sending of Accept-Language headers by default, and to ask		to omit the sending of Accept-Language header fields by default, and
	the user whether or not to start sending Accept-Language headers to a		to ask the user whether or not to start sending Accept-Language
	server if it detects, by looking for any Vary response-header fields		header fields to a server if it detects, by looking for any Vary
	generated by the server, that such sending could improve the quality		response-header fields generated by the server, that such sending
	of service.		could improve the quality of service.
	Elaborate user-customized accept header fields sent in every request,		Elaborate user-customized accept header fields sent in every request,
	in particular if these include quality values, can be used by servers		in particular if these include quality values, can be used by servers
	as relatively reliable and long-lived user identifiers. Such user		as relatively reliable and long-lived user identifiers. Such user
	identifiers would allow content providers to do click-trail tracking,		identifiers would allow content providers to do click-trail tracking,
	and would allow collaborating content providers to match cross-server		and would allow collaborating content providers to match cross-server
	click-trails or form submissions of individual users. Note that for		click-trails or form submissions of individual users. Note that for
	many users not behind a proxy, the network address of the host		many users not behind a proxy, the network address of the host
	running the user agent will also serve as a long-lived user		running the user agent will also serve as a long-lived user
	identifier. In environments where proxies are used to enhance		identifier. In environments where proxies are used to enhance
	privacy, user agents ought to be conservative in offering accept		privacy, user agents ought to be conservative in offering accept
	header configuration options to end users. As an extreme privacy		header configuration options to end users. As an extreme privacy
	measure, proxies could filter the accept headers in relayed requests.		measure, proxies could filter the accept header fields in relayed
	General purpose user agents which provide a high degree of header		requests. General purpose user agents which provide a high degree of
	configurability SHOULD warn users about the loss of privacy which can		header configurability SHOULD warn users about the loss of privacy
	be involved.		which can be involved.
	8.2. Content-Disposition Issues
	[RFC2183], from which the often implemented Content-Disposition (see
	Appendix B.1) header in HTTP is derived, has a number of very serious
	security considerations. Content-Disposition is not part of the HTTP
	standard, but since it is widely implemented, we are documenting its
	use and risks for implementors. See Section 5 of [RFC2183] for
	details.
	9. Acknowledgments		9. Acknowledgments
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[ISO-8859-1] International Organization for Standardization,		[ISO-8859-1] International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded		"Information technology -- 8-bit single-byte coded
	graphic character sets -- Part 1: Latin alphabet No.		graphic character sets -- Part 1: Latin alphabet No.
	1", ISO/IEC 8859-1:1998, 1998.		1", ISO/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.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,		Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,
	Connections, and Message Parsing",		Connections, and Message Parsing",
	draft-ietf-httpbis-p1-messaging-11 (work in progress),		draft-ietf-httpbis-p1-messaging-12 (work in progress),
	August 2010.		October 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.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., 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-11 (work in		Semantics", draft-ietf-httpbis-p2-semantics-12 (work in
	progress), August 2010.		progress), October 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.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:		Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:
	Conditional Requests",		Conditional Requests",
	draft-ietf-httpbis-p4-conditional-11 (work in		draft-ietf-httpbis-p4-conditional-12 (work in
	progress), August 2010.		progress), October 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.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range		Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
	Requests and Partial Responses",		Requests and Partial Responses",
	draft-ietf-httpbis-p5-range-11 (work in progress),		draft-ietf-httpbis-p5-range-12 (work in progress),
	August 2010.		October 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.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
	Ed., Nottingham, M., Ed., and J. Reschke, Ed.,		Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 6: Caching",		"HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-11 (work in progress),		draft-ietf-httpbis-p6-cache-12 (work in progress),
	August 2010.		October 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		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format 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 might be less		RFC 1950 is an Informational RFC, thus it might be less
	stable than this specification. On the other hand,		stable than this specification. On the other hand,
	this downward reference was present since the		this downward reference was present since the
	skipping to change at page 32, line 5		skipping to change at page 31, line 44
	Mail Extensions (MIME) Part Five: Conformance Criteria		Mail Extensions (MIME) Part Five: Conformance Criteria
	and Examples", RFC 2049, November 1996.		and Examples", RFC 2049, November 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
	T. Berners-Lee, "Hypertext Transfer Protocol --		T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", 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
	Presentation Information in Internet Messages: The
	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		[RFC2295] Holtman, K. and A. Mutz, "Transparent Content
	Negotiation 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		"MIME Encapsulation of Aggregate Documents, such as
	HTML (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", STD 63, RFC 3629, 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,		Procedures for Message Header Fields", BCP 90,
	RFC 3864, September 2004.		RFC 3864, September 2004.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
	and Registration Procedures", BCP 13, RFC 4288,		and Registration Procedures", BCP 13, RFC 4288,
	December 2005.		December 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
	skipping to change at page 35, line 27		skipping to change at page 35, line 16
	[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 headers, such as Content-Disposition and Title,		A number of other header fields, such as Content-Disposition and
	from SMTP and MIME are also often implemented (see [RFC2076]).		Title, from SMTP and MIME are also often implemented (see [RFC2076]).
	B.1. Content-Disposition
	The "Content-Disposition" response-header field has been proposed as
	a means for the origin server to suggest a default filename if the
	user requests that the content is saved to a file. This usage is
	derived from the definition of Content-Disposition in [RFC2183].
	content-disposition = "Content-Disposition" ":" OWS
	content-disposition-v
	content-disposition-v = disposition-type
	*( OWS ";" OWS disposition-parm )
	disposition-type = "attachment" / disp-extension-token
	disposition-parm = filename-parm / disp-extension-parm
	filename-parm = "filename" "=" quoted-string
	disp-extension-token = token
	disp-extension-parm = token "=" word
	An example is
	Content-Disposition: attachment; filename="fname.ext"
	The receiving user agent SHOULD NOT respect any directory path
	information present in the filename-parm parameter, which is the only
	parameter believed to apply to HTTP implementations at this time.
	The filename SHOULD be treated as a terminal component only.
	If this header is used in a response with the application/
	octet-stream content-type, the implied suggestion is that the user
	agent should not display the response, but directly enter a "save
	response as..." dialog.
	See Section 8.2 for Content-Disposition security issues.
	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 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 headers, and also the potentially		emitting bogus Content-Location header fields, and also the
	undesirable effect of potentially breaking relative links in content-		potentially undesirable effect of potentially breaking relative links
	negotiated resources. (Section 6.7)		in content-negotiated resources. (Section 6.7)
	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 = "Accept:" OWS Accept-v
	Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v		Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v
	Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="		Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
	qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="		qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
	skipping to change at page 37, line 28		skipping to change at page 36, line 32
	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 / "*" )
	content-coding = token		content-coding = token
	content-disposition = "Content-Disposition:" OWS
	content-disposition-v
	content-disposition-v = disposition-type *( OWS ";" OWS
	disposition-parm )
	disp-extension-parm = token "=" word
	disp-extension-token = token
	disposition-parm = filename-parm / disp-extension-parm
	disposition-type = "attachment" / disp-extension-token
	filename-parm = "filename=" quoted-string
	header-field = <header-field, defined in [Part1], Section 3.2>
	language-range = <language-range, defined in [RFC4647], Section 2.1>		language-range = <language-range, defined in [RFC4647], Section 2.1>
	language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>		language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
	media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS		media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
	";" OWS parameter )		";" OWS parameter )
	media-type = type "/" subtype *( OWS ";" OWS parameter )		media-type = type "/" subtype *( OWS ";" OWS parameter )
	parameter = attribute "=" value		parameter = attribute "=" value
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	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 = 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
	skipping to change at page 38, line 32		skipping to change at page 37, line 22
	; 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-Length defined but not used		; Content-Length defined but not used
	; Content-Location defined but not used		; Content-Location defined but not used
	; Content-MD5 defined but not used		; Content-MD5 defined but not used
	; Content-Range defined but not used		; Content-Range defined but not used
	; Content-Type defined but not used		; Content-Type defined but not used
	; Expires defined but not used		; Expires defined but not used
	; Last-Modified defined but not used		; Last-Modified defined but not used
	; MIME-Version defined but not used		; MIME-Version defined but not used
	; content-disposition defined but not used
	; header-field 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 RFC2616		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
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type		o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
	Registrations" (<http://purl.org/NET/http-errata#media-reg>)		Registrations" (<http://purl.org/NET/http-errata#media-reg>)
	skipping to change at page 40, line 5		skipping to change at page 38, line 41
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting		o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
	Charsets"		Charsets"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
	"Classification for Allow header"		"Classification for Allow header"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing		o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing
	default for qvalue in description of Accept-Encoding"		default for qvalue in description of Accept-Encoding"
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Field Registration
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header field registrations for
	defined in this document.		headers defined in this document.
	E.5. Since draft-ietf-httpbis-p3-payload-03		E.5. Since draft-ietf-httpbis-p3-payload-03
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting		o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
	Charsets"		Charsets"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag		o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag
	matching (Accept-Language) vs RFC4647"		matching (Accept-Language) vs RFC4647"
	skipping to change at page 40, line 46		skipping to change at page 39, line 33
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Use "/" instead of "|" for alternatives.		o Use "/" instead of "|" for alternatives.
	o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional		o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
	whitespace ("OWS") and required whitespace ("RWS").		whitespace ("OWS") and required whitespace ("RWS").
	o Rewrite ABNFs to spell out whitespace rules, factor out header		o Rewrite ABNFs to spell out whitespace rules, factor out header
	value format definitions.		field value format definitions.
	E.7. Since draft-ietf-httpbis-p3-payload-05		E.7. Since draft-ietf-httpbis-p3-payload-05
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join		o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
	"Differences Between HTTP Entities and RFC 2045 Entities"?"		"Differences Between HTTP Entities and RFC 2045 Entities"?"
	Final work on ABNF conversion		Final work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	skipping to change at page 43, line 28		skipping to change at page 42, line 13
	resource' in content-encoding definition"		resource' in content-encoding definition"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider		o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
	removing the 'changes from 2068' sections"		removing the 'changes from 2068' sections"
	Partly resolved issues:		Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5		o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
	and partial responses"		and partial responses"
			E.13. Since draft-ietf-httpbis-p3-payload-11
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out
			Content-Disposition"
	Index		Index
	A		A
	Accept header 17		Accept header 17
	Accept-Charset header 19		Accept-Charset header 19
	Accept-Encoding header 20		Accept-Encoding header 20
	Accept-Language header 21		Accept-Language header 21
	C		C
	Coding Format		Coding Format
	compress 8		compress 8
	deflate 8		deflate 8
	gzip 8		gzip 8
	identity 8		identity 8
	compress (Coding Format) 8		compress (Coding Format) 8
	content negotiation 5		content negotiation 5
	Content-Disposition header 35
	Content-Encoding header 22		Content-Encoding header 22
	Content-Language header 23		Content-Language header 23
	Content-Location header 24		Content-Location header 24
	Content-MD5 header 25		Content-MD5 header 25
	Content-Type header 27		Content-Type header 27
	D		D
	deflate (Coding Format) 8		deflate (Coding Format) 8
	G		G
	skipping to change at page 44, line 21		skipping to change at page 43, line 12
	Accept-Encoding-v 20		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 9		attribute 9
	charset 7		charset 7
	codings 20		codings 20
	content-coding 8		content-coding 8
	content-disposition 35
	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 25		Content-MD5 25
	Content-MD5-v 25		Content-MD5-v 25
	Content-Type 27		Content-Type 27
	Content-Type-v 27		Content-Type-v 27
	disp-extension-parm 35
	disp-extension-token 35
	disposition-parm 35
	disposition-type 35
	filename-parm 35
	language-range 21		language-range 21
	language-tag 11		language-tag 11
	media-range 17		media-range 17
	media-type 9		media-type 9
	MIME-Version 33		MIME-Version 33
	MIME-Version-v 33		MIME-Version-v 33
	parameter 9		parameter 9
	subtype 9		subtype 9
	type 9		type 9
	value 9		value 9
	gzip (Coding Format) 8		gzip (Coding Format) 8
	H		H
	Headers		Headers
	Accept 17		Accept 17
	Accept-Charset 19		Accept-Charset 19
	Accept-Encoding 20		Accept-Encoding 20
	Accept-Language 21		Accept-Language 21
	Content-Disposition 35
	Content-Encoding 22		Content-Encoding 22
	Content-Language 23		Content-Language 23
	Content-Location 24		Content-Location 24
	Content-MD5 25		Content-MD5 25
	Content-Type 27		Content-Type 27
	MIME-Version 33		MIME-Version 33
	I		I
	identity (Coding Format) 8		identity (Coding Format) 8
End of changes. 49 change blocks.
	193 lines changed or deleted		123 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/