[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

       Network Working Group                Harald Tveit Alvestrand
       Internet Draft: Multipart/Related                    UNINETT
       <draft-levinson-multipart-related-00.txt>    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 <ietf-822@822@dimacs.rutgers.edu>.  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 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
                                  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
            Content-Type: Application/X-FixedRecord;
            Content-ID: <950120.1132@XIson.com>
            Content-Type: Application/octet-stream
            Content-Description: The fixed length records
            Content-Transfer-Encoding: base64
            Content-ID: <950120.1133@XIson.com>
       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
            Content-Type: Multipart/Related; boundary=example;
       Levinson and Alvestrand  Expires July 31, 1995                  [Page 4]

       Internet Draft                                         Multipart/Related
            Content-Type: Text/x-sgml; charset=iso-8859-1;
            Content-ID: <950118.1528@XIson.com>
            Content-Description: Document
            <!DOCTYPE doc PUBLIC "-//IETF ..." [
            <!NOTATION jpeg SYSTEM "image/jpeg">
            <!ENTITY picture SYSTEM "cid:950118.1532@XIson.com" NDATA jpeg>
            ] >
            Content-Type: Application/x-sgml; charset=iso-8859-1
            Content-ID: <950118.1530@XIson.com>
            Content-Description: An sgml declaration
            <!SGML "ISO 8879-1986" ... >
            Content-Type: image/jpeg
            Content-ID: <950118.1532@XIson.com>
            Content-Transfer-Encoding: BASE64
            Content-Description: Picture
            [encoded jpeg image]
       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-
       9.  Author's address
       Edward Levinson
       Accurate Information Systems, Inc.
       2 Industrial Way
       Eatontown, NJ  07724-2265
       +1 908 389 5550
       Harald T. Alvestrand
       P.O.Box 6883 Elgeseter
       N-7002 Trondheim
       Levinson and Alvestrand  Expires July 31, 1995                  [Page 6]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/