p3-payload-orig.txt		draft-fielding-http-p3-payload-00.txt
	Network Working Group R. Fielding		Network Working Group R. Fielding, Ed.
	Internet-Draft UC Irvine		Internet-Draft Day Software
	Obsoletes: 2068, 2616, 2617 J. Gettys		Obsoletes: 2068, 2616, 2617 J. Gettys
	(if approved) Compaq/W3C		(if approved) J. Mogul
	Intended status: Standards Track J. Mogul		Intended status: Standards Track HP
	Expires: March 4, 2008 Compaq		Expires: May 14, 2008 H. Frystyk
	H. Frystyk		Microsoft
	W3C/MIT
	L. Masinter		L. Masinter
	Xerox		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	September 2007		November 11, 2007
	HTTP/1.1, part 3: Payload		HTTP/1.1, part 3: Message Payload and Content Negotiation
	draft-fielding-http-p3-payload-00		draft-fielding-http-p3-payload-00
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 1, line 45		skipping to change at page 1, line 44
	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 March 4, 2008.		This Internet-Draft will expire on May 14, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 5		2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 5
	2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 5		2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 7		2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 7
	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 8		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 8
	2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 8		2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 8
	2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 9		2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 9
	3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 9		3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 10
	3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 10		3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 11		3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 11
	4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 11		4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 11		4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 12
	4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 13		4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 13
	4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 13		4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 13
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 14		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 14
	5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 16		5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 16		5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 17
	5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 18		5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 18
	5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 19		5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 19
	5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 20		5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 20
	5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 21		5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 21
	5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 21		5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 22
	5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 23		5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 23
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 23		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	6.1. Privacy Issues Connected to Accept Headers . . . . . . . . 23		7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	6.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 24		7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 23
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 24
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Appendix A. Differences Between HTTP Entities and RFC 2045		Appendix A. Differences Between HTTP Entities and RFC 2045
	Entities . . . . . . . . . . . . . . . . . . . . . . 26		Entities . . . . . . . . . . . . . . . . . . . . . . 26
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 26		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 26
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 26		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 27
	A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 27		A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 27
	A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 27		A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 27
	A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 27		A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 28
	A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 28		A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 28
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 28		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 28
	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 28		B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 28
	Appendix C. Changes from RFC 2068 . . . . . . . . . . . . . . . . 29		Appendix C. Changes from RFC 2068 . . . . . . . . . . . . . . . . 29
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
	Intellectual Property and Copyright Statements . . . . . . . . . . 34		Intellectual Property and Copyright Statements . . . . . . . . . . 34
	1. Introduction		1. Introduction
	This document will define aspects of HTTP related to the payload of		This document will define aspects of HTTP related to the payload of
	messages (message content), including metadata and media types, along		messages (message content), including metadata and media types, along
	with HTTP content negotiation. Right now it only includes the		with HTTP content negotiation. Right now it only includes the
	extracted relevant sections of RFC 2616 without edit.		extracted relevant sections of RFC 2616 without edit.
	2. Protocol Parameters		2. Protocol Parameters
	skipping to change at page 4, line 50		skipping to change at page 4, line 50
	[RFC1700].		[RFC1700].
	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 [RFC1700] MUST represent the character set		Character Set registry [RFC1700] MUST represent the character set
	defined by that registry. Applications SHOULD limit their use of		defined by that registry. Applications SHOULD limit their use of
	character sets to those defined by the IANA registry.		character sets to those defined by the IANA registry.
			HTTP uses charset in two contexts: within an Accept-Charset request
			header (in which the charset value is an unquoted token) and as the
			value of a parameter in a Content-type header (within a request or
			response), in which case the parameter value of the charset parameter
			may be quoted.
	Implementors should be aware of IETF character set requirements		Implementors should be aware of IETF character set requirements
	[RFC2279] [RFC2277].		[RFC2279] [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 without
	charset parameter incorrectly to mean "recipient should guess."		charset parameter incorrectly to mean "recipient should guess."
	Senders wishing to defeat this behavior MAY include a charset		Senders wishing to defeat this behavior MAY include a charset
	parameter even when the charset is ISO-8859-1 and SHOULD do so when		parameter even when the charset is ISO-8859-1 and SHOULD do so when
	it is known that it will not confuse the recipient.		it is known that it will not confuse the recipient.
	skipping to change at page 6, line 34		skipping to change at page 6, line 42
	header.		header.
	New content-coding value tokens SHOULD be registered; to allow		New content-coding value tokens SHOULD be registered; to allow
	interoperability between clients and servers, specifications of the		interoperability between clients and servers, specifications of the
	content coding algorithms needed to implement a new value SHOULD be		content coding algorithms needed to implement a new value SHOULD be
	publicly available and adequate for independent implementation, and		publicly available and adequate for independent implementation, and
	conform to the purpose of content coding defined in this section.		conform to the purpose of content coding defined in this section.
	2.3. Media Types		2.3. Media Types
	HTTP uses Internet Media Types [RFC1590] in the Content-Type		HTTP uses Internet Media Types [RFC4288] in the Content-Type
	(Section 5.9) and Accept (Section 5.1) header fields in order to		(Section 5.9) and Accept (Section 5.1) header fields in order to
	provide open and extensible data typing and type negotiation.		provide open and extensible data typing and type negotiation.
	media-type = type "/" subtype *( ";" parameter )		media-type = type "/" subtype *( ";" parameter )
	type = token		type = token
	subtype = token		subtype = token
	Parameters MAY follow the type/subtype in the form of attribute/value		Parameters MAY follow the type/subtype in the form of attribute/value
	pairs.		pairs.
	skipping to change at page 7, line 16		skipping to change at page 7, line 24
	might be significant to the processing of a media-type, depending on		might be significant to the processing of a media-type, depending on
	its definition within the media type registry.		its definition within the media type registry.
	Note that some older HTTP applications do not recognize media type		Note that some older HTTP applications do not recognize media type
	parameters. When sending data to older HTTP applications,		parameters. When sending data to older HTTP applications,
	implementations SHOULD only use media type parameters when they are		implementations SHOULD only use media type parameters when they are
	required by that type/subtype definition.		required by that type/subtype definition.
	Media-type values are registered with the Internet Assigned Number		Media-type values are registered with the Internet Assigned Number
	Authority (IANA [RFC1700]). The media type registration process is		Authority (IANA [RFC1700]). The media type registration process is
	outlined in RFC 1590 [RFC1590]. Use of non-registered media types is		outlined in RFC 4288 [RFC4288]. Use of non-registered media types is
	discouraged.		discouraged.
	2.3.1. Canonicalization and Text Defaults		2.3.1. Canonicalization and Text Defaults
	Internet media types are registered with a canonical form. An		Internet media types are registered with a canonical form. An
	entity-body transferred via HTTP messages MUST be represented in the		entity-body transferred via HTTP messages MUST be represented in the
	appropriate canonical form prior to its transmission except for		appropriate canonical form prior to its transmission except for
	"text" types, as defined in the next paragraph.		"text" types, as defined in the next paragraph.
	When in canonical form, media subtypes of the "text" type use CRLF as		When in canonical form, media subtypes of the "text" type use CRLF as
	skipping to change at page 19, line 12		skipping to change at page 19, line 17
	the field that matches the language-tag. If no language-range in the		the field that matches the language-tag. If no language-range in the
	field matches the tag, the language quality factor assigned is 0. If		field matches the tag, the language quality factor assigned is 0. If
	no Accept-Language header is present in the request, the server		no Accept-Language header is present in the request, the server
	SHOULD assume that all languages are equally acceptable. If an		SHOULD assume that all languages are equally acceptable. If an
	Accept-Language header is present, then all languages which are		Accept-Language header is present, then all languages which are
	assigned a quality factor greater than 0 are acceptable.		assigned a quality factor greater than 0 are acceptable.
	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 with the complete linguistic preferences of
	the user in every request. For a discussion of this issue, see		the user in every request. For a discussion of this issue, see
	Section 6.1.		Section 7.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 23, line 24		skipping to change at page 23, line 33
	Content-Type = "Content-Type" ":" media-type		Content-Type = "Content-Type" ":" media-type
	Media types are defined in Section 2.3. An example of the field is		Media types are defined in Section 2.3. An example of the field is
	Content-Type: text/html; charset=ISO-8859-4		Content-Type: text/html; charset=ISO-8859-4
	Further discussion of methods for identifying the media type of an		Further discussion of methods for identifying the media type of an
	entity is provided in Section 3.2.1.		entity is provided in Section 3.2.1.
	6. Security Considerations		6. IANA Considerations
			TBD.
			7. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	6.1. Privacy Issues Connected to Accept Headers		7.1. Privacy Issues Connected to Accept Headers
	Accept request-headers can reveal information about the user to all		Accept request-headers can reveal information about the user to all
	servers which are accessed. The Accept-Language header in particular		servers which are accessed. The Accept-Language header in particular
	can reveal information the user would consider to be of a private		can reveal information the user would consider to be of a private
	nature, because the understanding of particular languages is often		nature, because the understanding of particular languages is often
	strongly correlated to the membership of a particular ethnic group.		strongly correlated to the membership of a particular ethnic group.
	User agents which offer the option to configure the contents of an		User agents which offer the option to configure the contents of an
	Accept-Language header to be sent in every request are strongly		Accept-Language header to be sent in every request are strongly
	encouraged to let the configuration process include a message which		encouraged to let the configuration process include a message which
	makes the user aware of the loss of privacy involved.		makes the user aware of the loss of privacy involved.
	skipping to change at page 24, line 21		skipping to change at page 24, line 34
	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 headers in relayed requests.
	General purpose user agents which provide a high degree of header		General purpose user agents which provide a high degree of header
	configurability SHOULD warn users about the loss of privacy which can		configurability SHOULD warn users about the loss of privacy which can
	be involved.		be involved.
	6.2. Content-Disposition Issues		7.2. Content-Disposition Issues
	RFC 1806 [RFC1806], from which the often implemented Content-		RFC 1806 [RFC1806], from which the often implemented Content-
	Disposition (see Appendix B.1) header in HTTP is derived, has a		Disposition (see Appendix B.1) header in HTTP is derived, has a
	number of very serious security considerations. Content-Disposition		number of very serious security considerations. Content-Disposition
	is not part of the HTTP standard, but since it is widely implemented,		is not part of the HTTP standard, but since it is widely implemented,
	we are documenting its use and risks for implementors. See RFC 2183		we are documenting its use and risks for implementors. See RFC 2183
	[RFC2183] (which updates RFC 1806) for details.		[RFC2183] (which updates RFC 1806) for details.
	7. Acknowledgments		8. Acknowledgments
	Based on an XML translation of RFC 2616 by Julian Reschke.		Based on an XML translation of RFC 2616 by Julian Reschke.
	8. References		9. References
	[RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590,
	November 1996.
	[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,		[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
	RFC 1700, October 1994.		RFC 1700, October 1994.
	[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.
	[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation		[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
	Information in Internet Messages: The Content-Disposition		Information in Internet Messages: The Content-Disposition
	Header", RFC 1806, June 1995.		Header", RFC 1806, June 1995.
	skipping to change at page 25, line 51		skipping to change at page 26, line 15
	[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating		[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
	Presentation Information in Internet Messages: The		Presentation Information in Internet Messages: The
	Content-Disposition Header Field", RFC 2183, August 1997.		Content-Disposition Header Field", RFC 2183, August 1997.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	Languages", BCP 18, RFC 2277, January 1998.		Languages", BCP 18, RFC 2277, January 1998.
	[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", RFC 2279, January 1998.		10646", RFC 2279, January 1998.
			[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
			Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet		[RFC822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.		text messages", STD 11, RFC 822, August 1982.
	Appendix A. Differences Between HTTP Entities and RFC 2045 Entities		Appendix A. Differences Between HTTP Entities and RFC 2045 Entities
	HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC		HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
	822 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME		822 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME
	[RFC2045]) to allow entities to be transmitted in an open variety of		[RFC2045]) to allow entities to be transmitted in an open variety of
	representations and with extensible mechanisms. However, RFC 2045		representations and with extensible mechanisms. However, RFC 2045
	discusses mail, and HTTP has a few features that are different from		discusses mail, and HTTP has a few features that are different from
	skipping to change at page 27, line 33		skipping to change at page 27, line 51
	media type, proxies and gateways from HTTP to MIME-compliant		media type, proxies and gateways from HTTP to MIME-compliant
	protocols MUST either change the value of the Content-Type header		protocols MUST either change the value of the Content-Type header
	field or decode the entity-body before forwarding the message. (Some		field or decode the entity-body before forwarding the message. (Some
	experimental applications of Content-Type for Internet mail have used		experimental applications of Content-Type for Internet mail have used
	a media-type parameter of ";conversions=<content-coding>" to perform		a media-type parameter of ";conversions=<content-coding>" to perform
	a function equivalent to Content-Encoding. However, this parameter		a function equivalent to Content-Encoding. However, this parameter
	is not part of RFC 2045).		is not part of RFC 2045).
	A.4. No Content-Transfer-Encoding		A.4. No Content-Transfer-Encoding
	HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC		HTTP does not use the Content-Transfer-Encoding field of RFC 2045.
	2045. Proxies and gateways from MIME-compliant protocols to HTTP		Proxies and gateways from MIME-compliant protocols to HTTP MUST
	MUST remove any non-identity CTE ("quoted-printable" or "base64")		remove any Content-Transfer-Encoding prior to delivering the response
	encoding prior to delivering the response message to an HTTP client.		message to an HTTP client.
	Proxies and gateways from HTTP to MIME-compliant protocols are		Proxies and gateways from HTTP to MIME-compliant protocols are
	responsible for ensuring that the message is in the correct format		responsible for ensuring that the message is in the correct format
	and encoding for safe transport on that protocol, where "safe		and encoding for safe transport on that protocol, where "safe
	transport" is defined by the limitations of the protocol being used.		transport" is defined by the limitations of the protocol being used.
	Such a proxy or gateway SHOULD label the data with an appropriate		Such a proxy or gateway SHOULD label the data with an appropriate
	Content-Transfer-Encoding if doing so will improve the likelihood of		Content-Transfer-Encoding if doing so will improve the likelihood of
	safe transport over the destination protocol.		safe transport over the destination protocol.
	A.5. Introduction of Transfer-Encoding		A.5. Introduction of Transfer-Encoding
	skipping to change at page 29, line 12		skipping to change at page 29, line 29
	The receiving user agent SHOULD NOT respect any directory path		The receiving user agent SHOULD NOT respect any directory path
	information present in the filename-parm parameter, which is the only		information present in the filename-parm parameter, which is the only
	parameter believed to apply to HTTP implementations at this time.		parameter believed to apply to HTTP implementations at this time.
	The filename SHOULD be treated as a terminal component only.		The filename SHOULD be treated as a terminal component only.
	If this header is used in a response with the application/		If this header is used in a response with the application/
	octet-stream content-type, the implied suggestion is that the user		octet-stream content-type, the implied suggestion is that the user
	agent should not display the response, but directly enter a `save		agent should not display the response, but directly enter a `save
	response as...' dialog.		response as...' dialog.
	See Section 6.2 for Content-Disposition security issues.		See Section 7.2 for Content-Disposition security issues.
	Appendix C. Changes from RFC 2068		Appendix C. Changes from RFC 2068
	Charset wildcarding is introduced to avoid explosion of character set		Charset wildcarding is introduced to avoid explosion of character set
	names in accept headers. (Section 5.2)		names in accept headers. (Section 5.2)
	Content-Base was deleted from the specification: it was not		Content-Base was deleted from the specification: it was not
	implemented widely, and there is no simple, safe way to introduce it		implemented widely, and there is no simple, safe way to introduce it
	without a robust extension mechanism. In addition, it is used in a		without a robust extension mechanism. In addition, it is used in a
	similar, but not identical fashion in MHTML [RFC2110].		similar, but not identical fashion in MHTML [RFC2110].
	skipping to change at page 29, line 39		skipping to change at page 30, line 10
	The Alternates, Content-Version, Derived-From, Link, URI, Public and		The Alternates, Content-Version, Derived-From, Link, URI, Public and
	Content-Base header fields were defined in previous versions of this		Content-Base header fields were defined in previous versions of this
	specification, but not commonly implemented. See RFC 2068 [RFC2068].		specification, but not commonly implemented. See RFC 2068 [RFC2068].
	Index		Index
	A		A
	Accept header 14		Accept header 14
	Accept-Charset header 16		Accept-Charset header 16
	Accept-Encoding header 16		Accept-Encoding header 17
	Accept-Language header 18		Accept-Language header 18
	Alternates header 29		Alternates header 29
	C		C
	compress 5		compress 6
	Content-Base header 29		Content-Base header 29
	Content-Disposition header 28		Content-Disposition header 28
	Content-Encoding header 19		Content-Encoding header 19
	Content-Language header 20		Content-Language header 20
	Content-Location header 21		Content-Location header 21
	Content-MD5 header 21		Content-MD5 header 22
	Content-Type header 23		Content-Type header 23
	Content-Version header 29		Content-Version header 29
	D		D
	deflate 6		deflate 6
	Derived-From header 29		Derived-From header 29
	G		G
	Grammar		Grammar
	Accept 14		Accept 14
	Accept-Charset 16		Accept-Charset 16
	Accept-Encoding 17		Accept-Encoding 17
	accept-extension 14		accept-extension 14
	Accept-Language 18		Accept-Language 18
	accept-params 14		accept-params 14
	attribute 6		attribute 7
	charset 4		charset 4
	codings 17		codings 17
	content-coding 5		content-coding 5
	content-disposition 28		content-disposition 29
	Content-Encoding 19		Content-Encoding 19
	Content-Language 20		Content-Language 20
	Content-Location 21		Content-Location 21
	Content-MD5 22		Content-MD5 22
	Content-Type 23		Content-Type 23
	disp-extension-parm 28		disp-extension-parm 29
	disp-extension-token 28		disp-extension-token 29
	disposition-parm 28		disposition-parm 29
	disposition-type 28		disposition-type 29
	entity-body 10		entity-body 10
	entity-header 10		entity-header 10
	extension-header 10		extension-header 10
	filename-parm 28		filename-parm 29
	language-range 18		language-range 18
	language-tag 9		language-tag 9
	md5-digest 22		md5-digest 22
	media-range 14		media-range 14
	media-type 6		media-type 6
	MIME-Version 26		MIME-Version 26
	parameter 6		parameter 7
	primary-tag 9		primary-tag 9
	qvalue 8		qvalue 9
	subtag 9		subtag 9
	subtype 6		subtype 6
	type 6		type 6
	value 6		value 7
	gzip 5		gzip 5
	H		H
	Headers		Headers
	Accept 14		Accept 14
	Accept-Charset 16		Accept-Charset 16
	Accept-Encoding 16		Accept-Encoding 17
	Accept-Language 18		Accept-Language 18
	Alternate 29		Alternate 29
	Content-Base 29		Content-Base 29
	Content-Disposition 28		Content-Disposition 28
	Content-Encoding 19		Content-Encoding 19
	Content-Language 20		Content-Language 20
	Content-Location 21		Content-Location 21
	Content-MD5 21		Content-MD5 22
	Content-Type 23		Content-Type 23
	Content-Version 29		Content-Version 29
	Derived-From 29		Derived-From 29
	Link 29		Link 29
	Public 29		Public 29
	URI 29		URI 29
	I		I
	identity 6		identity 6
	skipping to change at page 31, line 38		skipping to change at page 32, line 7
	Link header 29		Link header 29
	P		P
	Public header 29		Public header 29
	U		U
	URI header 29		URI header 29
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding		Roy T. Fielding (editor)
	Department of Information and Computer Science		Day Software
	University of California, Irvine		23 Corporate Plaza DR, Suite 280
	Irvine, CA 92697-3425		Newport Beach, CA 92660
			USA
			Phone: +1-949-706-5300
			Fax: +1-949-706-5305
			Email: fielding@gbiv.com
			URI: http://roy.gbiv.com/
	Fax: +1(949)824-1715
	Email: fielding@ics.uci.edu
	James Gettys		James Gettys
	World Wide Web Consortium		Hewlett-Packard Company
	MIT Laboratory for Computer Science, NE43-356		HP Labs, Cambridge Research Laboratory
	545 Technology Square		One Cambridge Center
	Cambridge, MA 02139		Cambridge, MA 02138
			USA
	Fax: +1(617)258-8682		Email: Jim.Gettys@hp.com
	Email: jg@w3.org
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Compaq Computer Corporation		Hewlett-Packard Company
	Western Research Laboratory		HP Labs, Large Scale Systems Group
	250 University Avenue		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94305		Palo Alto, CA 94304
			USA
	Email: mogul@wrl.dec.com		Email: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	World Wide Web Consortium		Microsoft Corporation
	MIT Laboratory for Computer Science, NE43-356		1 Microsoft Way
	545 Technology Square		Redmond, WA 98052
	Cambridge, MA 02139		USA
	Fax: +1(617)258-8682
	Email: frystyk@w3.org
			Email: henrikn@microsoft.com
	Larry Masinter		Larry Masinter
	Xerox Corporation		Adobe Systems, Incorporated
	MIT Laboratory for Computer Science, NE43-356		345 Park Ave
	3333 Coyote Hill Road		San Jose, CA 95110
	Palo Alto, CA 94034		USA
	Email: masinter@parc.xerox.com		Email: LMM@acm.org
			URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		Email: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Laboratory for Computer Science, NE43-356		MIT Laboratory for Computer Science
	545 Technology Square		545 Technology Square
	Cambridge, MA 02139		Cambridge, MA 02139
			USA
	Fax: +1(617)258-8682		Fax: +1 (617) 258 8682
	Email: timbl@w3.org		Email: timbl@w3.org
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
End of changes. 53 change blocks.
	86 lines changed or deleted		103 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/