Network Working Group Harald Tveit Alvestrand Internet Draft: Multipart/Related UNINETT Edward Levinson ACCURATE Info. Sys. January 31, 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 proposals for MIME-SGML, 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 Levinson and Alvestrand Expires July 31, 1995 [Page 1] Internet Draft Multipart/Related information are required, the "root" or starting body part(s), and an indication of the object type. 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. 2. All body parts contained within this media type must have Content-ID headers and values. 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 part. The "start" parameter, if given, points, by content-id, to the body part containing the object root. The default object root is the first body part within the Multipart/Related body. The root header also specifies the additional object information required to display the object. The relationships between the body parts of a compound object distinguishes it from other object types. Those relationships are often represented by links internal to the object's components that reference other components. Within a single operating environment the links are often file Levinson and Alvestrand Expires July 31, 1995 [Page 2] Internet Draft Multipart/Related names, within a MIME message content-ids can serve the same purpose. MIME message composers are encouraged, as a recommended practice, to use the content-id header for each body part within the Multipart/Related body part. 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 compound object's "root". If the content-ID of several body parts are listed, then the first body part referenced specifies the object type. 3.2 The Type Parameter The type parameter can be specified to indicate the content-type of the Multipart/Related object. Using this parameter permits a MIME agent to determine the content-type without reference to the enclosed body part. The type parameter is expected to be useful in those agents processing the MIME message as a stream. 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 multipart-subtype = existing-subtypes / "related" related-param = ( ";" "start" "=" msg-id ) / ( ";" "type" "=" type "/" subtype ) Note that quotes are required if the type parameter value has embedded blanks. 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. Levinson and Alvestrand Expires July 31, 1995 [Page 3] Internet Draft Multipart/Related 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> 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-sgml The Text/X-sgml content-type has three parameters declaration optional catalog optional style-sheet optional Note, a MIME encapsulation of SGML is currently under discussion. In this example the Multipart/Related type parameter is omitted. Another feature of this example is the inclusion of an additional body part, the picture. It is referred to internally by the encapsulated document via 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. Content-Type: Multipart/Related; boundary=example; start=950118.1528@XIson.com --example Levinson and Alvestrand Expires July 31, 1995 [Page 4] Internet Draft Multipart/Related Content-Type: Text/x-sgml; charset=iso-8859-1; declaration=<950118.1530@XIson.com> Content-ID: <950118.1528@XIson.com> Content-Description: Document ] > whatever --example Content-Type: Application/x-sgml; charset=iso-8859-1 Content-ID: <950118.1530@XIson.com> Content-Description: An sgml declaration --example Content-Type: image/jpeg Content-ID: <950118.1532@XIson.com> Content-Transfer-Encoding: BASE64 Content-Description: Picture [encoded jpeg image] --example-- 5. User Agent Requirements MIME-capable mail user agents (MUAs) may suppress display of Multipart/Related body parts whose underlying content-type cannot be displayed. The underlying content-type is the content-type of the first body part pointed to by the start parameter. If the type parameter value is given, the MUA may base its display decision on that value. The MUA must make available to the process that displays the underlying content-type the correspondence between the content-ids of the constituent body parts and their storage locations. Similarly, the value of the start parameter must be available. 6. Security considerations Security considerations relevant to Multipart/Related are identical to those of the embedded content-type. 7. Acknowledgments Acknowledgements are, as always, due to more people than can be listed. However, the authors take full responsibility for all errors contained in this document. Levinson and Alvestrand Expires July 31, 1995 [Page 5] Internet Draft Multipart/Related 8. References [822] Crocker, D., Standard for the Format of ARPA Internet Text Messages, August 1982, University of Delaware, RFC 822. [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. [SGML] ISO 8879:1988, Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML). [CID] Levinson, E., CID: The Content-ID Uniform Resource Locator, work in progress, ftp://ds.internic.net/internet- drafts/draft-levinson-cid-00.txt. 9. Author's address Edward Levinson Accurate Information Systems, Inc. 2 Industrial Way Eatontown, NJ 07724-2265 USA +1 908 389 5550 Harald T. Alvestrand UNINETT P.O.Box 6883 Elgeseter N-7002 Trondheim Norway Levinson and Alvestrand Expires July 31, 1995 [Page 6]