draft-ietf-appsawg-mime-default-charset-04.txt		draft-ietf-appsawg-mime-default-charset-latest.txt
	Applications Area Working Group A. Melnikov		Applications Area Working Group A. Melnikov
	Internet-Draft Isode Limited		Internet-Draft Isode Limited
	Updates: 2046 (if approved) J. Reschke		Updates: 2046 (if approved) J. Reschke
	Intended status: Standards Track greenbytes		Intended status: Standards Track greenbytes
	Expires: November 10, 2012 May 9, 2012		Expires: November 17, 2013 May 16, 2013
	Update to MIME regarding Charset Parameter Handling in		Update to MIME regarding "charset" Parameter Handling
	Textual Media Types		in Textual Media Types
	draft-ietf-appsawg-mime-default-charset-04		draft-ietf-appsawg-mime-default-charset-latest
	Abstract		Abstract
	This document changes RFC 2046 rules regarding default charset		This document changes RFC 2046 rules regarding default "charset"
	parameter values for text/* media types to better align with common		parameter values for "text/*" media types to better align with common
	usage by existing clients and servers.		usage by existing clients and servers.
	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 Apps Area Working		Discussion of this draft should take place on the Apps Area Working
	Group mailing list (apps-discuss@ietf.org), which is archived at		Group mailing list (apps-discuss@ietf.org), which is archived at
	<http://www.ietf.org/mail-archive/web/apps-discuss>.		<http://www.ietf.org/mail-archive/web/apps-discuss>.
	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 November 10, 2012.		This Internet-Draft will expire on November 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Overview . . . . . . . . . . . . . . . 3		1. Introduction and Overview . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . 3
	3. New rules for default charset parameter values for		3. New Rules for Default "charset" Parameter Values
	text/* media types . . . . . . . . . . . . . . . . . . 3		for "text/*" Media Types . . . . . . . . . . . . . . . 3
	4. Default charset parameter value for text/plain		4. Default "charset" Parameter Value for "text/plain"
	media type . . . . . . . . . . . . . . . . . . . . . . 4		Media Type . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . 6
	1. Introduction and Overview		1. Introduction and Overview
	RFC 2046 specified that the default charset parameter (i.e. the value		RFC 2046 specified that the default "charset" parameter (i.e., the
	used when the parameter is not specified) is "US-ASCII" (Section		value used when the parameter is not specified) is "US-ASCII"
	4.1.2 of [RFC2046]). RFC 2616 changed the default for use by HTTP		(Section 4.1.2 of [RFC2046]). RFC 2616 changed the default for use
	(Hypertext Transfer Protocol) to be "ISO-8859-1" (Section 3.7.1 of		by HTTP (Hypertext Transfer Protocol) to be "ISO-8859-1" (Section
	[RFC2616]). This encoding is not very common for new text/* media		3.7.1 of [RFC2616]). This encoding is not very common for new
	types and a special rule in the HTTP specification adds confusion		"text/*" media types and a special rule in the HTTP specification
	about which specification ([RFC2046] or [RFC2616]) is authoritative		adds confusion about which specification ([RFC2046] or [RFC2616]) is
	in regards to the default charset for text/* media types.		authoritative in regards to the default charset for "text/*" media
			types.
	Many complex text subtypes such as text/html [RFC2854] and text/xml		Many complex text subtypes such as "text/html" [RFC2854] and "text/
	[RFC3023] have internal (to their format) means of describing the		xml" [RFC3023] have internal (to their format) means of describing
	charset. Many existing User Agents ignore the default of "US-ASCII"		the charset. Many existing User Agents ignore the default of "US-
	rule for at least text/html and text/xml.		ASCII" rule for at least "text/html" and "text/xml".
	This document changes RFC 2046 rules regarding default charset		This document changes RFC 2046 rules regarding default "charset"
	parameter values for text/* media types to better align with common		parameter values for "text/*" media types to better align with common
	usage by existing clients and servers. It does not change the		usage by existing clients and servers. It does not change the
	defaults for any currently registered media type.		defaults for any currently registered media type.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. New rules for default charset parameter values for text/* media		3. New Rules for Default "charset" Parameter Values for "text/*" Media
	types		Types
	Section 4.1.2 of [RFC2046] says:		Section 4.1.2 of [RFC2046] says:
	The default character set, which must be assumed in the absence of		The default character set, which must be assumed in the absence of
	a charset parameter, is US-ASCII.		a charset parameter, is US-ASCII.
	As explained in the Introduction section this rule is considered to		As explained in the Introduction section, this rule is considered
	be outdated, so this document replaces it with the following set of		outdated, so this document replaces it with the following set of
	rules:		rules:
	Each subtype of the "text" media type which uses the "charset"		Each subtype of the "text" media type that uses the "charset"
	parameter can define its own default value for the "charset"		parameter can define its own default value for the "charset"
	parameter, including the absence of any default.		parameter, including the absence of any default.
	In order to improve interoperability with deployed agents, "text/*"		In order to improve interoperability with deployed agents, "text/*"
	media type registrations SHOULD either		media type registrations SHOULD either
	a. specify that the "charset" parameter is not used for the defined		a. specify that the "charset" parameter is not used for the defined
	subtype, because the charset information is transported inside		subtype, because the charset information is transported inside
	the payload (such as in "text/xml"), or		the payload (such as in "text/xml"), or
	b. require explicit unconditional inclusion of the "charset"		b. require explicit unconditional inclusion of the "charset"
	parameter eliminating the need for a default value.		parameter, eliminating the need for a default value.
	In accordance with option (a), above, registrations for "text/*"		In accordance with option (a) above, registrations for "text/*" media
	media types that can transport charset information inside the		types that can transport charset information inside the corresponding
	corresponding payloads (such as "text/html" and "text/xml") SHOULD		payloads (such as "text/html" and "text/xml") SHOULD NOT specify the
	NOT specify the use of a "charset" parameter, nor any default value,		use of a "charset" parameter, nor any default value, in order to
	in order to avoid conflicting interpretations should the charset		avoid conflicting interpretations should the "charset" parameter
	parameter value and the value specified in the payload disagree.		value and the value specified in the payload disagree.
	New subtypes of the "text" media type, thus, SHOULD NOT define a		Thus, new subtypes of the "text" media type SHOULD NOT define a
	default "charset" value. If there is a strong reason to do so		default "charset" value. If there is a strong reason to do so
	despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as		despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as
	the default.		the default.
	Regardless of what approach is chosen, all new text/* registrations		Regardless of what approach is chosen, all new "text/*" registrations
	MUST clearly specify how the charset is determined; relying on the		MUST clearly specify how the charset is determined; relying on the
	default defined in Section 4.1.2 of [RFC2046] is no longer permitted.		default defined in Section 4.1.2 of [RFC2046] is no longer permitted.
	However, existing text/* registrations that fail to specify how the		However, existing "text/*" registrations that fail to specify how the
	charset is determined still default to US-ASCII.		charset is determined still default to US-ASCII.
	Specifications covering the "charset" parameter, and what default		Specifications covering the "charset" parameter, and what default
	value, if any, is used, are subtype-specific, NOT protocol-specific.		value, if any, is used, are subtype-specific, NOT protocol-specific.
	Protocols that use MIME, therefore, MUST NOT override default charset		Protocols that use MIME, therefore, MUST NOT override default charset
	values for "text/*" media types to be different for their specific		values for "text/*" media types to be different for their specific
	protocol. The protocol definitions MUST leave that to the subtype		protocol. The protocol definitions MUST leave that to the subtype
	definitions.		definitions.
	4. Default charset parameter value for text/plain media type		4. Default "charset" Parameter Value for "text/plain" Media Type
	The default charset parameter value for text/plain is unchanged from		The default "charset" parameter value for "text/plain" is unchanged
	[RFC2046] and remains as "US-ASCII".		from [RFC2046] and remains as "US-ASCII".
	5. Security Considerations		5. Security Considerations
	Guessing of the charset parameter can lead to security issues such as		Guessing of the "charset" parameter can lead to security issues such
	content buffer overflows, denial of services or bypass of filtering		as content buffer overflows, denial of services, or bypass of
	mechanisms. However, this document does not promote guessing, but		filtering mechanisms. However, this document does not promote
	encourages use of charset information that is specified by the		guessing, but encourages use of charset information that is specified
	sender.		by the sender.
	Conflicting information in-band vs out-of-band can also lead to		Conflicting information in-band vs. out-of-band can also lead to
	similar security problems, and this document recommends the use of		similar security problems, and this document recommends the use of
	charset information which is more likely to be correct (for example,		charset information that is more likely to be correct (for example,
	in-band over out-of-band).		in-band over out-of-band).
	6. IANA Considerations		6. IANA Considerations
	This document asks IANA to update the "text" subregistry of the Media		IANA has updated the "text" subregistry of the Media Types registry
	Types registry (<http://www.iana.org/assignments/media-types/text/>),		(<http://www.iana.org/assignments/media-types/text/>) to add the
	to add the following preamble: "See [this RFC] for information about		following preamble: "See [RFC6657] for information about 'charset'
	'charset' parameter handling for text media types."		parameter handling for text media types."
	IANA is also asked to add this RFC to the list of references at the		Also, IANA has added this RFC to the list of references at the
	beginning of the Application for Media Type		beginning of the Application for Media Type
	(<http://www.iana.org/cgi-bin/mediatypes.pl>).		(<http://www.iana.org/form/media-types>).
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 6, line 15		skipping to change at page 6, line 9
	Authors' Addresses		Authors' Addresses
	Alexey Melnikov		Alexey Melnikov
	Isode Limited		Isode Limited
	5 Castle Business Village		5 Castle Business Village
	36 Station Road		36 Station Road
	Hampton, Middlesex TW12 2BX		Hampton, Middlesex TW12 2BX
	UK		UK
	Email: Alexey.Melnikov@isode.com		EMail: Alexey.Melnikov@isode.com
	Julian F. Reschke		Julian F. Reschke
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	Email: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 31 change blocks.
	61 lines changed or deleted		63 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/