MIMESGML Working Group E. Levinson Internet Draft: Multipart/Related ACCURATE Info. Sys. May 30, 1995 The MIME Multipart/Related Content-type This draft document is being circulated for comment. Please send your comments to the authors or to the ietf-822 mail list . If consensus is reached, this document may be submitted to the RFC editor as a Proposed Standard protocol specification for use with MIME. Status of this Memo This document is an Internet Draft; Internet Drafts are working documents of the Internet Engineering Task Force (IETF) its Areas, and Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. They may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the abstract listing in each Internet Draft directory for the current status of this or any other Internet Draft. 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. 1. Introduction 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 object 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, one single mechanism should be defined for such aggregate or compound objects. The Multipart/Related content-type addresses the MIME representation of compound objects. Basically, two pieces of information are required, the "root" or starting body part(s), and an indication of the object type. Levinson Expires December 31, 1995 [Page 1] Internet Draft Multipart/Related 2. Definition The following form is copied from RFC 1590, Appendix A. To: IANA@isi.edu Subject: Registration of new Media Type content-type/subtype Media Type name: Multipart Media subtype name: Related Required parameters: None. Optional parameters: Start, an ordered list of content-IDs. Type, a media type/subtype Encoding considerations: 1. Multipart content-types cannot have encodings. Security considerations: Depends solely on the referenced type Published specification: This document Person & email address to contact for further information: Document authors 3. Intended usage The Multipart/Related Content-Type is intended for compound object 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 actual content-type of the Multipart/Related object is specified by the content-type of the "root" or starting body parts. The "start" parameter, if given, points, by content-id, to one or more body parts that contain the object root. The default root is the first body part within the Multipart/Related body. The content-type header of the first of the start body part may also specify additional object information. 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, within a MIME message content-ids can serve the same purpose. A companion piece [CID] discusses the use of content-ids in such objects. 3.1. The Start Parameter The start parameter, if given, lists the content-ID of the Levinson Expires December 31, 1995 [Page 2] Internet Draft Multipart/Related compound object's "root". The root may consist of one or more body parts, in which case the start parameter consists of a comma separated list of content-IDs. In that case the first listed body part specifies the object type. 3.2 The Type Parameter The type parameter must be specified if the start parameter is present. It permits a MIME user agent to determine the content-type without reference to the enclosed body part. Where the content-type of the object root and the one indicated by the type parameter disagree, the object root is authoritative. The MIME agent, however, may take action, including suppressing the Multipart/Related body, based on the indicated content-type. 3.3 Syntax related-param = [ ";" "start" "=" msg-id *( "," msg-id ) ] [ ";" "type" "=" type "/" subtype ] ; order independent Note that the values of both parameters will usually require quoting. Msg-id usually contains the special characters "<", ">", "@", and perhaps others. If msg-id contains quoted-strings, those quote marks must be escaped. Similarly, the type parameter contains the special character "/". 4. Examples 4.1 Application/X-FixedRecord The X-FixedRecord content-type consists of two parts: an octet-stream and a list of the lengths of each record. The root, which lists the record lengths has one required parameter, data-blocks, whose value is the content-id of one or more octet-stream body parts. The body of 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". The example below, uses a single data block. Content-Type: Multipart/Related; boundary=tiger-lily start="<950120.1133@XIson.com>"; type="Application/X-FixedRecord" --tiger-lily Content-Type: Application/X-FixedRecord; data-blocks="<950120.1133@XIson.com>" Content-ID: <950120.1132@XIson.com> Levinson Expires December 31, 1995 [Page 3] Internet Draft Multipart/Related 25 10 34 10 25 21 26 10 --tiger-lily Content-Type: Application/octet-stream Content-Description: The fixed length records Content-Transfer-Encoding: base64 Content-ID: <950120.1133@XIson.com> T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo= --tiger-lily-- 4.2 Text/X-Okie 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. Tehy 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 this or the Multipart/Related specification. Content-Type: Multipart/Related; boundary=example; start="<950118.1528@XIson.com>" type="Text/x-Okie" --example Content-Type: Text/x-Okie; charset=iso-8859-1; declaration="<950118.1530@XIson.com>" Content-ID: <950118.1528@XIson.com> Content-Description: Document {doc} This picture was taken by an automatic camera mounted ... {image file=cid:<950118.1532@XIson.com>} {para} Now this is an enlargement of the area ... {image file=cid:<950118:1648@XIson.com>} {/doc} --example Content-Type: image/jpeg Content-ID: <950118.1648@XIson.com> Levinson Expires December 31, 1995 [Page 4] Internet Draft Multipart/Related Content-Transfer-Encoding: BASE64 Content-Description: Picture A [encoded jpeg image] --example Content-Type: image/jpeg Content-ID: <950118.1532@XIson.com> Content-Transfer-Encoding: BASE64 Content-Description: Picture B [encoded jpeg image] --example-- 5. User Agent Requirements Existing MIME-capable mail user agents (MUAs) handle the existing media types in a straigth forward 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 handings one or more discrete types. Multipart/Related entities require that all constituent body parts be available to the display process before it is invoked. The following sections discuss what information the proccessing application, called the unpacker, requires. It is possible that the unpacker will manipulate the entities for display and then invoke another process. Okie, above, is an example of this; its unpacker may need 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. 5.1 Data Requirments MIME-capable mail user agents (MUAs) are required to provide the unpacker: (a) the bodies of the MIME entities, the entity Content-* headers, (b) the parameters of the Multipart/Related Content-type header, (c) the parameters of the first start entity's Content-type header, and (d) the correspondence between each body's local file name, that body's header data, and, if present, the body part's content-id. 5.2 Storing Multipart/Related Entities 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 unpacker. Levinson Expires December 31, 1995 [Page 5] Internet Draft Multipart/Related 5.3 Recursion 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. 5.5 Configuration Considerations It is suggested that MUAs that use configuration mechanisms, see [CFG] for an example, refer to Multipart/Related as Multipart/Related/, were is the value of the underlying content-type. MIME-capable mail user agents (MUAs) may suppress processing of Multipart/Related body parts whose underlying content-type it cannot display or process. (The underlying content-type is the content-type of the start body part, or, if given, the value of the type parameter.) Alternately, the MUA may treat the Multipart/Related media type as Multipart/Mixed. 6. Security considerations Security considerations relevant to Multipart/Related are identical to those of the underlying content-type. 7. Acknowledgments This proposal is the result of conversations the author has had with many people. In particular, Harald A. Alvestrand and Ned Freed, pro- vided both encouragement and guidance. The author, however, take full responsibility for all errors contained in this document. 8. References [822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", August 1982, University of Delaware, RFC 822. [CID] Levinson, E., "CID: The Content-ID Uniform Resource Loca- tor", work in progress, ftp://ds.internic.net/internet- drafts/draft-levinson-cid-00.txt. [CFG] Borenstein, N., "A User Agent Configuration Mechanism For Multimedia Mail Format Information", September 23, 1993, RFC 1524 [MIME] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", June 1992, RFC 1341. 9. Author's address Edward Levinson Levinson Expires December 31, 1995 [Page 6] Internet Draft Multipart/Related Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 07724-2265 USA +1 908 389 5550 Levinson Expires December 31, 1995 [Page 7]