Network Working Group N. Freed
Request for Comments: 2231 Innosoft
Updates: 2045, 2047, 2183 K. Moore
Obsoletes: 2184 University of Tennessee
Category: Standards Track November 1997
Network Working Group N. Freed
Request for Comments: 2231 Innosoft
Updates: 2045, 2047, 2183 K. Moore
Obsoletes: 2184 University of Tennessee
Category: Standards Track November 1997
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
MIME参数值和编码字扩展：字符集、语言和连续体
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide
此备忘录定义了RFC 2045介质类型和RFC 2183处置参数值机制的扩展，以提供
(1) a means to specify parameter values in character sets other than US-ASCII,
(1) 一种在字符集中指定参数值的方法，而非US-ASCII，
(2) to specify the language to be used should the value be displayed, and
(2) 指定显示值时要使用的语言，以及
(3) a continuation mechanism for long parameter values to avoid problems with header line wrapping.
(3) 长参数值的延续机制，以避免标题行换行的问题。
This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set.
本备忘录还定义了对RFC 2047中定义的编码字的扩展，以允许指定用于显示的语言以及字符集。
The Multipurpose Internet Mail Extensions, or MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049], define a message format that allows for:
多用途Internet邮件扩展或MIME[RFC-2045、RFC-2046、RFC-2047、RFC-2048、RFC-2049]定义了一种消息格式，允许：
(1) textual message bodies in character sets other than US-ASCII,
(1) 字符集（US-ASCII除外）中的文本消息体，
(2) non-textual message bodies,
(2) 非文本消息体，
(3) multi-part message bodies, and
(3) 多部分消息正文，以及
(4) textual header information in character sets other than US-ASCII.
(4) 字符集（US-ASCII除外）中的文本标题信息。
MIME is now widely deployed and is used by a variety of Internet protocols, including, of course, Internet email. However, MIME's success has resulted in the need for additional mechanisms that were not provided in the original protocol specification.
MIME现在被广泛部署，并被各种互联网协议使用，当然包括互联网电子邮件。然而，MIME的成功导致了对原始协议规范中未提供的其他机制的需求。
In particular, existing MIME mechanisms provide for named media type (content-type field) parameters as well as named disposition (content-disposition field). A MIME media type may specify any number of parameters associated with all of its subtypes, and any specific subtype may specify additional parameters for its own use. A MIME disposition value may specify any number of associated parameters, the most important of which is probably the attachment disposition's filename parameter.
特别是，现有MIME机制提供了命名媒体类型（内容类型字段）参数以及命名处置（内容处置字段）。MIME媒体类型可以指定与其所有子类型关联的任意数量的参数，任何特定子类型都可以指定其他参数以供自己使用。MIME处置值可以指定任意数量的关联参数，其中最重要的可能是附件处置的filename参数。
These parameter names and values end up appearing in the content-type and content-disposition header fields in Internet email. This inherently imposes three crucial limitations:
这些参数名称和值最终出现在Internet电子邮件的“内容类型”和“内容处置”标题字段中。这本身就造成了三个关键限制：
(1) Lines in Internet email header fields are folded according to RFC 822 folding rules. This makes long parameter values problematic.
(1) Internet电子邮件标题字段中的行根据RFC 822折叠规则进行折叠。这使得长参数值成为问题。
(2) MIME headers, like the RFC 822 headers they often appear in, are limited to 7bit US-ASCII, and the encoded-word mechanisms of RFC 2047 are not available to parameter values. This makes it impossible to have parameter values in character sets other than US-ASCII without specifying some sort of private per-parameter encoding.
(2) MIME头，就像它们经常出现的RFC 822头一样，被限制为7bit US-ASCII，并且RFC 2047的编码字机制对参数值不可用。这使得在不指定某种私有的每参数编码的情况下，不可能在字符集（US-ASCII除外）中包含参数值。
(3) It has recently become clear that character set information is not sufficient to properly display some sorts of information -- language information is also needed [RFC-2130]. For example, support for handicapped users may require reading text string
(3) 最近很明显，字符集信息不足以正确显示某些类型的信息——还需要语言信息[RFC-2130]。例如，支持残疾用户可能需要阅读文本字符串
aloud. The language the text is written in is needed for this to be done correctly. Some parameter values may need to be displayed, hence there is a need to allow for the inclusion of language information.
出声地要正确完成此操作，需要使用文本所用的语言。可能需要显示一些参数值，因此需要允许包含语言信息。
The last problem on this list is also an issue for the encoded words defined by RFC 2047, as encoded words are intended primarily for display purposes.
该列表上的最后一个问题也是RFC 2047定义的编码字的问题，因为编码字主要用于显示目的。
This document defines extensions that address all of these limitations. All of these extensions are implemented in a fashion that is completely compatible at a syntactic level with existing MIME implementations. In addition, the extensions are designed to have as little impact as possible on existing uses of MIME.
本文档定义了解决所有这些限制的扩展。所有这些扩展都是以一种在语法层面上与现有MIME实现完全兼容的方式实现的。此外，这些扩展的设计目的是尽可能少地影响MIME的现有使用。
IMPORTANT NOTE: These mechanisms end up being somewhat gibbous when they actually are used. As such, these mechanisms should not be used lightly; they should be reserved for situations where a real need for them exists.
重要提示：这些机制在实际使用时会有点凸出。因此，这些机制不应轻易使用；它们应该保留在真正需要它们的情况下。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC- 2119].
本文档偶尔使用大写字母表示的术语。当术语“必须”、“应该”、“不得”、“不应该”和“可能”出现大写时，它们被用来表示本规范的特殊要求。[RFC-2119]中对这些术语的含义进行了讨论。
Long MIME media type or disposition parameter values do not interact well with header line wrapping conventions. In particular, proper header line wrapping depends on there being places where linear whitespace (LWSP) is allowed, which may or may not be present in a parameter value, and even if present may not be recognizable as such since specific knowledge of parameter value syntax may not be available to the agent doing the line wrapping. The result is that long parameter values may end up getting truncated or otherwise damaged by incorrect line wrapping implementations.
长MIME媒体类型或处置参数值与标题行包装约定的交互不好。特别是，正确的标题行换行取决于是否存在允许线性空白（LWSP）的位置，线性空白可能存在于参数值中，也可能不存在于参数值中，即使存在也可能无法识别，因为执行换行的代理可能无法获得参数值语法的特定知识。其结果是，长参数值可能最终被截断或被不正确的换行实现损坏。
A mechanism is therefore needed to break up parameter values into smaller units that are amenable to line wrapping. Any such mechanism MUST be compatible with existing MIME processors. This means that
因此，需要一种机制来将参数值分解为更小的单元，以便于换行。任何此类机制都必须与现有MIME处理器兼容。这意味着
(1) the mechanism MUST NOT change the syntax of MIME media type and disposition lines, and
(1) 该机制不得更改MIME媒体类型和处置行的语法，以及
(2) the mechanism MUST NOT depend on parameter ordering since MIME states that parameters are not order sensitive. Note that while MIME does prohibit modification of MIME headers during transport, it is still possible that parameters will be reordered when user agent level processing is done.
(2) 该机制不能依赖于参数顺序，因为MIME声明参数不区分顺序。请注意，虽然MIME确实禁止在传输过程中修改MIME头，但在完成用户代理级别的处理时，参数仍有可能被重新排序。
The obvious solution, then, is to use multiple parameters to contain a single parameter value and to use some kind of distinguished name to indicate when this is being done. And this obvious solution is exactly what is specified here: The asterisk character ("*") followed by a decimal count is employed to indicate that multiple parameters are being used to encapsulate a single parameter value. The count starts at 0 and increments by 1 for each subsequent section of the parameter value. Decimal values are used and neither leading zeroes nor gaps in the sequence are allowed.
因此，显而易见的解决方案是使用多个参数来包含单个参数值，并使用某种可分辨名称来指示何时执行此操作。这个显而易见的解决方案正是这里指定的：使用星号字符（“*”）后跟一个十进制计数来表示使用多个参数封装单个参数值。计数从0开始，并在参数值的每个后续部分递增1。使用十进制值，序列中不允许前导零或间隙。
The original parameter value is recovered by concatenating the various sections of the parameter, in order. For example, the content-type field
通过按顺序连接参数的各个部分来恢复原始参数值。例如，“内容类型”字段
Content-Type: message/external-body; access-type=URL;
URL*0="ftp://";
URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
Content-Type: message/external-body; access-type=URL;
URL*0="ftp://";
URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
is semantically identical to
在语义上与相同
Content-Type: message/external-body; access-type=URL;
URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
Content-Type: message/external-body; access-type=URL;
URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
Note that quotes around parameter values are part of the value syntax; they are NOT part of the value itself. Furthermore, it is explicitly permitted to have a mixture of quoted and unquoted continuation fields.
请注意，参数值周围的引号是值语法的一部分；它们不是价值本身的一部分。此外，明确允许混合使用带引号和不带引号的连续字段。
Some parameter values may need to be qualified with character set or language information. It is clear that a distinguished parameter name is needed to identify when this information is present along with a specific syntax for the information in the value itself. In addition, a lightweight encoding mechanism is needed to accommodate 8 bit information in parameter values.
某些参数值可能需要使用字符集或语言信息进行限定。很明显，需要一个可分辨的参数名来标识何时存在此信息以及值本身中信息的特定语法。此外，需要一种轻量级编码机制来容纳参数值中的8位信息。
Asterisks ("*") are reused to provide the indicator that language and character set information is present and encoding is being used. A single quote ("'") is used to delimit the character set and language information at the beginning of the parameter value. Percent signs ("%") are used as the encoding flag, which agrees with RFC 2047.
重复使用星号（“*”）以提供语言和字符集信息存在且正在使用编码的指示器。单引号（“”）用于分隔参数值开头的字符集和语言信息。百分比符号（“%”）用作编码标志，与RFC 2047一致。
Specifically, an asterisk at the end of a parameter name acts as an indicator that character set and language information may appear at the beginning of the parameter value. A single quote is used to separate the character set, language, and actual value information in the parameter value string, and an percent sign is used to flag octets encoded in hexadecimal. For example:
具体而言，参数名称末尾的星号用作指示符，表明字符集和语言信息可能出现在参数值的开头。单引号用于分隔参数值字符串中的字符集、语言和实际值信息，百分号用于标记十六进制编码的八位字节。例如：
Content-Type: application/x-stuff;
title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
Content-Type: application/x-stuff;
title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
Note that it is perfectly permissible to leave either the character set or language field blank. Note also that the single quote delimiters MUST be present even when one of the field values is omitted. This is done when either character set, language, or both are not relevant to the parameter value at hand. This MUST NOT be done in order to indicate a default character set or language -- parameter field definitions MUST NOT assign a default character set or language.
请注意，完全允许将字符集或语言字段留空。还要注意，即使省略了一个字段值，也必须存在单引号分隔符。当字符集、语言或两者都与手头的参数值不相关时，可以执行此操作。这不能用于指示默认字符集或语言——参数字段定义不能指定默认字符集或语言。
Character set and language information may be combined with the parameter continuation mechanism. For example:
字符集和语言信息可以与参数延续机制相结合。例如：
Content-Type: application/x-stuff
title*0*=us-ascii'en'This%20is%20even%20more%20
title*1*=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"
Content-Type: application/x-stuff
title*0*=us-ascii'en'This%20is%20even%20more%20
title*1*=%2A%2A%2Afun%2A%2A%2A%20
title*2="isn't it!"
Note that:
请注意：
(1) Language and character set information only appear at the beginning of a given parameter value.
(1) 语言和字符集信息仅出现在给定参数值的开头。
(2) Continuations do not provide a facility for using more than one character set or language in the same parameter value.
(2) Continuations不提供在同一参数值中使用多个字符集或语言的功能。
(3) A value presented using multiple continuations may contain a mixture of encoded and unencoded segments.
(3) 使用多个连续体表示的值可能包含编码段和未编码段的混合。
(4) The first segment of a continuation MUST be encoded if language and character set information are given.
(4) 如果给定语言和字符集信息，则必须对连续的第一段进行编码。
(5) If the first segment of a continued parameter value is encoded the language and character set field delimiters MUST be present even when the fields are left blank.
(5) 如果对连续参数值的第一段进行编码，则即使字段留空，语言和字符集字段分隔符也必须存在。
RFC 2047 provides support for non-US-ASCII character sets in RFC 822 message header comments, phrases, and any unstructured text field. This is done by defining an encoded word construct which can appear in any of these places. Given that these are fields intended for display, it is sometimes necessary to associate language information with encoded words as well as just the character set. This specification extends the definition of an encoded word to allow the inclusion of such information. This is simply done by suffixing the character set specification with an asterisk followed by the language tag. For example:
RFC 2047支持RFC 822消息头注释、短语和任何非结构化文本字段中的非美国ASCII字符集。这是通过定义一个可以出现在这些地方的编码单词结构来实现的。由于这些字段是用于显示的，因此有时需要将语言信息与编码单词以及字符集相关联。本规范扩展了编码字的定义，允许包含此类信息。这只需在字符集规范后面加一个星号和语言标记即可。例如：
From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>
From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>
IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes.
IMAP4[RFC-2060]服务器应在生成BODY和BODYSTRUCTURE获取属性时解码参数值连续性。
The ABNF for MIME parameter values given in RFC 2045 is:
RFC 2045中给出的MIME参数值的ABNF为：
parameter := attribute "=" value
parameter := attribute "=" value
attribute := token ; Matching of attributes ; is ALWAYS case-insensitive.
属性：=令牌；属性匹配；始终不区分大小写。
This specification changes this ABNF to:
本规范将此ABNF更改为：
parameter := regular-parameter / extended-parameter
parameter := regular-parameter / extended-parameter
regular-parameter := regular-parameter-name "=" value
regular-parameter := regular-parameter-name "=" value
regular-parameter-name := attribute [section]
常规参数名称：=属性[节]
attribute := 1*attribute-char
attribute := 1*attribute-char
attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
"*", "'", "%", or tspecials>
attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
"*", "'", "%", or tspecials>
section := initial-section / other-sections
section := initial-section / other-sections
initial-section := "*0"
initial-section := "*0"
other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9") *DIGIT)
other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9") *DIGIT)
extended-parameter := (extended-initial-name "="
extended-value) /
(extended-other-names "="
extended-other-values)
extended-parameter := (extended-initial-name "="
extended-value) /
(extended-other-names "="
extended-other-values)
extended-initial-name := attribute [initial-section] "*"
extended-initial-name := attribute [initial-section] "*"
extended-other-names := attribute other-sections "*"
extended-other-names := attribute other-sections "*"
extended-initial-value := [charset] "'" [language] "'"
extended-other-values
extended-initial-value := [charset] "'" [language] "'"
extended-other-values
extended-other-values := *(ext-octet / attribute-char)
extended-other-values := *(ext-octet / attribute-char)
ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
charset := <registered character set name>
charset := <registered character set name>
language := <registered language tag [RFC-1766]>
language := <registered language tag [RFC-1766]>
The ABNF given in RFC 2047 for encoded-words is:
RFC 2047中给出的编码字ABNF为：
encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
This specification changes this ABNF to:
本规范将此ABNF更改为：
encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
In the future it is likely that some character sets will provide facilities for inline language labeling. Such facilities are inherently more flexible than those defined here as they allow for language switching in the middle of a string.
在未来，一些字符集可能会提供内联语言标签的功能。这样的设施本质上比在这里定义的更灵活，因为它们允许在字符串的中间进行语言切换。
If and when such facilities are developed they SHOULD be used in preference to the language labeling facilities specified here. Note that all the mechanisms defined here allow for the omission of language labels so as to be able to accommodate this possible future usage.
如果开发此类设施，则应优先使用此处规定的语言标签设施。请注意，这里定义的所有机制都允许省略语言标签，以便能够适应将来可能的使用。
This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of MIME.
本RFC不讨论安全问题，也不认为会提出任何电子邮件中尚未出现的安全问题以及MIME完全一致性实现中存在的安全问题。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822 August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC-1766]Alvestrand，H.，“语言识别标签”，RFC 1766，1995年3月。
[RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，1996年12月。
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, December 1996.
[RFC-2047]Moore，K.，“多用途Internet邮件扩展（MIME）第三部分：Internet消息头中非ASCII文本的表示”，RFC 2047，1996年12月。
[RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, December 1996.
[RFC-2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：MIME注册程序”，RFC 2048，1996年12月。
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.
[RFC-2049]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年12月。
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC-2060]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 2060，1996年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[RFC-2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "Report from the IAB Character Set Workshop", RFC 2130, April 1997.
[RFC-2130]Weider，C.，Preston，C.，Simonsen，K.，Alvestrand，H.，Atkinson，R.，Crispin，M.，和P.Svanberg，“来自IAB字符集研讨会的报告”，RFC 2130，1997年4月。
[RFC-2183] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[RFC-2183]Troost，R.，Dorner，S.和K.Moore，“在互联网消息中传达呈现信息：内容处置标题”，RFC 2183，1997年8月。
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Ned Freed Innosoft International，Inc.美国加利福尼亚州西科维纳湖大道1050号，邮编：91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.com
Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA
基思穆尔计算机科学系田纳西大学107诺克斯维尔Ayres Hall TN美国
EMail: moore@cs.utk.edu
EMail: moore@cs.utk.edu
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。