draft-ietf-httpbis-p3-payload-06.txt		draft-ietf-httpbis-p3-payload-07.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 One Laptop per Child
	Expires: September 10, 2009 J. Mogul		Expires: January 14, 2010 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 9, 2009		July 13, 2009
	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-06		draft-ietf-httpbis-p3-payload-07
	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 to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 10, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 41		skipping to change at page 2, line 41
	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/11> 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.7.		The changes in this draft are summarized in Appendix E.8.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 6		Specification . . . . . . . . . . . . . . . . . . . . 6
	2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6		2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 37		skipping to change at page 3, line 37
	4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14		4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
	4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15		4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15
	4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15		4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
	5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18		5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
	5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19		5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20		5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
	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 . . . . . . . . . . . . . . . . . . . . . . . 24
	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
	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 . . . . . . . . 27
	7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 27		7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 28		9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	9.2. Informative References . . . . . . . . . . . . . . . . . . 30		9.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A. Differences Between HTTP Entities and RFC 2045		Appendix A. Differences Between HTTP Entities and RFC 2045
	Entities . . . . . . . . . . . . . . . . . . . . . . 31		Entities . . . . . . . . . . . . . . . . . . . . . . 31
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32
	A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32		A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32
	A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32		A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33
	A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33		A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33
	A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33		A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33
	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33		B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34
	Appendix C. Compatibility with Previous Versions . . . . . . . . 34		Appendix C. Compatibility with Previous Versions . . . . . . . . 34
	C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34		C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34
	C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35		C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 37		publication) . . . . . . . . . . . . . . . . . . . . 37
	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 37		E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 37
	E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37		E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37
	E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38		E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38
	E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38		E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38
	E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38		E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39
	E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39		E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
	E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39		E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
			E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
	skipping to change at page 12, line 51		skipping to change at page 12, line 51
	message.		message.
	3.2.1. Type		3.2.1. Type
	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.		Content-Type specifies the media type of the underlying data. Any
			HTTP/1.1 message containing an entity-body SHOULD include a Content-
			Type header field defining the media type of that body, unless that
			information is unknown. If the Content-Type header field is not
			present, it indicates that the sender does not know the media type of
			the data; recipients MAY either assume that it is "application/
			octet-stream" ([RFC2046], Section 4.5.1) or examine the content to
			determine its type.
	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.
	Any HTTP/1.1 message containing an entity-body SHOULD include a		Note that neither the interpretation of the data type of a message
	Content-Type header field defining the media type of that body. If		nor the behaviors caused by it are defined by HTTP; this potentially
	and only if the media type is not given by a Content-Type field, the		includes examination of the content to override any indicated type
	recipient MAY attempt to guess the media type via inspection of its		("sniffing").
	content and/or the name extension(s) of the URI used to identify the
	resource. If the media type remains unknown, the recipient SHOULD
	treat it as type "application/octet-stream".
	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 4.4 of		before any transfer-codings have been applied. Section 4.4 of
	[Part1] defines how the transfer-length of a message-body is		[Part1] defines how the transfer-length of a message-body is
	determined.		determined.
	4. Content Negotiation		4. Content Negotiation
	skipping to change at page 24, line 33		skipping to change at page 24, line 42
	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.6 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 request-target.
	The meaning of the Content-Location header in PUT or POST requests is		The meaning of the Content-Location header in requests is undefined;
	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 entity-header field "Content-MD5", as defined in [RFC1864], is an		The entity-header field "Content-MD5", as defined in [RFC1864], is an
	MD5 digest of the entity-body for the purpose of providing an end-to-		MD5 digest of the entity-body for the purpose of providing an end-to-
	end message integrity check (MIC) of the entity-body. (Note: a MIC		end message integrity check (MIC) of the entity-body. (Note: a MIC
	is good for detecting accidental modification of the entity-body in		is good for detecting accidental modification of the entity-body in
	transit, but is not proof against malicious attacks.)		transit, but is not proof against malicious attacks.)
	Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v		Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
	Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>		Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
	The Content-MD5 header field MAY be generated by an origin server or		The Content-MD5 header field MAY be generated by an origin server or
	client to function as an integrity check of the entity-body. Only		client to function as an integrity check of the entity-body. Only
	origin servers or clients MAY generate the Content-MD5 header field;		origin servers or clients MAY generate the Content-MD5 header field;
	proxies and gateways MUST NOT generate it, as this would defeat its		proxies and gateways MUST NOT generate it, as this would defeat its
	value as an end-to-end integrity check. Any recipient of the entity-		value as an end-to-end integrity check. Any recipient of the entity-
	body, including gateways and proxies, MAY check that the digest value		body, including gateways and proxies, MAY check that the digest value
	in this header field matches that of the entity-body as received.		in this header field matches that of the entity-body as received.
	skipping to change at page 28, line 23		skipping to change at page 28, line 29
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 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., 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-06		and Message Parsing", draft-ietf-httpbis-p1-messaging-07
	(work in progress), March 2009.		(work in progress), July 2009.
	[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-06 (work in		Semantics", draft-ietf-httpbis-p2-semantics-07 (work in
	progress), March 2009.		progress), July 2009.
	[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-06 (work in		Requests", draft-ietf-httpbis-p4-conditional-07 (work in
	progress), March 2009.		progress), July 2009.
	[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-06 (work		Partial Responses", draft-ietf-httpbis-p5-range-07 (work
	in progress), March 2009.		in progress), July 2009.
	[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.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	draft-ietf-httpbis-p6-cache-06 (work in progress),		6: Caching", draft-ietf-httpbis-p6-cache-07 (work in
	March 2009.		progress), July 2009.
	[RFC1766] Alvestrand, H., "Tags for the Identification of		[RFC1766] Alvestrand, H., "Tags for the Identification of
	Languages", RFC 1766, March 1995.		Languages", RFC 1766, March 1995.
	[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 Format
	Specification version 3.3", RFC 1950, May 1996.		Specification version 3.3", RFC 1950, May 1996.
	skipping to change at page 32, line 28		skipping to change at page 32, line 33
	octets 13 and 10 to represent CR and LF, as is the case for some		octets 13 and 10 to represent CR and LF, as is the case for some
	multi-byte character sets.		multi-byte character sets.
	Implementors should note that conversion will break any cryptographic		Implementors should note that conversion will break any cryptographic
	checksums applied to the original content unless the original content		checksums applied to the original content unless the original content
	is already in canonical form. Therefore, the canonical form is		is already in canonical form. Therefore, the canonical form is
	recommended for any content that uses such checksums in HTTP.		recommended for any content that uses such checksums in HTTP.
	A.3. Conversion of Date Formats		A.3. Conversion of Date Formats
	HTTP/1.1 uses a restricted set of date formats (Section 3.2.1 of		HTTP/1.1 uses a restricted set of date formats (Section 3.2 of
	[Part1]) to simplify the process of date comparison. Proxies and		[Part1]) to simplify the process of date comparison. Proxies and
	gateways from other protocols SHOULD ensure that any Date header		gateways from other protocols SHOULD ensure that any Date header
	field present in a message conforms to one of the HTTP/1.1 formats		field present in a message conforms to one of the HTTP/1.1 formats
	and rewrite the date if necessary.		and rewrite the date if necessary.
	A.4. Introduction of Content-Encoding		A.4. Introduction of Content-Encoding
	RFC 2045 does not include any concept equivalent to HTTP/1.1's		RFC 2045 does not include any concept equivalent to HTTP/1.1's
	Content-Encoding header field. Since this acts as a modifier on the		Content-Encoding header field. Since this acts as a modifier on the
	media type, proxies and gateways from HTTP to MIME-compliant		media type, proxies and gateways from HTTP to MIME-compliant
	skipping to change at page 40, line 5		skipping to change at page 40, line 13
	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>):
	o Add appendix containing collected and expanded ABNF, reorganize		o Add appendix containing collected and expanded ABNF, reorganize
	ABNF introduction.		ABNF introduction.
	Other changes:		Other changes:
	o Move definition of quality values into Part 1.		o Move definition of quality values into Part 1.
			E.8. Since draft-ietf-httpbis-p3-payload-06
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content-
			Location isn't special"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
			Sniffing"
	Index		Index
	A		A
	Accept header 16		Accept header 16
	Accept-Charset header 18		Accept-Charset header 18
	Accept-Encoding header 19		Accept-Encoding header 19
	Accept-Language header 20		Accept-Language header 20
	Alternates header 35		Alternates header 35
	C		C
	compress 8		compress 8
			Content Type Sniffing 13
	Content-Base header 35		Content-Base header 35
	Content-Disposition header 33		Content-Disposition header 34
	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 24
	Content-Type header 26		Content-Type header 26
	Content-Version header 35		Content-Version header 35
	D		D
	deflate 8		deflate 8
	Derived-From header 35		Derived-From header 35
	G		G
	Grammar		Grammar
	Accept 16		Accept 16
	Accept-Charset 18		Accept-Charset 18
	Accept-Charset-v 18		Accept-Charset-v 18
	Accept-Encoding 19		Accept-Encoding 19
	Accept-Encoding-v 19		Accept-Encoding-v 19
	accept-ext 16		accept-ext 16
	Accept-Language 20		Accept-Language 21
	Accept-Language-v 20		Accept-Language-v 21
	accept-params 16		accept-params 16
	Accept-v 16		Accept-v 16
	attribute 9		attribute 9
	charset 7		charset 7
	codings 19		codings 19
	content-coding 8		content-coding 8
	content-disposition 34		content-disposition 34
	content-disposition-v 34		content-disposition-v 34
	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 34
	disp-extension-token 34		disp-extension-token 34
	disposition-parm 34		disposition-parm 34
	disposition-type 34		disposition-type 34
	entity-body 12		entity-body 12
	entity-header 12		entity-header 12
	extension-header 12		extension-header 12
	filename-parm 34		filename-parm 34
	language-range 20		language-range 21
	language-tag 11		language-tag 11
	media-range 16		media-range 16
	media-type 9		media-type 9
	MIME-Version 31		MIME-Version 31
	MIME-Version-v 31		MIME-Version-v 31
	parameter 9		parameter 9
	primary-tag 11		primary-tag 11
	subtag 11		subtag 11
	subtype 9		subtype 9
	type 9		type 9
	skipping to change at page 41, line 38		skipping to change at page 42, line 11
	gzip 8		gzip 8
	H		H
	Headers		Headers
	Accept 16		Accept 16
	Accept-Charset 18		Accept-Charset 18
	Accept-Encoding 19		Accept-Encoding 19
	Accept-Language 20		Accept-Language 20
	Alternate 35		Alternate 35
	Content-Base 35		Content-Base 35
	Content-Disposition 33		Content-Disposition 34
	Content-Encoding 22		Content-Encoding 22
	Content-Language 23		Content-Language 23
	Content-Location 23		Content-Location 24
	Content-MD5 24		Content-MD5 24
	Content-Type 26		Content-Type 26
	Content-Version 35		Content-Version 35
	Derived-From 35		Derived-From 35
	Link 35		Link 35
	MIME-Version 31		MIME-Version 31
	Public 35		Public 35
	URI 35		URI 35
	I		I
End of changes. 31 change blocks.
	43 lines changed or deleted		58 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/