Network Working Group E. Levinson
Request for Comments: 2387 August 1998
Obsoletes: 2112
Category: Standards Track
Network Working Group E. Levinson
Request for Comments: 2387 August 1998
Obsoletes: 2112
Category: Standards Track
The MIME Multipart/Related Content-type
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use.
多部分/相关内容类型提供了一种通用机制，用于表示作为相关MIME主体部分聚合的对象。本文档定义了多部分/相关内容类型，并提供了其使用示例。
Several applications of MIME, including MIME-PEM, and MIME-Macintosh and other proposals, require multiple body parts that make sense only in the aggregate. The present approach to these compound objects has been to define specific multipart subtypes for each new object. In keeping with the MIME philosophy of having one mechanism to achieve the same goal for different purposes, this document describes a single mechanism for such aggregate or compound objects.
MIME的几个应用程序，包括MIME-PEM、MIME Macintosh和其他建议，需要多个身体部位，这些部位只有在整体上才有意义。这些复合对象的当前方法是为每个新对象定义特定的多部分子类型。为了与MIME的理念保持一致，即使用一种机制实现不同目的的相同目标，本文档描述了用于此类聚合或复合对象的单一机制。
The Multipart/Related content-type addresses the MIME representation of compound objects. The object is categorized by a "type" parameter. Additional parameters are provided to indicate a specific starting body part or root and auxiliary information which may be required when unpacking or processing the object.
多部分/相关内容类型处理复合对象的MIME表示。对象按“类型”参数分类。提供附加参数，以指示特定的起始主体部分或根部，以及解包或处理对象时可能需要的辅助信息。
Multipart/Related MIME entities may contain Content-Disposition headers that provide suggestions for the storage and display of a body part. Multipart/Related processing takes precedence over Content-Disposition; the interaction between them is discussed in section 4.
多部分/相关MIME实体可能包含为主体部分的存储和显示提供建议的内容处置头。多部分/相关处理优先于内容处理；第4节讨论了它们之间的相互作用。
Responsibility for the display or processing of a Multipart/Related's constituent entities rests with the application that handles the compound object.
处理复合对象的应用程序负责显示或处理多部分/相关部分的组成实体。
The following form is copied from RFC 1590, Appendix A.
以下表格复制自RFC 1590附录A。
To: IANA@isi.edu
Subject: Registration of new Media Type content-type/subtype
To: IANA@isi.edu
Subject: Registration of new Media Type content-type/subtype
Media Type name: Multipart
媒体类型名称：多部分
Media subtype name: Related
媒体子类型名称：相关
Required parameters: Type, a media type/subtype.
所需参数：类型，媒体类型/子类型。
Optional parameters: Start Start-info
可选参数：开始信息
Encoding considerations: Multipart content-types cannot have encodings.
编码注意事项：多部分内容类型不能有编码。
Security considerations: Depends solely on the referenced type.
安全注意事项：仅取决于引用的类型。
Published specification: RFC-REL (this document).
已发布规范：RFC-REL（本文件）。
Person & email address to contact for further information: Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 +1 908 494 1606 XIson@cnj.digex.net
联系人和电子邮件地址，以获取更多信息：Edward Levinson 47 Clive Street Metuchen，NJ 08840-1060+1 908 494 1606XIson@cnj.digex.net
The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts. The content-type of the Multipart/Related object is specified by the type parameter. The "start" parameter, if given, points, via a content-ID, to the body part that contains the object root. The default root is the first body part within the Multipart/Related body.
多部分/相关媒体类型适用于由多个相互关联的身体部位组成的复合对象。对于多部分/相关对象，单独显示组成身体部位无法实现正确显示。多部分/相关对象的内容类型由type参数指定。“start”参数（如果给定）通过内容ID指向包含对象根的主体部分。默认根是多部分/相关主体中的第一个主体部分。
The relationships among the body parts of a compound object distinguishes it from other object types. These relationships are often represented by links internal to the object's components that
复合对象的身体部位之间的关系将其与其他对象类型区分开来。这些关系通常由对象组件的内部链接表示，这些组件
reference the other components. Within a single operating environment the links are often file names, such links may be represented within a MIME message using content-IDs or the value of some other "Content-" headers.
参考其他组件。在单个操作环境中，链接通常是文件名，此类链接可以在MIME消息中使用内容ID或某些其他“content-”头的值表示。
The type parameter must be specified and its value is the MIME media type of the "root" body part. It permits a MIME user agent to determine the content-type without reference to the enclosed body part. If the value of the type parameter and the root body part's content-type differ then the User Agent's behavior is undefined.
必须指定类型参数，其值为“根”主体部分的MIME媒体类型。它允许MIME用户代理确定内容类型，而无需参考封闭的主体部分。如果类型参数的值与根主体部分的内容类型不同，则用户代理的行为未定义。
The start parameter, if given, is the content-ID of the compound object's "root". If not present the "root" is the first body part in the Multipart/Related entity. The "root" is the element the applications processes first.
start参数（如果给定）是复合对象“根”的内容ID。如果不存在，“根”是多部分/相关实体中的第一个主体部分。“根”是应用程序首先处理的元素。
Additional information can be provided to an application by the start-info parameter. It contains either a string or points, via a content-ID, to another MIME entity in the message. A typical use might be to provide additional command line parameters or a MIME entity giving auxiliary information for processing the compound object.
可以通过start info参数向应用程序提供其他信息。它包含一个字符串或通过内容ID指向消息中的另一个MIME实体。典型的用法可能是提供额外的命令行参数或MIME实体，提供处理复合对象的辅助信息。
Applications that use Multipart/Related must specify the interpretation of start-info. User Agents shall provide the parameter's value to the processing application. Processes can distinguish a start-info reference from a token or quoted-string by examining the first non-white-space character, "<" indicates a reference.
使用Multipart/Related的应用程序必须指定开始信息的解释。用户代理应向处理应用程序提供参数值。进程可以通过检查第一个非空白字符“<”指示引用，将开始信息引用与标记或带引号的字符串区分开来。
related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
cid-list := cid cid-list
cid列表：=cid列表
cid := msg-id ; c.f. [822]
cid := msg-id ; c.f. [822]
value := token / quoted-string ; c.f. [MIME]
; value cannot begin with "<"
value := token / quoted-string ; c.f. [MIME]
; value cannot begin with "<"
Note that the parameter values will usually require quoting. Msg-id contains the special characters "<", ">", "@", and perhaps other special characters. If msg-id contains quoted-strings, those quote marks must be escaped. Similarly, the type parameter contains the special character "/".
请注意，参数值通常需要引用。Msg id包含特殊字符“<”、“>”、“@”，可能还有其他特殊字符。如果msg id包含带引号的字符串，则必须转义这些引号。类似地，type参数包含特殊字符“/”。
Content-Disposition Headers [DISP] suggest presentation styles for MIME body parts. [DISP] describes two presentation styles, called the disposition type, INLINE and ATTACHMENT. These, used within a multipart entity, allow the sender to suggest presentation information. [DISP] also provides for an optional storage (file) name. Content-Disposition headers could appear in one or more body parts contained within a Multipart/Related entity.
内容处置标题[DISP]建议MIME正文部分的表示样式。[DISP]描述了两种表示样式，称为处置类型，内联和附件。这些在多部分实体中使用，允许发送者建议演示信息。[DISP]还提供了可选的存储（文件）名称。内容处置标题可能出现在多部分/相关实体中包含的一个或多个正文部分中。
Using Content-Disposition headers in addition to Multipart/Related provides presentation information to User Agents that do not recognize Multipart/Related. They will treat the multipart as Multipart/Mixed and they may find the Content-Disposition information useful.
除了使用Multipart/Related之外，还使用Content-Disposition头为不识别Multipart/Related的用户代理提供表示信息。他们将多部分视为多部分/混合，他们可能会发现内容配置信息很有用。
With Multipart/Related however, the application processing the compound object determines the presentation style for all the contained parts. In that context the Content-Disposition header information is redundant or even misleading. Hence, User Agents that understand Multipart/Related shall ignore the disposition type within a Multipart/Related body part.
但是，对于Multipart/Related，处理复合对象的应用程序确定所有包含部件的表示样式。在这种情况下，内容处置标题信息是冗余的，甚至是误导性的。因此，理解多部分/相关的用户代理应忽略多部分/相关身体部位内的处置类型。
It may be possible for a User Agent capable of handling both Multipart/Related and Content-Disposition headers to provide the invoked application the Content-Disposition header's optional filename parameter to the Multipart/Related. The use of that information will depend on the specific application and should be specified when describing the handling of the corresponding compound object. Such descriptions would be appropriate in an RFC registering that object's media type.
能够处理多部分/相关和内容处置头的用户代理可以向被调用的应用程序提供内容处置头的可选文件名参数给多部分/相关。该信息的使用将取决于具体应用，并且在描述相应复合对象的处理时应指定。这样的描述适用于注册该对象媒体类型的RFC。
The X-FixedRecord content-type consists of one or more octet-streams and a list of the lengths of each record. The root, which lists the record lengths of each record within the streams. The record length
X-FixedRecord内容类型由一个或多个八位字节流和每个记录的长度列表组成。根，列出流中每个记录的记录长度。记录长度
list, type Application/X-FixedRecord, consists of a set of INTEGERs in ASCII format, one per line. Each INTEGER gives the number of octets from the octet-stream body part that constitute the next "record".
列表类型为Application/X-FixedRecord，由一组ASCII格式的整数组成，每行一个。每个整数给出构成下一个“记录”的八位字节流体部分的八位字节数。
The example below, uses a single data block.
下面的示例使用单个数据块。
Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>
25 10 34 10 25 21 26 10 --example-1 Content-Type: Application/octet-stream Content-Description: The fixed length records Content-Transfer-Encoding: base64 Content-ID: <950120.aaCB@XIson.com>
25 10 34 10 25 21 26 10--示例1内容类型：应用程序/八位字节流内容描述：固定长度记录内容传输编码：base64内容ID:<950120。aaCB@XIson.com>
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo=
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEKGTWPBMQGB24GAGLZIGZHCM0GAGUGGFK IHNVBWUGZHVJA3MKRSBJJUEGSSBCLDPDGGGYS BxDWFJAYBxDWFJAYBYBYBYBYBYBYWJAYBYBYBYWJAYBYBYBYWYBYBYWYBYWYBYBYWYBYBYWYBYBYWYBYBYBYBYBYBYBYBYWYBYW=
--example-1--
--示例-1--
The Text/X-Okie is an invented markup language permitting the inclusion of images with text. A feature of this example is the inclusion of two additional body parts, both picture. They are referred to internally by the encapsulated document via each picture's body part content-ID. Usage of "cid:", as in this example, may be useful for a variety of compound objects. It is not, however, a part of the Multipart/Related specification.
Text/X-Okie是一种发明的标记语言，允许在文本中包含图像。本例的一个特点是包含两个附加的身体部位，均为图片。它们由封装文档通过每张图片的主体部分content-ID在内部引用。如本例所示，使用“cid:”可能对各种复合对象有用。但是，它不是多部分/相关规范的一部分。
Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>"
type="Text/x-Okie"
Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>"
type="Text/x-Okie"
--example-2
Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118.AEB0@XIson.com>"
Content-ID: <950118.AEBH@XIson.com>
Content-Description: Document
--example-2
Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118.AEB0@XIson.com>"
Content-ID: <950118.AEBH@XIson.com>
Content-Description: Document
{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:950118.AECB@XIson.com}
{para}
Now this is an enlargement of the area ...
{image file=cid:950118:AFDH@XIson.com}
{/doc}
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AFDH@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture A
{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:950118.AECB@XIson.com}
{para}
Now this is an enlargement of the area ...
{image file=cid:950118:AFDH@XIson.com}
{/doc}
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AFDH@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture A
[encoded jpeg image]
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
[encoded jpeg image]
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
[encoded jpeg image] --example-2--
[编码的jpeg图像]--示例2--
In the above example each image body part could also have a Content-Disposition header. For example,
在上面的示例中，每个图像主体部分还可以有一个内容处置头。例如
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
Content-Disposition: INLINE
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
Content-Disposition: INLINE
[encoded jpeg image] --example-2--
[编码的jpeg图像]--示例2--
User Agents that recognize Multipart/Related will ignore the Content-Disposition header's disposition type. Other User Agents will process the Multipart/Related as Multipart/Mixed and may make use of that header's information.
识别多部分/相关的用户代理将忽略内容处置标头的处置类型。其他用户代理将把Multipart/Related作为Multipart/Mixed处理，并可能利用该头的信息。
User agents that do not recognize Multipart/Related shall, in accordance with [MIME], treat the entire entity as Multipart/Mixed. MIME User Agents that do recognize Multipart/Related entities but are unable to process the given type should give the user the option of suppressing the entire Multipart/Related body part shall be.
不识别多部分/相关的用户代理应根据[MIME]将整个实体视为多部分/混合。MIME用户代理可识别多部分/相关实体，但无法处理给定类型，应允许用户选择抑制整个多部分/相关主体部分。
Existing MIME-capable mail user agents (MUAs) handle the existing media types in a straightforward manner. For discrete media types (e.g. text, image, etc.) the body of the entity can be directly passed to a display process. Similarly the existing composite subtypes can be reduced to handing one or more discrete types. Handling Multipart/Related differs in that processing cannot be reduced to handling the individual entities.
现有的支持MIME的邮件用户代理（MUA）以简单的方式处理现有的媒体类型。对于离散媒体类型（例如文本、图像等），实体的主体可以直接传递到显示过程。类似地，现有的复合子类型可以简化为处理一个或多个离散类型。处理多部分/相关的不同之处在于，处理不能简化为处理单个实体。
The following sections discuss what information the processing application requires.
以下各节讨论处理应用程序需要哪些信息。
It is possible that an application specific "receiving agent" will manipulate the entities for display prior to invoking actual application process. Okie, above, is an example of this; it may need a receiving agent to parse the document and substitute local file names for the originator's file names. Other applications may just require a table showing the correspondence between the local file names and the originator's. The receiving agent takes responsibility for such processing.
在调用实际应用程序流程之前，特定于应用程序的“接收代理”可能会操纵实体以进行显示。上面的Okie就是一个例子；它可能需要一个接收代理来解析文档，并用本地文件名替换发起人的文件名。其他应用程序可能只需要一个表格，显示本地文件名与发起人文件名之间的对应关系。接收代理负责此类处理。
MIME-capable mail user agents (MUAs) are required to provide the application:
需要支持MIME的邮件用户代理（MUA）来提供应用程序：
(a) the bodies of the MIME entities and the entity Content-* headers,
(a) MIME实体的主体和实体内容-*头，
(b) the parameters of the Multipart/Related Content-type header, and
(b) 多部分/相关内容类型标头的参数，以及
(c) the correspondence between each body's local file name, that body's header data, and, if present, the body part's content-ID.
(c) 每个实体的本地文件名、该实体的头数据和（如果存在）实体零件的content-ID之间的对应关系。
The Multipart/Related media type will be used for objects that have internal linkages between the body parts. When the objects are stored the linkages may require processing by the application or its receiving agent.
多部分/相关媒体类型将用于在身体部位之间具有内部链接的对象。存储对象时，链接可能需要应用程序或其接收代理进行处理。
MIME is a recursive structure. Hence one must expect a Multipart/Related entity to contain other Multipart/Related entities. When a Multipart/Related entity is being processed for display or storage, any enclosed Multipart/Related entities shall be processed as though they were being stored.
MIME是一种递归结构。因此，必须期望多部分/相关实体包含其他多部分/相关实体。当处理多部分/相关实体以进行显示或存储时，应对任何封闭的多部分/相关实体进行处理，就像它们被存储一样。
It is suggested that MUAs that use configuration mechanisms, see [CFG] for an example, refer to Multipart/Related as Multi-part/Related/<type>, were <type> is the value of the "type" parameter.
建议使用配置机制的MUA，例如参见[CFG]，将Multipart/Related称为Multi-part/Related/<type>，were<type>是“type”参数的值。
Security considerations relevant to Multipart/Related are identical to those of the underlying content-type.
与Multipart/Related相关的安全注意事项与基础内容类型的安全注意事项相同。
This proposal is the result of conversations the author has had with many people. In particular, Harald A. Alvestrand, James Clark, Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinchfield, provided both encouragement and invaluable help. The author, however, take full responsibility for all errors contained in this document.
这项建议是作者与许多人交谈的结果。特别是，哈拉尔·A·阿尔维斯特朗、詹姆斯·克拉克、查尔斯·戈德法布、加里·休斯顿、内德·弗里德、雷·穆迪和唐·斯丁奇菲尔德都提供了鼓励和宝贵的帮助。但是，作者应对本文件中包含的所有错误承担全部责任。
[822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[CID] Levinson, E., and J. Clark, "Message/External-Body Content-ID Access Type", RFC 1873, December 1995, Levinson, E., "Message/External-Body Content-ID Access Type", Work in Progress.
[CID]Levinson，E.和J.Clark，“消息/外部主体内容ID访问类型”，RFC 1873，1995年12月，Levinson，E，“消息/外部主体内容ID访问类型”，正在进行的工作。
[CFG] Borenstein, N., "A User Agent Configuration Mechanism For Multimedia Mail Format Information", RFC 1524, September 1993.
[CFG]Borenstein，N.，“多媒体邮件格式信息的用户代理配置机制”，RFC 1524，1993年9月。
[DISP] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[DISP]Troost，R.和S.Dorner，“在互联网消息中传达呈现信息：内容处置标题”，RFC 1806，1995年6月。
[MIME] Borenstein, N., and Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Borenstein，N.和Freed，N.，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 USA
Edward Levinson美国新泽西州梅图臣克莱夫街47号，邮编08840-1060
Phone: +1 908 494 1606
EMail: XIson@cnj.digex.com
Phone: +1 908 494 1606
EMail: XIson@cnj.digex.com
Corrected cid urls to conform to RFC 2111; the angle brackets were removed.
更正cid URL，以符合RFC 2111；角括号已拆除。
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。