home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mimesgml-multipart-rel-01.txt < prev    next >
Text File  |  1995-05-31  |  15KB  |  433 lines
  1.  
  2.        MIMESGML Working Group                           E. Levinson
  3.        Internet Draft: Multipart/Related        ACCURATE Info. Sys.
  4.        <draft-ietf-mimesgml-related-01.txt>            May 30, 1995
  5.  
  6.                  The MIME Multipart/Related Content-type
  7.  
  8.        This draft document is being circulated for comment.  Please
  9.        send your comments to the authors or to the ietf-822 mail
  10.        list <ietf-822@822@dimacs.rutgers.edu>.  If consensus is
  11.        reached, this document may be submitted to the RFC editor as
  12.        a Proposed Standard protocol specification for use with
  13.        MIME.
  14.  
  15.        Status of this Memo
  16.  
  17.        This document is an Internet Draft; Internet Drafts are
  18.        working documents of the Internet Engineering Task Force
  19.        (IETF) its Areas, and Working Groups.  Note that other
  20.        groups may also distribute working documents as Internet
  21.        Drafts.
  22.  
  23.        Internet Drafts are draft documents valid for a maximum of
  24.        six months.  They may be updated, replaced, or obsoleted by
  25.        other documents at any time.  It is not appropriate to use
  26.        Internet Drafts as reference material or to cite them other
  27.        than as a "working draft" or  "work in progress".
  28.  
  29.        Please check the abstract listing in each Internet Draft
  30.        directory for the current status of this or any other
  31.        Internet Draft.
  32.  
  33.        Abstract
  34.  
  35.        The Multipart/Related content-type provides a common
  36.        mechanism for representing objects that are aggregates of
  37.        related MIME body parts.  This document defines the
  38.        Multipart/Related content-type and provides examples of its
  39.        use.
  40.  
  41.        1.  Introduction
  42.  
  43.        Several applications of MIME, including MIME-PEM, and MIME-
  44.        Macintosh and other proposals, require multiple body parts
  45.        that make sense only in the aggregate.  The present approach
  46.        to these compound object has been to define specific
  47.        multipart subtypes for each new object.  In keeping with the
  48.        MIME philosophy of having one mechanism to achieve the same
  49.        goal for different purposes, one single mechanism should be
  50.        defined for such aggregate or compound objects.
  51.  
  52.        The Multipart/Related content-type addresses the MIME
  53.        representation of compound objects. Basically, two pieces of
  54.        information are required, the "root" or starting body
  55.        part(s), and an indication of the object type.
  56.  
  57.  
  58.  
  59.        Levinson               Expires December 31, 1995                [Page 1]
  60.  
  61.        Internet Draft                                         Multipart/Related
  62.  
  63.  
  64.        2.  Definition
  65.  
  66.        The following form is copied from RFC 1590, Appendix A.
  67.  
  68.  
  69.        To:  IANA@isi.edu
  70.        Subject:  Registration of new Media Type content-type/subtype
  71.  
  72.        Media Type name:           Multipart
  73.  
  74.        Media subtype name:        Related
  75.  
  76.        Required parameters:       None.
  77.  
  78.        Optional parameters:       Start, an ordered list of content-IDs.
  79.                                   Type, a media type/subtype
  80.  
  81.        Encoding considerations:   1. Multipart content-types cannot have
  82.                                      encodings.
  83.  
  84.        Security considerations:   Depends solely on the referenced type
  85.  
  86.        Published specification:   This document
  87.  
  88.        Person & email address to contact for further information:
  89.                                   Document authors
  90.  
  91.        3.  Intended usage
  92.  
  93.        The Multipart/Related Content-Type is intended for compound
  94.        object consisting of several inter-related body parts.  For
  95.        a Multipart/Related object, proper display cannot be
  96.        achieved by individually displaying the constituent body
  97.        parts.  The actual content-type of the Multipart/Related
  98.        object is specified by the content-type of the "root" or
  99.        starting body parts.  The "start" parameter, if given,
  100.        points, by content-id, to one or more body parts that
  101.        contain the object root.  The default root is the first body
  102.        part within the Multipart/Related body.  The content-type
  103.        header of the first of the start body part may also specify
  104.        additional object information.
  105.  
  106.        The relationships among the body parts of a compound object
  107.        distinguishes it from other object types.  These
  108.        relationships are often represented by links internal to the
  109.        object's components that reference the other components.
  110.        Within a single operating environment the links are often
  111.        file names, within a MIME message content-ids can serve the
  112.        same purpose.  A companion piece [CID] discusses the use of
  113.        content-ids in such objects.
  114.  
  115.        3.1.  The Start Parameter
  116.  
  117.        The start parameter, if given, lists the content-ID of the
  118.  
  119.  
  120.  
  121.        Levinson               Expires December 31, 1995                [Page 2]
  122.  
  123.        Internet Draft                                         Multipart/Related
  124.  
  125.  
  126.        compound object's "root".  The root may consist of one or
  127.        more body parts, in which case the start parameter consists
  128.        of a comma separated list of content-IDs.  In that case the
  129.        first listed body part specifies the object type.
  130.  
  131.        3.2 The Type Parameter
  132.  
  133.        The type parameter must be specified if the start parameter
  134.        is present.  It permits a MIME user agent to determine the
  135.        content-type without reference to the enclosed body part.
  136.  
  137.        Where the content-type of the object root and the one
  138.        indicated by the type parameter disagree, the object root is
  139.        authoritative.  The MIME agent, however, may take action,
  140.        including suppressing the Multipart/Related body, based on
  141.        the indicated content-type.
  142.  
  143.        3.3 Syntax
  144.  
  145.             related-param     = [ ";" "start" "=" msg-id *( "," msg-id ) ]
  146.                                 [ ";" "type"  "=" type "/" subtype ]
  147.                                 ; order independent
  148.  
  149.        Note that the values of both parameters will usually require
  150.        quoting.  Msg-id usually contains the special characters
  151.        "<", ">", "@", and perhaps others.  If msg-id contains
  152.        quoted-strings, those quote marks must be escaped.
  153.        Similarly, the type parameter contains the special character
  154.        "/".
  155.  
  156.        4.  Examples
  157.  
  158.        4.1 Application/X-FixedRecord
  159.  
  160.        The X-FixedRecord content-type consists of two parts: an
  161.        octet-stream and a list of the lengths of each record.  The
  162.        root, which lists the record lengths has one required
  163.        parameter, data-blocks, whose value is the content-id of one
  164.        or more octet-stream body parts.  The body of X-FixedRecord
  165.        consists of a set of INTEGERs in ASCII format, one per line.
  166.        Each INTEGER gives the number of octets from the octet-
  167.        stream body part that constitute the next "record".
  168.  
  169.        The example below, uses a single data block.
  170.  
  171.  
  172.             Content-Type: Multipart/Related; boundary=tiger-lily
  173.                     start="<950120.1133@XIson.com>";
  174.                     type="Application/X-FixedRecord"
  175.  
  176.             --tiger-lily
  177.             Content-Type: Application/X-FixedRecord;
  178.                     data-blocks="<950120.1133@XIson.com>"
  179.             Content-ID: <950120.1132@XIson.com>
  180.  
  181.  
  182.  
  183.        Levinson               Expires December 31, 1995                [Page 3]
  184.  
  185.        Internet Draft                                         Multipart/Related
  186.  
  187.  
  188.             25
  189.             10
  190.             34
  191.             10
  192.             25
  193.             21
  194.             26
  195.             10
  196.             --tiger-lily
  197.             Content-Type: Application/octet-stream
  198.             Content-Description: The fixed length records
  199.             Content-Transfer-Encoding: base64
  200.             Content-ID: <950120.1133@XIson.com>
  201.  
  202.             T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
  203.             BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
  204.             IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
  205.             BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
  206.             YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
  207.             NrIHF1YWNrCkUgSSBFIEkgTwo=
  208.  
  209.             --tiger-lily--
  210.  
  211.        4.2 Text/X-Okie
  212.  
  213.        The Text/X-Okie is an invented markup language permitting
  214.        the inclusion of images with text.  A feature of this
  215.        example is the inclusion of two additional body parts, both
  216.        picture. Tehy are referred to internally by the encapsulated
  217.        document via each picture's body part content-id.  Usage of
  218.        "cid:", as in this example, may be useful for a variety of
  219.        compound objects.  It is not, however, a part of this or the
  220.        Multipart/Related specification.
  221.  
  222.             Content-Type: Multipart/Related; boundary=example;
  223.                     start="<950118.1528@XIson.com>"
  224.                     type="Text/x-Okie"
  225.  
  226.             --example
  227.             Content-Type: Text/x-Okie; charset=iso-8859-1;
  228.                     declaration="<950118.1530@XIson.com>"
  229.             Content-ID: <950118.1528@XIson.com>
  230.             Content-Description: Document
  231.  
  232.             {doc}
  233.             This picture was taken by an automatic camera mounted ...
  234.             {image file=cid:<950118.1532@XIson.com>}
  235.             {para}
  236.             Now this is an enlargement of the area ...
  237.             {image file=cid:<950118:1648@XIson.com>}
  238.             {/doc}
  239.             --example
  240.             Content-Type: image/jpeg
  241.             Content-ID: <950118.1648@XIson.com>
  242.  
  243.  
  244.  
  245.        Levinson               Expires December 31, 1995                [Page 4]
  246.  
  247.        Internet Draft                                         Multipart/Related
  248.  
  249.  
  250.             Content-Transfer-Encoding: BASE64
  251.             Content-Description: Picture A
  252.  
  253.             [encoded jpeg image]
  254.             --example
  255.             Content-Type: image/jpeg
  256.             Content-ID: <950118.1532@XIson.com>
  257.             Content-Transfer-Encoding: BASE64
  258.             Content-Description: Picture B
  259.  
  260.             [encoded jpeg image]
  261.             --example--
  262.  
  263.        5.  User Agent Requirements
  264.  
  265.        Existing MIME-capable mail user agents (MUAs) handle the
  266.        existing media types in a straigth forward manner.  For
  267.        discrete media types (e.g. text, image, etc.) the body of
  268.        the entity can be directly passed to a display process.
  269.        Similarly the existing composite subtypes can be reduced to
  270.        handings one or more discrete types.
  271.  
  272.        Multipart/Related entities require that all constituent body
  273.        parts be available to the display process before it is
  274.        invoked.  The following sections discuss what information
  275.        the proccessing application, called the unpacker, requires.
  276.  
  277.        It is possible that the unpacker will manipulate the
  278.        entities for display and then invoke another process.  Okie,
  279.        above, is an example of this; its unpacker may need to parse
  280.        the document and substitute local file names for the
  281.        originator's file names.  Other applications may just
  282.        require a table showing the correspondence between the local
  283.        file names and the originator's.
  284.  
  285.        5.1 Data Requirments
  286.  
  287.        MIME-capable mail user agents (MUAs) are required to provide
  288.        the unpacker:
  289.  
  290.        (a)  the bodies of the MIME entities, the entity Content-* headers,
  291.  
  292.        (b)  the parameters of the Multipart/Related Content-type header,
  293.  
  294.        (c)  the parameters of the first start entity's Content-type header, and
  295.  
  296.        (d)  the correspondence between each body's local file name, that body's
  297.             header data, and, if present, the body part's content-id.
  298.  
  299.        5.2 Storing Multipart/Related Entities
  300.  
  301.        The Multipart/Related media type will be used for objects that have
  302.        internal linkages between the body parts.  When the objects are stored
  303.        the linkages may require processing by the unpacker.
  304.  
  305.  
  306.  
  307.        Levinson               Expires December 31, 1995                [Page 5]
  308.  
  309.        Internet Draft                                         Multipart/Related
  310.  
  311.  
  312.        5.3 Recursion
  313.  
  314.        MIME is a recursive structure.  Hence one must expect a
  315.        Multipart/Related entity to contain other Multipart/Related entities.
  316.        When a Multipart/Related entity is being processed for display or
  317.        storage, any enclosed Multipart/Related entities shall be processed as
  318.        though they were being stored.
  319.  
  320.        5.5 Configuration Considerations
  321.  
  322.        It is suggested that MUAs that use configuration mechanisms, see [CFG]
  323.        for an example, refer to Multipart/Related as Multipart/Related/<type>,
  324.        were <type> is the value of the underlying content-type.
  325.  
  326.        MIME-capable mail user agents (MUAs) may suppress processing of
  327.        Multipart/Related body parts whose underlying content-type it cannot
  328.        display or process.  (The underlying content-type is the content-type of
  329.        the start body part, or, if given, the value of the type parameter.)
  330.        Alternately, the MUA may treat the Multipart/Related media type as
  331.        Multipart/Mixed.
  332.  
  333.        6.  Security considerations
  334.  
  335.        Security considerations relevant to Multipart/Related are identical to
  336.        those of the underlying content-type.
  337.  
  338.        7.  Acknowledgments
  339.  
  340.        This proposal is the result of conversations the author has had with
  341.        many people.  In particular, Harald A. Alvestrand and Ned Freed, pro-
  342.        vided both encouragement and guidance.  The author, however, take full
  343.        responsibility for all errors contained in this document.
  344.  
  345.        8.  References
  346.  
  347.  
  348.        [822]       Crocker, D., "Standard for the Format of ARPA Internet Text
  349.                    Messages", August 1982, University of Delaware, RFC 822.
  350.  
  351.        [CID]       Levinson, E., "CID: The Content-ID Uniform Resource Loca-
  352.                    tor", work in progress, ftp://ds.internic.net/internet-
  353.                    drafts/draft-levinson-cid-00.txt.
  354.  
  355.        [CFG]       Borenstein, N., "A User Agent Configuration Mechanism For
  356.                    Multimedia Mail Format Information", September 23, 1993, RFC
  357.                    1524
  358.  
  359.        [MIME]      Borenstein, N. and Freed, N., "MIME (Multipurpose Internet
  360.                    Mail Extensions): Mechanisms for Specifying and Describing
  361.                    the Format of Internet Message Bodies", June 1992, RFC 1341.
  362.  
  363.        9.  Author's address
  364.  
  365.        Edward Levinson
  366.  
  367.  
  368.  
  369.        Levinson               Expires December 31, 1995                [Page 6]
  370.  
  371.        Internet Draft                                         Multipart/Related
  372.  
  373.  
  374.        Accurate Information Systems, Inc.
  375.        2 Industrial Way
  376.        Eatontown, NJ  07724-2265
  377.        USA
  378.        +1 908 389 5550
  379.        <ELevinson@Accurate.com>
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.        Levinson               Expires December 31, 1995                [Page 7]
  432.  
  433.