SGML: The MIME Multipart/Related Content-type

SGML: The MIME Multipart/Related Content-type

       MIMESGML Working Group                           E. Levinson
       Internet Draft: Multipart/Related        ACCURATE Info. Sys.
       <draft-ietf-mimesgml-related-01.txt>            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

       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

       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.


       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

       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.

       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

       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

            Content-Type: Application/X-FixedRecord;
            Content-ID: <>

       Levinson               Expires December 31, 1995                [Page 3]

       Internet Draft                                         Multipart/Related

            Content-Type: Application/octet-stream
            Content-Description: The fixed length records
            Content-Transfer-Encoding: base64
            Content-ID: <>



       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;

            Content-Type: Text/x-Okie; charset=iso-8859-1;
            Content-ID: <>
            Content-Description: Document

            This picture was taken by an automatic camera mounted ...
            {image file=cid:<>}
            Now this is an enlargement of the area ...
            {image file=cid:<>}
            Content-Type: image/jpeg
            Content-ID: <>

       Levinson               Expires December 31, 1995                [Page 4]

       Internet Draft                                         Multipart/Related

            Content-Transfer-Encoding: BASE64
            Content-Description: Picture A

            [encoded jpeg image]
            Content-Type: image/jpeg
            Content-ID: <>
            Content-Transfer-Encoding: BASE64
            Content-Description: Picture B

            [encoded jpeg image]

       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/<type>,
       were <type> 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

       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,

       [CFG]       Borenstein, N., "A User Agent Configuration Mechanism For
                   Multimedia Mail Format Information", September 23, 1993, RFC

       [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
       +1 908 389 5550

       Levinson               Expires December 31, 1995                [Page 7]