Network Working Group G. Klyne
Request for Comments: 2912 Content Technologies
Category: Standards Track September 2000
Network Working Group G. Klyne
Request for Comments: 2912 Content Technologies
Category: Standards Track September 2000
Indicating Media Features for MIME Content
指示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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.
在“描述媒体功能集的语法”中，提供了一种表达式格式，用于使用简单的媒体功能标签描述媒体功能。
This memo defines a Multipurpose Internet Mail Extensions (MIME) 'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.
此备忘录定义了一个多用途Internet Mail Extensions（MIME）“Content features:”标头，可用于使用此表达式格式对MIME邮件部分进行注释，并指明可能的使用方式。
Table of Contents
目录
1. Introduction ............................................... 2
1.1 Terminology and document conventions ................... 2
2. Motivation and goals ....................................... 3
3. The 'Content-features:' MIME header ........................ 4
3.1 Whitespace and folding long headers .................... 4
3.2 Usage considerations ................................... 4
3.2.1 Simple message parts ............................... 4
3.2.2 Multipart and other composites ..................... 5
3.2.3 Reference to external data ......................... 5
4. Examples ................................................... 5
4.1 Simple message ......................................... 5
4.2 Fax message ............................................ 6
4.3 Multipart/alternative data ............................. 6
4.4 Reference to external message data ..................... 8
4.5 Compressed data ........................................ 8
4.6 Multipart/related data ................................. 8
5. Security Considerations .................................... 9
6. Acknowledgements ........................................... 10
7. References ................................................. 10
8. Author's Address ........................................... 10
Full Copyright Statement ...................................... 11
1. Introduction ............................................... 2
1.1 Terminology and document conventions ................... 2
2. Motivation and goals ....................................... 3
3. The 'Content-features:' MIME header ........................ 4
3.1 Whitespace and folding long headers .................... 4
3.2 Usage considerations ................................... 4
3.2.1 Simple message parts ............................... 4
3.2.2 Multipart and other composites ..................... 5
3.2.3 Reference to external data ......................... 5
4. Examples ................................................... 5
4.1 Simple message ......................................... 5
4.2 Fax message ............................................ 6
4.3 Multipart/alternative data ............................. 6
4.4 Reference to external message data ..................... 8
4.5 Compressed data ........................................ 8
4.6 Multipart/related data ................................. 8
5. Security Considerations .................................... 9
6. Acknowledgements ........................................... 10
7. References ................................................. 10
8. Author's Address ........................................... 10
Full Copyright Statement ...................................... 11
In "A Syntax for Describing Media Feature Sets" [1], an expression format is presented for describing media feature capabilities as a combination of simple media feature tags, registered according to "Media Feature Tag Registration Procedure" [2]. This provides a format for message handling agents to describe the media feature content of messages that they can handle.
在“描述媒体功能集的语法”[1]中，提供了一种表达式格式，用于将媒体功能功能描述为简单媒体功能标签的组合，并根据“媒体功能标签注册程序”[2]注册。这为消息处理代理提供了一种格式，用于描述它们可以处理的消息的媒体功能内容。
This memo defines a MIME 'Content-features:' header that can be used to annotate a MIME message part using these feature expressions. This header provides a means to indicate media-related features of message content that go beyond the MIME content type.
此备忘录定义了一个MIME“Content features:”标头，可用于使用这些功能表达式对MIME消息部分进行注释。此标头提供了一种方法，用于指示超出MIME内容类型的消息内容的媒体相关功能。
Consideration is also given to how it may be used to present message media content information that is problematic to express within the basic MIME framework.
还考虑了如何使用它来呈现在基本MIME框架中难以表达的消息媒体内容信息。
This section defines a number of terms and other document conventions, which are used with specific meaning in this memo.
本节定义了许多术语和其他文件惯例，这些术语和惯例在本备忘录中具有特定含义。
media feature information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.
媒体功能信息，指示假定可用于正确呈现或以其他方式呈现消息内容的设施。媒体功能不包括影响消息传输的信息。
feature set some set of media features described by a media feature assertion, as described in "A Syntax for Describing Media Feature Sets" [1]. (See that memo for a more formal definition of this term.)
功能集由媒体功能断言描述的一些媒体功能集，如“描述媒体功能集的语法”[1]中所述。（有关该术语更正式的定义，请参见该备忘录。）
feature set expression a string that describes some feature set, formulated according to the rules in "A Syntax for Describing Media Feature Sets" [1] (and possibly extended by other specifications).
功能集表达式描述某些功能集的字符串，根据“描述媒体功能集的语法”[1]中的规则制定（可能由其他规范扩展）。
This specification uses syntax notation and conventions described in RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3].
本规范使用RFC 2234“语法规范的扩充BNF:ABNF”[3]中描述的语法符号和约定。
NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth.
注：此类评论提供了有关本文件背后的基本原理的其他非必要信息。构建一致性实现不需要这些信息，但可以帮助那些希望更深入地理解设计的人。
It is envisaged that media feature labelling of message parts may be used in the following ways:
设想消息部分的媒体特征标签可通过以下方式使用：
o to supply more detailed media feature information about a message content than can be provided by the 'Content-type:' header.
o 提供有关消息内容的更详细的媒体功能信息，而不是“content type:”标头提供的信息。
o to provide summary media feature information (possibly including MIME content types) about the content of a composite MIME message part (e.g. 'multipart' or 'message'), without having to open up the inner content of the message.
o 提供关于复合MIME消息部分（例如“多部分”或“消息”）内容的摘要媒体功能信息（可能包括MIME内容类型），而无需打开消息的内部内容。
o to supply media feature information about external data referenced by a message part (e.g. 'message/external-body' MIME type). This information would not be available by examination of the message content.
o 提供有关消息部分引用的外部数据的媒体功能信息（例如“消息/外部正文”MIME类型）。通过检查邮件内容无法获得此信息。
o to describe the content of a message that is encrypted or encoded using some application-specific file structure that hides the content from a MIME processor. This information also would not be generally available by examination of the message content.
o 描述使用特定于应用程序的文件结构加密或编码的消息内容，该文件结构对MIME处理器隐藏内容。通过检查消息内容，通常也无法获得此信息。
A new header field is defined that extends the allowable formats for 'optional-field' [4] with the following syntax:
定义了一个新的标题字段，该字段使用以下语法扩展了“可选字段”[4]的允许格式：
optional-field =/ "Content-features" ":" Feature-expr
Feature-expr = filter ; See [1], section 4.1
optional-field =/ "Content-features" ":" Feature-expr
Feature-expr = filter ; See [1], section 4.1
where 'filter' is the media feature expression format defined by "A Syntax for Describing Media Feature Sets" [1].
其中，“过滤器”是由“描述媒体功能集的语法”定义的媒体功能表达式格式[1]。
This header provides additional information about the message content directly contained or indirectly referenced in the corresponding MIME message part.
此标头提供有关相应MIME消息部分中直接包含或间接引用的消息内容的附加信息。
In some circumstances, media feature expressions can be very long.
在某些情况下，媒体功能表达式可能非常长。
According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature expression. Further, RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears to avoid line length restrictions.
根据“描述媒体功能集的语法”[1]，媒体功能表达式的词汇元素之间允许空白。此外，RFC822/MIME[4,5]允许在空白处折叠长标题，以避免行长度限制。
Therefore, it is recommended that whitespace is included as permitted, especially in long media feature expressions, to facilitate the folding of headers by agents that do not otherwise understand the syntax of this field.
因此，建议在允许的情况下包括空格，特别是在长媒体功能表达式中，以便于不理解此字段语法的代理折叠标题。
When applied to a simple MIME message part, the header should appear just once and is used to convey additional information about the message part content that goes beyond that provided by the MIME 'Content-type:' header field. The 'Content-features:' header may indicate a content type that is different than that given by the MIME 'Content-type:' header. This is possible but not recommended when applied to a non-composite body part: in any case, MIME content type processing must be performed in accordance with the 'Content-type:' header.
当应用于简单的MIME消息部分时，头应该只出现一次，并用于传递有关消息部分内容的附加信息，这些信息超出了MIME“content type:”头字段提供的信息。“Content features:”标头可能表示与MIME“Content type:”标头给出的内容类型不同的内容类型。这是可能的，但不建议应用于非复合主体零件：在任何情况下，MIME内容类型处理都必须按照“content type:”标题执行。
NOTE: Once the message content has been delivered to an application, it is possible that subsequent processing may be affected by content type information indicated by the media feature expression. See example 4.5 below.
注意：一旦消息内容已交付给应用程序，后续处理可能会受到媒体功能表达式指示的内容类型信息的影响。见下面的示例4.5。
'Content-features:' headers may be applied to a MIME multipart indicating information about the inner content of the multipart.
“Content features:”头可以应用于MIME多部分，指示有关多部分内部内容的信息。
Implementations must not assume a one-to-one relationship between 'Content-features' headers and contained body parts. Headers may appear on a containing multipart wrapper in a different order than the body parts to which they refer; a single header may refer to more than one contained body part; several headers may refer to the same contained body part.
实现不得假定“内容功能”标题和包含的正文部分之间存在一对一的关系。标题可能以不同于它们所指的主体部分的顺序出现在包含多部分包装上；单个收割台可指多个包含的车身部件；多个标题可能指的是同一个包含的主体部分。
If it is important to relate specific media features to specific contained MIME body parts, then the 'Content-features:' header should be applied directly to the body part concerned, rather than the surrounding composite.
如果将特定媒体功能与特定包含的MIME正文部分相关联很重要，那么“Content features:”标题应直接应用于相关正文部分，而不是周围的复合内容。
NOTE: The intent here is to allow summary media feature information to be provided without having to open up and examine the inner content of the MIME message.
注意：此处的目的是允许提供摘要媒体功能信息，而无需打开并检查MIME消息的内部内容。
Similar usage may apply when the message format is a non-MIME or opaque composite; e.g. 'application/zip', or an encrypted message. In these cases, the option of examining the message content to discover media feature information is not available.
当消息格式为非MIME或不透明组合时，可能会使用类似的用法；e、 g.“application/zip”或加密消息。在这些情况下，检查消息内容以发现媒体功能信息的选项不可用。
Media feature information about data indirectly referenced by a MIME body part rather than contained within a message can be conveyed using one or more 'Content-features:' headers.
可以使用一个或多个“Content features:”标题来传递有关MIME正文部分间接引用而非包含在消息中的数据的媒体功能信息。
For example, media information --including contained MIME content type(s)-- about the data referenced by a MIME 'Message/external-body' may be conveyed.
例如，可以传递有关MIME“消息/外部主体”引用的数据的媒体信息（包括包含的MIME内容类型）。
Mime-Version: 1.0
Content-type: text/plain;charset=US-ASCII
Content-features: (& (paper-size=A4) (ua-media=stationery) )
Mime-Version: 1.0
Content-type: text/plain;charset=US-ASCII
Content-features: (& (paper-size=A4) (ua-media=stationery) )
: (data) :
：（数据）：
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="break"
Content-features:
(& (Type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-S)
(dpi=200)
(dpi-xyratio=200/100)
(paper-size=A4)
(image-coding=MH) (MRC-mode=0)
(ua-media=stationery) )
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="break"
Content-features:
(& (Type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-S)
(dpi=200)
(dpi-xyratio=200/100)
(paper-size=A4)
(image-coding=MH) (MRC-mode=0)
(ua-media=stationery) )
--break
Content-Type: image/tiff; name="coverpage.tiff"
Content-Transfer-Encoding: base64
Content-Description: This part is a coverpage
Content-Disposition: attachment; filename="coverpage.tiff"
--break
Content-Type: image/tiff; name="coverpage.tiff"
Content-Transfer-Encoding: base64
Content-Description: This part is a coverpage
Content-Disposition: attachment; filename="coverpage.tiff"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
:
(more data)
:
--break
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA
AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
:
(more data)
:
--break
Content-Type: image/tiff; name="document.tiff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.tiff"
Content-Type: image/tiff; name="document.tiff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA : (more data) : --break--
aaaadgaaaa8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaababaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa--
This example illustrates three points:
这个例子说明了三点：
o Information about the various parts in a multipart/alternative can be made available before the alternative body parts are processed. This may facilitiate optimum one-pass processing of multipart/alternative data.
o 在处理备用车身零件之前，可以获得多部件/备用车身零件中各零件的相关信息。这可能有助于多部分/备选数据的最佳一次处理。
o There may be alternatives having the same basic MIME content-type, but differing in the content features that they use.
o 可能存在具有相同基本MIME内容类型的替代方案，但它们使用的内容功能不同。
o There is NO defined correspondence between 'Content-features' headers and contained body parts.
o “内容要素”标题和包含的正文部分之间没有定义的对应关系。
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="break"
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features:
(& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
Content-features:
(& (Type="text/html") (charset=ISO-8859-1) (color=binary) )
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="break"
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features:
(& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
Content-features:
(& (Type="text/html") (charset=ISO-8859-1) (color=binary) )
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=binary)
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=binary)
:
(data)
:
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=limited)
:
(data)
:
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=limited)
: (data) : --break
：（数据）：--中断
Content-type: text/html;charset=iso-8859-1
Content-features: (color=binary)
Content-type: text/html;charset=iso-8859-1
Content-features: (color=binary)
:
(data)
:
--break
Content-type: text/html;charset=iso-8859-1
Content-features: (color=limited)
:
(data)
:
--break
Content-type: text/html;charset=iso-8859-1
Content-features: (color=limited)
: (data) : --break--
：（数据）：--中断--
Mime-Version: 1.0
Content-type: message/external-body; access-type=URL;
URL="http://www.foo.com/file1.html"
Mime-Version: 1.0
Content-type: message/external-body; access-type=URL;
URL="http://www.foo.com/file1.html"
Content-type: Multipart/mixed
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features: (& (Type="image/tiff") (color=limited) )
Content-type: Multipart/mixed
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features: (& (Type="image/tiff") (color=limited) )
<end>
<end>
This example shows how the 'Content-features' header can be used to overcome the problem noted in the MIME registration for 'Application/zip' regarding information about the data content.
此示例显示了如何使用“Content features”标题来克服“Application/zip”的MIME注册中提到的有关数据内容信息的问题。
Mime-Version: 1.0
Content-type: application/zip
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features: (& (Type="image/tiff") (color=limited) )
Content-transfer-encoding: base64
Mime-Version: 1.0
Content-type: application/zip
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features: (& (Type="image/tiff") (color=limited) )
Content-transfer-encoding: base64
: (data) : <end>
：（数据）：<end>
(See also: RFC 2387, "The MIME Multipart/Related Content-type" [8])
（另请参见：RFC 2387，“MIME多部分/相关内容类型”[8]）
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"; start="<foo3@foo1@bar.net>"
Content-features: (& (type="text/html") (charset=US-ASCII) )
Content-features: (type="image/gif")
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"; start="<foo3@foo1@bar.net>"
Content-features: (& (type="text/html") (charset=US-ASCII) )
Content-features: (type="image/gif")
--boundary-example
Content-Type: text/html;charset=US-ASCII
Content-ID: <foo3@foo1@bar.net>
--boundary-example
Content-Type: text/html;charset=US-ASCII
Content-ID: <foo3@foo1@bar.net>
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo">
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo">
--boundary-example
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--boundary-example
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0LGODLHGAGGAPEAP/////Zracgoaaach+PUNvcHlyaWdodCAoQykgMTk5 NSBjrRGlibvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchvgliaxrlzc4a等。。。
--boundary-example--
--边界示例--
When applied to simple or multipart MIME formatted data, a media feature expression provides summary information about the message data, which in many cases can be determined by examination of the message content. Under these circumstances, no additional security considerations appear to be raised.
当应用于简单或多部分MIME格式的数据时，媒体功能表达式提供有关消息数据的摘要信息，在许多情况下，可以通过检查消息内容来确定这些信息。在这种情况下，似乎没有提出额外的安全考虑。
When applied to other message composites, especially encrypted message content, feature expressions may disclose information that is otherwise unavailable. In these cases, some security considerations associated with media content negotiation [1,2] may have greater relevance.
当应用于其他消息组合（尤其是加密消息内容）时，功能表达式可能会泄漏其他情况下不可用的信息。在这些情况下，与媒体内容协商相关的一些安全考虑[1,2]可能具有更大的相关性。
It is suggested here that media feature descriptions may be usefully employed with encrypted message content. In doing this, take care to ensure that the purpose of encryption is not compromised (e.g. encryption might be intended to conceal the fact that a particular application data format is being used, which fact might be disclosed by an injudiciously applied Content-features header).
这里建议，媒体特征描述可以有效地用于加密消息内容。在执行此操作时，请注意确保加密的目的不会受到损害（例如，加密可能旨在隐藏正在使用特定应用程序数据格式的事实，这一事实可能会被应用不当的内容特征头披露）。
If a 'Content-features' header is applied to a multipart/signed object (or indeed outside any other form of signed data) the media feature information is not protected. This unprotected information could be tampered with, possibly fooling implementations into doing inappropriate things with the contained material. (Putting the media feature information inside the signed information would overcome this, at the cost of requiring implementations to parse the inner structure to find it.)
如果将“内容功能”标题应用于多部分/签名对象（或实际上在任何其他形式的签名数据之外），则媒体功能信息不受保护。这些未受保护的信息可能会被篡改，可能会欺骗实现对所包含的材料进行不适当的操作。（将媒体功能信息放在签名信息中可以克服这一问题，代价是需要实现解析内部结构才能找到它。）
This proposal draws from discussions with Dan Wing. The fax message example was taken from a proposal by Mike Ruhl. The multipart/related example is developed from RFC 2557 [7].
该提案来自与Dan Wing的讨论。传真消息示例取自Mike Ruhl的提案。多部分/相关示例是根据RFC 2557[7]开发的。
The author would like to thank the following people who offered comments that led to significant improvements: Mr Hiroshi Tamura, Ted Hardie, Maurizio Codogno, Jacob Palme, Ned Freed.
作者要感谢以下提供了显著改进意见的人：田村弘先生、特德·哈迪、毛里齐奥·科多格诺、雅各布·帕尔姆、内德·弗里德。
[1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[1] Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[2] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[2] Holtman，K.，Mutz，A.和T.Hardie，“媒体功能标签注册程序”，RFC 2506，1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[4] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[4] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Internet message bodies", RFC 2045, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第1部分：互联网邮件正文格式”，RFC 20451996年11月。
[6] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[6] Levinson，E.，“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[7] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[7] Palme，J.，Hopmann，A.和N.Shelness，“聚合文档的MIME封装，如HTML（MHTML）”，RFC2557，1999年3月。
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
格雷厄姆·克莱恩内容技术有限公司，地址：英国RG7 4SA阿灵顿商业园Theale Reading Parkview 1220
Phone: +44 118 930 1300
Fax: +44 118 930 1301
EMail: GK@ACM.ORG
Phone: +44 118 930 1300
Fax: +44 118 930 1301
EMail: GK@ACM.ORG
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。