MIMESGML Working Group E. Levinson Internet Draft: Multipart/Related ACCURATE Info. Sys. July 7, 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. 0. Changes Since Previous Version Introduced content reference as formal pointer to another body part. This handles a potentially conflicting use and ambiguity with content-ids. See section 4. Added Content-Reference header and description (see above). Added Start-Info parameter which allow "command line" or other data to be passed to the invoked process. Changed Start parameter to be a single content reference. Multiple content references were thought to be needed for SGML but, it turns out are not needed. Levinson Expires January 15, 1995 [Page 1] Internet Draft Multipart/Related Changed Type parameter to be required and gave it precedence over the "root" body part's media-type. This enables user agents that must process messages on the fly to avoid searching ahead. Revised introductory text in section 3 describing the parameters and eliminated comment about parameters on the start body part. 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 and an indication of the object type. Additional "command line" information may also be needed. Normally the value of the starting body part will be a content-id. To properly handle Some ambiguous situations arise when using content-id to refer to another body part. A new header, "Content-Reference", is introduced for use when disambiguation is required. 2. Multipart/Related Registration Information The following form is copied from RFC 1590, Appendix A. Levinson Expires January 15, 1995 [Page 2] Internet Draft Multipart/Related 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, a content reference. Start-info, a content reference Encoding considerations: Multipart content-types cannot have encodings. Security considerations: Depends solely on the referenced type. Published specification: RFC-REL (this document). Person & email address to contact for further information: Edward Levinson Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 07724 +1 908 389 5550 +1 908 389 5556 (fax) ELevinson@Accurate.com 3. Intended usage The Multipart/Related Content-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, through a content reference (defined below), to the body part that contains the object root. The default root is the first body part within the Multipart/Related body. 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 references can serve the same purpose. 3.1. The Type Parameter The type parameter must be specified. It permits a MIME user agent to determine the content-type without reference Levinson Expires January 15, 1995 [Page 3] Internet Draft Multipart/Related 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.2. The Start Parameter The start parameter, if given, is a content reference to the compound object's "root". If not present the "root" is the first body part in the Multipart/Related entity. 3.3. The Start-Info Parameter Additional information can be provided to an application by the start-info parameter. It contains either a string or points, via a content reference, to another MIME entity in the message. A typical use might be to provide addtional command line parameters or a MIME entity giving auxiliary information for processing the compound object. 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. 3.4. Syntax related-param := [ ";" "start" "=" reference ] [ ";" "start-info" "=" ( reference / value ) ] [ ";" "type" "=" type "/" subtype ] ; order independent reference := msg-id ; c.f. [822] 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 "/". 4. Content References A content reference uniquely determines a MIME entity within a single message. Normally, a content reference corresponds Levinson Expires January 15, 1995 [Page 4] Internet Draft Multipart/Related to a Content-ID value. However, in some circumstances two entities may contain the same body but have different headers. Since the content-id also represents a token for a possibly cached copy of the body the two entities should, optimally, have the same content-id. Since they have different header they are different entities and should have different content-ids. To resolve this conflict and ambiguity a body part may optionally have a Content- Reference: header. Its value is a msg-id. The content reference value of a MIME entity is the value of its Content-Reference: header if present. If not present then it is the value of the Content-ID: header. If neither header is present, the entity does not have a content reference value. The syntax for the Content-Reference header is ref := "Content-Reference" ":" msg-id The following example illustrates the Content-Reference usage and the ambiguity that can arise. In the example two MIME entities have the same body content but each has a different Content-FooBar-Element header. The content-ids of both MIME entities are the same and the data may be retrieved from a cache. Content-Type: Multipart/Related; start=""; type="Application/FooBar"; boundary=example-41 --example-41 Content-type: Message/External-Body; access-type=anon-ftp; ... Content-Type: Application/FooBar Content-FooBar-Element: name=AAA; ... Content-Reference: Content-ID: --example-41 Content-type: Message/External-Body; access-type=anon-ftp; ... Content-Type: Application/FooBar Content-FooBar-Element: name=BBB; ... Content-ID: --example-41-- 5. Examples 5.1 Application/X-FixedRecord The X-FixedRecord content-type consists of one or more Levinson Expires January 15, 1995 [Page 5] Internet Draft Multipart/Related 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 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". The example below, uses a single data block. Content-Type: Multipart/Related; boundary=tiger-lily start="<950120.aaCC@XIson.com>"; type="Application/X-FixedRecord" start-info="-o ps" --tiger-lily Content-Type: Application/X-FixedRecord Content-ID: <950120.aaCC@XIson.com> 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.aaCB@XIson.com> T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo= --tiger-lily-- 5.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. 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 this or the Multipart/Related specification. Levinson Expires January 15, 1995 [Page 6] Internet Draft Multipart/Related Content-Type: Multipart/Related; boundary=example; start="<950118.AEBH@XIson.com>" type="Text/x-Okie" --example 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 Content-Type: image/jpeg Content-ID: <950118.AFDH@XIson.com> Content-Transfer-Encoding: BASE64 Content-Description: Picture A [encoded jpeg image] --example Content-Type: image/jpeg Content-ID: <950118.AECB@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 straigthtforward 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. 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 processing 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. Levinson Expires January 15, 1995 [Page 7] Internet Draft Multipart/Related 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, and (c) 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. 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. 7. Security considerations Security considerations relevant to Multipart/Related are identical to those of the underlying content-type. 8. Acknowledgments This proposal is the result of conversations the author has had with many people. In particular, Harald A. Alvestrand, James Clark, Ned Freed, and Don Stinchfield, provided both encouragement and invaluable help. The author, however, take full responsibility for all errors con- tained in this document. 8. References Levinson Expires January 15, 1995 [Page 8] Internet Draft Multipart/Related [822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", August 1982, University of Delaware, RFC 822. [CID] Levinson, E., "Message/External-Body Content-ID Access Type", work in progress, ftp://ds.internic.net/internet- drafts/draft-ietf-mimesgml-access-cid-01.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 Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 07724-2265 USA +1 908 389 5550 Levinson Expires January 15, 1995 [Page 9]