Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6657 Isode Limited
Updates: 2046 J. Reschke
Category: Standards Track greenbytes
ISSN: 2070-1721 July 2012
Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 6657 Isode Limited
Updates: 2046 J. Reschke
Category: Standards Track greenbytes
ISSN: 2070-1721 July 2012
Update to MIME regarding "charset" Parameter Handling in Textual Media Types
关于文本媒体类型中“字符集”参数处理的MIME更新
Abstract
摘要
This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers.
本文档更改了RFC 2046关于“text/*”媒体类型的默认“charset”参数值的规则，以便更好地与现有客户端和服务器的常见用法保持一致。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6657.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Overview .......................................2
2. Conventions Used in This Document ...............................2
3. New Rules for Default "charset" Parameter Values for
"text/*" Media Types ............................................3
4. Default "charset" Parameter Value for "text/plain" Media Type ...4
5. Security Considerations .........................................4
6. IANA Considerations .............................................4
7. References ......................................................4
7.1. Normative References .......................................4
7.2. Informative References .....................................5
Appendix A. Acknowledgements ......................................6
1. Introduction and Overview .......................................2
2. Conventions Used in This Document ...............................2
3. New Rules for Default "charset" Parameter Values for
"text/*" Media Types ............................................3
4. Default "charset" Parameter Value for "text/plain" Media Type ...4
5. Security Considerations .........................................4
6. IANA Considerations .............................................4
7. References ......................................................4
7.1. Normative References .......................................4
7.2. Informative References .....................................5
Appendix A. Acknowledgements ......................................6
RFC 2046 specified that the default "charset" parameter (i.e., the value used when the parameter is not specified) is "US-ASCII" (Section 4.1.2 of [RFC2046]). RFC 2616 changed the default for use by HTTP (Hypertext Transfer Protocol) to be "ISO-8859-1" (Section 3.7.1 of [RFC2616]). This encoding is not very common for new "text/*" media types and a special rule in the HTTP specification adds confusion about which specification ([RFC2046] or [RFC2616]) is authoritative in regards to the default charset for "text/*" media types.
RFC 2046规定默认的“字符集”参数（即未指定参数时使用的值）为“US-ASCII”（RFC2046第4.1.2节）。RFC 2616将HTTP（超文本传输协议）使用的默认值更改为“ISO-8859-1”（[RFC2616]第3.7.1节）。这种编码对于新的“text/*”媒体类型不是很常见，HTTP规范中的一条特殊规则增加了关于哪个规范（[RFC2046]或[RFC2616]）对于“text/*”媒体类型的默认字符集是权威的混淆。
Many complex text subtypes such as "text/html" [RFC2854] and "text/ xml" [RFC3023] have internal (to their format) means of describing the charset. Many existing User Agents ignore the default of "US-ASCII" rule for at least "text/html" and "text/xml".
许多复杂的文本子类型，如“text/html”[RFC2854]和“text/xml”[RFC3023]具有描述字符集的内部（与其格式相同）方法。许多现有的用户代理忽略了至少“text/html”和“text/xml”的默认“US-ASCII”规则。
This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. It does not change the defaults for any currently registered media type.
本文档更改了RFC 2046关于“text/*”媒体类型的默认“charset”参数值的规则，以便更好地与现有客户端和服务器的常见用法保持一致。它不会更改任何当前注册的媒体类型的默认值。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
3. New Rules for Default "charset" Parameter Values for "text/*" Media Types
3. “text/*”媒体类型的默认“charset”参数值的新规则
Section 4.1.2 of [RFC2046] says:
[RFC2046]第4.1.2节规定：
The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
默认字符集（在没有字符集参数的情况下必须假定）为US-ASCII。
As explained in the Introduction section, this rule is considered outdated, so this document replaces it with the following set of rules:
如引言部分所述，此规则被视为已过时，因此本文档将其替换为以下一组规则：
Each subtype of the "text" media type that uses the "charset" parameter can define its own default value for the "charset" parameter, including the absence of any default.
使用“字符集”参数的“文本”媒体类型的每个子类型都可以为“字符集”参数定义自己的默认值，包括没有任何默认值。
In order to improve interoperability with deployed agents, "text/*" media type registrations SHOULD either
为了提高与已部署代理的互操作性，“text/*”媒体类型注册应
a. specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (such as in "text/xml"), or
a. 指定“charset”参数不用于定义的子类型，因为字符集信息在有效负载内传输（例如在“text/xml”中），或者
b. require explicit unconditional inclusion of the "charset" parameter, eliminating the need for a default value.
b. 需要显式无条件包含“charset”参数，无需使用默认值。
In accordance with option (a) above, registrations for "text/*" media types that can transport charset information inside the corresponding payloads (such as "text/html" and "text/xml") SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the "charset" parameter value and the value specified in the payload disagree.
根据上述选项（a），可在相应有效载荷内传输字符集信息的“text/*”媒体类型（如“text/html”和“text/xml”）的注册不应指定“charset”参数的使用，也不应指定任何默认值，以避免对“charset”的解释发生冲突参数值与有效负载中指定的值不一致。
Thus, new subtypes of the "text" media type SHOULD NOT define a default "charset" value. If there is a strong reason to do so despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as the default.
因此，“文本”媒体类型的新子类型不应定义默认的“字符集”值。尽管有此建议，如果有充分的理由这样做，他们应该使用“UTF-8”[RFC3629]字符集作为默认值。
Regardless of what approach is chosen, all new "text/*" registrations MUST clearly specify how the charset is determined; relying on the default defined in Section 4.1.2 of [RFC2046] is no longer permitted. However, existing "text/*" registrations that fail to specify how the charset is determined still default to US-ASCII.
无论选择何种方法，所有新的“text/*”注册都必须明确指定如何确定字符集；不再允许依赖[RFC2046]第4.1.2节中定义的违约。但是，无法指定如何确定字符集的现有“text/*”注册仍然默认为US-ASCII。
Specifications covering the "charset" parameter, and what default value, if any, is used, are subtype-specific, NOT protocol-specific. Protocols that use MIME, therefore, MUST NOT override default charset
涵盖“charset”参数的规范以及使用的默认值（如果有）是特定于子类型的，而不是特定于协议的。因此，使用MIME的协议不能覆盖默认字符集
values for "text/*" media types to be different for their specific protocol. The protocol definitions MUST leave that to the subtype definitions.
“text/*”媒体类型的值因其特定协议而异。协议定义必须将其留给子类型定义。
The default "charset" parameter value for "text/plain" is unchanged from [RFC2046] and remains as "US-ASCII".
“text/plain”的默认“charset”参数值与[RFC2046]相同，并保持为“US-ASCII”。
Guessing of the "charset" parameter can lead to security issues such as content buffer overflows, denial of services, or bypass of filtering mechanisms. However, this document does not promote guessing, but encourages use of charset information that is specified by the sender.
猜测“charset”参数可能导致安全问题，如内容缓冲区溢出、拒绝服务或绕过过滤机制。但是，本文档不支持猜测，而是鼓励使用发送方指定的字符集信息。
Conflicting information in-band vs. out-of-band can also lead to similar security problems, and this document recommends the use of charset information that is more likely to be correct (for example, in-band over out-of-band).
带内信息与带外信息的冲突也会导致类似的安全问题，本文档建议使用更有可能正确的字符集信息（例如，带内信息与带外信息）。
IANA has updated the "text" subregistry of the Media Types registry
(<http://www.iana.org/assignments/media-types/text/>) to add the
following preamble: "See [RFC6657] for information about 'charset'
parameter handling for text media types."
IANA has updated the "text" subregistry of the Media Types registry
(<http://www.iana.org/assignments/media-types/text/>) to add the
following preamble: "See [RFC6657] for information about 'charset'
parameter handling for text media types."
Also, IANA has added this RFC to the list of references at the beginning of the Application for Media Type (<http://www.iana.org/form/media-types>).
此外，IANA已将此RFC添加到媒体类型应用程序开头的引用列表中(<http://www.iana.org/form/media-types>).
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC2854]Connolly，D.和L.Masinter，“文本/html”媒体类型”，RFC 28542000年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
Many thanks to Ned Freed and John Klensin for comments and ideas that motivated creation of this document, and to Carsten Bormann, Murray S. Kucherawy, Barry Leiba, and Henri Sivonen for feedback and text suggestions.
非常感谢Ned Freed和John Klensin的评论和想法，感谢Carsten Bormann、Murray S.Kucherawy、Barry Leiba和Henri Sivonen的反馈和文本建议。
Authors' Addresses
作者地址
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode Limited TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/