draft-ietf-appsawg-mime-default-charset-04.txt   rfc6657.txt 
Applications Area Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Limited Request for Comments: 6657 Isode Limited
Updates: 2046 (if approved) J. Reschke Updates: 2046 J. Reschke
Intended status: Standards Track greenbytes Category: Standards Track greenbytes
Expires: November 10, 2012 May 9, 2012 ISSN: 2070-1721 July 2012
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
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) Status of This Memo
Discussion of this draft should take place on the Apps Area Working
Group mailing list (apps-discuss@ietf.org), which is archived at
<http://www.ietf.org/mail-archive/web/apps-discuss>.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 10, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6657.
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
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 .......................................2
2. Conventions Used in This Document . . . . . . . . . . . 3 2. Conventions Used in This Document ...............................2
3. New rules for default charset parameter values for 3. New Rules for Default "charset" Parameter Values for
text/* media types . . . . . . . . . . . . . . . . . . 3 "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 .............................................4
6. IANA Considerations . . . . . . . . . . . . . . . . . . 5 7. References ......................................................4
7. References . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References .......................................4
7.1. Normative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References .....................................5
7.2. Informative References . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements ......................................6
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 21
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. 
89 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/