draft-ietf-httpbis-p3-payload-18.txt		draft-ietf-httpbis-p3-payload-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: July 7, 2012 J. Mogul		Expires: August 6, 2012 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	January 4, 2012		February 3, 2012
	HTTP/1.1, part 3: Message Payload and Content Negotiation		HTTP/1.1, part 3: Message Payload and Content Negotiation
	draft-ietf-httpbis-p3-payload-18		draft-ietf-httpbis-p3-payload-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 3 of the		information initiative since 1990. This document is Part 3 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix E.19.		The changes in this draft are summarized in Appendix E.20.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 7, 2012.		This Internet-Draft will expire on August 6, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 44		skipping to change at page 3, line 44
	6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25		6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	7.1. Header Field Registration . . . . . . . . . . . . . . . . 25		7.1. Header Field Registration . . . . . . . . . . . . . . . . 25
	7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25		7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26		8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 27		10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
	10.2. Informative References . . . . . . . . . . . . . . . . . . 28		10.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. Differences between HTTP and MIME . . . . . . . . . . 29		Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32
	Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32		Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32
	skipping to change at page 4, line 29		skipping to change at page 4, line 29
	E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38		E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38
	E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38		E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38
	E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38		E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38
	E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39		E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39
	E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39		E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39
	E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39		E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39
	E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40		E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40
	E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40		E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40
	E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 40		E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 40
	E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 40		E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 40
			E.20. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 message payloads (a.k.a., content),		This document defines HTTP/1.1 message payloads (a.k.a., content),
	the associated metadata header fields that define how the payload is		the associated metadata header fields that define how the payload is
	intended to be interpreted by a recipient, the request header fields		intended to be interpreted by a recipient, the request header fields
	that might influence content selection, and the various selection		that might influence content selection, and the various selection
	algorithms that are collectively referred to as HTTP content		algorithms that are collectively referred to as HTTP content
	negotiation.		negotiation.
	skipping to change at page 6, line 18		skipping to change at page 6, line 18
	define specific error handling mechanisms, except in cases where it		define specific error handling mechanisms, except in cases where it
	has direct impact on security. This is because different uses of the		has direct impact on security. This is because different uses of the
	protocol require different error handling strategies; for example, a		protocol require different error handling strategies; for example, a
	Web browser may wish to transparently recover from a response where		Web browser may wish to transparently recover from a response where
	the Location header field doesn't parse according to the ABNF,		the Location header field doesn't parse according to the ABNF,
	whereby in a systems control protocol using HTTP, this type of error		whereby in a systems control protocol using HTTP, this type of error
	recovery could lead to dangerous consequences.		recovery could lead to dangerous consequences.
	1.3. Syntax Notation		1.3. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the Augmented Backus-Naur Form (ABNF)
	[Part1] (which extends the syntax defined in [RFC5234] with a list		notation of [RFC5234] with the list rule extension defined in Section
	rule). Appendix D shows the collected ABNF, with the list rule		1.2 of [Part1]. Appendix D shows the collected ABNF with the list
	expanded.		rule expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), and VCHAR (any visible US-ASCII		sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	1.3.1. Core Rules		1.3.1. Core Rules
	The core rules below are defined in [Part1]:		The core rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.4>
	word = <word, defined in [Part1], Section 3.2.3>		word = <word, defined in [Part1], Section 3.2.4>
	1.3.2. ABNF Rules defined in other Parts of the Specification		1.3.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	qvalue = <qvalue, defined in [Part1], Section 5.3>		qvalue = <qvalue, defined in [Part1], Section 5.3>
	2. Protocol Parameters		2. Protocol Parameters
	skipping to change at page 8, line 24		skipping to change at page 8, line 24
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	Names of content codings MUST NOT overlap with names of transfer		Names of content codings MUST NOT overlap with names of transfer
	codings (Section 5.1 of [Part1]), unless the encoding transformation		codings (Section 5.1 of [Part1]), unless the encoding transformation
	is identical (as it is the case for the compression codings defined		is identical (as is the case for the compression codings defined in
	in Section 5.1.2 of [Part1]).		Section 5.1.2 of [Part1]).
	Values to be added to this name space require a specification (see		Values to be added to this name space require a specification (see
	"Specification Required" in Section 4.1 of [RFC5226]), and MUST		"Specification Required" in Section 4.1 of [RFC5226]), and MUST
	conform to the purpose of content coding defined in this section.		conform to the purpose of content coding defined in this section.
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	2.3. Media Types		2.3. Media Types
	skipping to change at page 15, line 17		skipping to change at page 15, line 17
	of responses have multiple representations) and a potential		of responses have multiple representations) and a potential
	violation of the user's privacy.		violation of the user's privacy.
	3. It complicates the implementation of an origin server and the		3. It complicates the implementation of an origin server and the
	algorithms for generating responses to a request.		algorithms for generating responses to a request.
	4. It might limit a public cache's ability to use the same response		4. It might limit a public cache's ability to use the same response
	for multiple user's requests.		for multiple user's requests.
	Server-driven negotiation allows the user agent to specify its		Server-driven negotiation allows the user agent to specify its
	preferences, but it cannot expect responses to always honour them.		preferences, but it cannot expect responses to always honor them.
	For example, the origin server might not implement server-driven		For example, the origin server might not implement server-driven
	negotiation, or it might decide that sending a response that doesn't		negotiation, or it might decide that sending a response that doesn't
	conform to them is better than sending a 406 (Not Acceptable)		conform to them is better than sending a 406 (Not Acceptable)
	response.		response.
	Many of the mechanisms for expressing preferences use quality values		Many of the mechanisms for expressing preferences use quality values
	to declare relative preference. See Section 5.3 of [Part1] for more		to declare relative preference. See Section 5.3 of [Part1] for more
	information.		information.
	HTTP/1.1 includes the following header fields for enabling server-		HTTP/1.1 includes the following header fields for enabling server-
	skipping to change at page 26, line 33		skipping to change at page 26, line 33
	8. Security Considerations		8. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	8.1. Privacy Issues Connected to Accept Header Fields		8.1. Privacy Issues Connected to Accept Header Fields
	Accept headers fields can reveal information about the user to all		Accept header fields can reveal information about the user to all
	servers which are accessed. The Accept-Language header field in		servers which are accessed. The Accept-Language header field in
	particular can reveal information the user would consider to be of a		particular can reveal information the user would consider to be of a
	private nature, because the understanding of particular languages is		private nature, because the understanding of particular languages is
	often strongly correlated to the membership of a particular ethnic		often strongly correlated to the membership of a particular ethnic
	group. User agents which offer the option to configure the contents		group. User agents which offer the option to configure the contents
	of an Accept-Language header field to be sent in every request are		of an Accept-Language header field to be sent in every request are
	strongly encouraged to let the configuration process include a		strongly encouraged to let the configuration process include a
	message which makes the user aware of the loss of privacy involved.		message which makes the user aware of the loss of privacy involved.
	An approach that limits the loss of privacy would be for a user agent		An approach that limits the loss of privacy would be for a user agent
	skipping to change at page 27, line 29		skipping to change at page 27, line 29
	See Section 11 of [Part1].		See Section 11 of [Part1].
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-18		and Message Parsing",
	(work in progress), January 2012.		draft-ietf-httpbis-p1-messaging-latest (work in progress),
			February 2012.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-18 (work in		Semantics", draft-ietf-httpbis-p2-semantics-latest (work
	progress), January 2012.		in progress), February 2012.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-18 (work in		Requests", draft-ietf-httpbis-p4-conditional-latest (work
	progress), January 2012.		in progress), February 2012.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-18 (work		Partial Responses", draft-ietf-httpbis-p5-range-latest
	in progress), January 2012.		(work in progress), February 2012.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-18 (work in		6: Caching", draft-ietf-httpbis-p6-cache-latest (work in
	progress), January 2012.		progress), February 2012.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950, May 1996.		Specification version 3.3", RFC 1950, May 1996.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
	Randers-Pehrson, "GZIP file format specification version		Randers-Pehrson, "GZIP file format specification version
	4.3", RFC 1952, May 1996.		4.3", RFC 1952, May 1996.
	skipping to change at page 30, line 27		skipping to change at page 30, line 31
	necessary. Proxies and gateways from MIME environments to HTTP also		necessary. Proxies and gateways from MIME environments to HTTP also
	need to be aware of the differences because some conversions might be		need to be aware of the differences because some conversions might be
	required.		required.
	A.1. MIME-Version		A.1. MIME-Version
	HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages		HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
	MAY include a single MIME-Version header field to indicate what		MAY include a single MIME-Version header field to indicate what
	version of the MIME protocol was used to construct the message. Use		version of the MIME protocol was used to construct the message. Use
	of the MIME-Version header field indicates that the message is in		of the MIME-Version header field indicates that the message is in
	full compliance with the MIME protocol (as defined in [RFC2045]).		full conformance with the MIME protocol (as defined in [RFC2045]).
	Proxies/gateways are responsible for ensuring full compliance (where		Proxies/gateways are responsible for ensuring full conformance (where
	possible) when exporting HTTP messages to strict MIME environments.		possible) when exporting HTTP messages to strict MIME environments.
	MIME-Version = 1*DIGIT "." 1*DIGIT		MIME-Version = 1*DIGIT "." 1*DIGIT
	MIME version "1.0" is the default for use in HTTP/1.1. However,		MIME version "1.0" is the default for use in HTTP/1.1. However,
	HTTP/1.1 message parsing and semantics are defined by this document		HTTP/1.1 message parsing and semantics are defined by this document
	and not the MIME specification.		and not the MIME specification.
	A.2. Conversion to Canonical Form		A.2. Conversion to Canonical Form
	skipping to change at page 33, line 40		skipping to change at page 33, line 40
	Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS		Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
	content-coding ] )		content-coding ] )
	Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS		Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
	language-tag ] )		language-tag ] )
	Content-Location = absolute-URI / partial-URI		Content-Location = absolute-URI / partial-URI
	Content-Type = media-type		Content-Type = media-type
	MIME-Version = 1*DIGIT "." 1*DIGIT		MIME-Version = 1*DIGIT "." 1*DIGIT
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	accept-ext = OWS ";" OWS token [ "=" word ]		accept-ext = OWS ";" OWS token [ "=" word ]
	accept-params = OWS ";" OWS "q=" qvalue *accept-ext		accept-params = OWS ";" OWS "q=" qvalue *accept-ext
	attribute = token		attribute = token
	charset = token		charset = token
	codings = content-coding / "identity" / "*"		codings = content-coding / "identity" / "*"
	content-coding = token		content-coding = token
	skipping to change at page 34, line 17		skipping to change at page 34, line 17
	";" OWS parameter )		";" OWS parameter )
	media-type = type "/" subtype *( OWS ";" OWS parameter )		media-type = type "/" subtype *( OWS ";" OWS parameter )
	parameter = attribute "=" value		parameter = attribute "=" value
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	qvalue = <qvalue, defined in [Part1], Section 5.3>		qvalue = <qvalue, defined in [Part1], Section 5.3>
	subtype = token		subtype = token
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.4>
	type = token		type = token
	value = word		value = word
	word = <word, defined in [Part1], Section 3.2.3>		word = <word, defined in [Part1], Section 3.2.4>
	ABNF diagnostics:		ABNF diagnostics:
	; Accept defined but not used		; Accept defined but not used
	; Accept-Charset defined but not used		; Accept-Charset defined but not used
	; Accept-Encoding defined but not used		; Accept-Encoding defined but not used
	; Accept-Language defined but not used		; Accept-Language defined but not used
	; Content-Encoding defined but not used		; Content-Encoding defined but not used
	; Content-Language defined but not used		; Content-Language defined but not used
	; Content-Location defined but not used		; Content-Location defined but not used
	skipping to change at page 40, line 42		skipping to change at page 40, line 42
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document		o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
	HTTP's error-handling philosophy"		HTTP's error-handling philosophy"
	E.19. Since draft-ietf-httpbis-p3-payload-17		E.19. Since draft-ietf-httpbis-p3-payload-17
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended		o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
	maturity level vs normative references"		maturity level vs normative references"
			E.20. Since draft-ietf-httpbis-p3-payload-18
			None yet.
	Index		Index
	A		A
	Accept header field 16		Accept header field 16
	Accept-Charset header field 18		Accept-Charset header field 18
	Accept-Encoding header field 19		Accept-Encoding header field 19
	Accept-Language header field 20		Accept-Language header field 20
	C		C
	Coding Format		Coding Format
	compress 7		compress 7
	deflate 7		deflate 7
	gzip 8		gzip 8
	compress (Coding Format) 7		compress (Coding Format) 7
	content negotiation 5		content negotiation 5
	Content-Encoding header field 21		Content-Encoding header field 21
	Content-Language header field 22		Content-Language header field 22
	Content-Location header field 23		Content-Location header field 23
			Content-Transfer-Encoding header field 31
	Content-Type header field 25		Content-Type header field 25
	D		D
	deflate (Coding Format) 7		deflate (Coding Format) 7
	G		G
	Grammar		Grammar
	Accept 16		Accept 16
	Accept-Charset 18		Accept-Charset 18
	Accept-Encoding 19		Accept-Encoding 19
	skipping to change at page 42, line 4		skipping to change at page 42, line 8
	H		H
	Header Fields		Header Fields
	Accept 16		Accept 16
	Accept-Charset 18		Accept-Charset 18
	Accept-Encoding 19		Accept-Encoding 19
	Accept-Language 20		Accept-Language 20
	Content-Encoding 21		Content-Encoding 21
	Content-Language 22		Content-Language 22
	Content-Location 23		Content-Location 23
			Content-Transfer-Encoding 31
	Content-Type 25		Content-Type 25
	MIME-Version 30		MIME-Version 30
	M		M
	MIME-Version header field 30		MIME-Version header field 30
	P		P
	payload 11		payload 11
	R		R
End of changes. 24 change blocks.
	32 lines changed or deleted		40 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/