home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1872 < prev    next >
Text File  |  1995-12-19  |  16KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        E. Levinson
  8. Request for Comments: 1872            Accurate Information Systems, Inc.
  9. Category: Experimental                                     December 1995
  10.  
  11.  
  12.                 The MIME Multipart/Related Content-type
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The Multipart/Related content-type provides a common mechanism for
  24.    representing objects that are aggregates of related MIME body parts.
  25.    This document defines the Multipart/Related content-type and provides
  26.    examples of its use.
  27.  
  28. 1.  Introduction
  29.  
  30.    Several applications of MIME, including MIME-PEM, and MIME-Macintosh
  31.    and other proposals, require multiple body parts that make sense only
  32.    in the aggregate.  The present approach to these compound objects has
  33.    been to define specific multipart subtypes for each new object.  In
  34.    keeping with the MIME philosophy of having one mechanism to achieve
  35.    the same goal for different purposes, this document describes a
  36.    single mechanism for such aggregate or compound objects.
  37.  
  38.    The Multipart/Related content-type addresses the MIME representation
  39.    of compound objects.  The object is categorized by a "type"
  40.    parameter.  Additional parameters are provided to indicate a specific
  41.    starting body part or root and auxiliary information which may be
  42.    required when unpacking or processing the object.
  43.  
  44.    Responsibility for the display or processing of a Multipart/Related's
  45.    constituent entities rests with the application that handles the
  46.    compound object.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Levinson                      Experimental                      [Page 1]
  59.  
  60. RFC 1872                   Multipart/Related               December 1995
  61.  
  62.  
  63. 2.  Multipart/Related Registration Information
  64.  
  65.    The following form is copied from RFC 1590, Appendix A.
  66.  
  67.    To:  IANA@isi.edu
  68.    Subject:  Registration of new Media Type content-type/subtype
  69.  
  70.    Media Type name:           Multipart
  71.  
  72.    Media subtype name:        Related
  73.  
  74.    Required parameters:       Type, a media type/subtype.
  75.  
  76.    Optional parameters:       Start, a content-id.
  77.                               Start-info, a string or content-id list.
  78.  
  79.    Encoding considerations:   Multipart content-types cannot have
  80.                               encodings.
  81.  
  82.    Security considerations:   Depends solely on the referenced type.
  83.  
  84.    Published specification:   This document.
  85.  
  86.    Person & email address to contact for further information:
  87.                               Edward Levinson
  88.                               Accurate Information Systems, Inc.
  89.                               2 Industrial Way
  90.                               Eatontown, NJ 07724
  91.                               +1 908 389 5550
  92.                               +1 908 389 5556 (fax)
  93.                               ELevinson@Accurate.com
  94.  
  95. 3.  Intended usage
  96.  
  97.    The Multipart/Related media type is intended for compound objects
  98.    consisting of several inter-related body parts.  For a
  99.    Multipart/Related object, proper display cannot be achieved by
  100.    individually displaying the constituent body parts.  The content-type
  101.    of the Multipart/Related object is specified by the type parameter.
  102.    The "start" parameter, if given, points, via a content-ID, to the
  103.    body part that contains the object root.  The default root is the
  104.    first body part within the Multipart/Related body.
  105.  
  106.    The relationships among the body parts of a compound object
  107.    distinguishes it from other object types.  These relationships are
  108.    often represented by links internal to the object's components that
  109.    reference the other components.  Within a single operating
  110.    environment the links are often file names, such links may be
  111.  
  112.  
  113.  
  114. Levinson                      Experimental                      [Page 2]
  115.  
  116. RFC 1872                   Multipart/Related               December 1995
  117.  
  118.  
  119.    represented within a MIME message using content-IDs or the value of
  120.    some other "Content-" header.
  121.  
  122. 3.1.  The Type Parameter
  123.  
  124.    The type parameter must be specified and its value is the MIME media
  125.    type of the root body part.  It permits a MIME user agent to
  126.    determine the content-type without reference to the enclosed body
  127.    part.  If the value of the type parameter and the root body part's
  128.    content-type differ then the User Agent's behavior is undefined.
  129.  
  130.    Note: Constraining the "type" parameter's value to an existing media
  131.    type allows the appropriate processing to be identified without
  132.    creating yet another hierarchy of registered types.  A possible
  133.    default action would have the MIME mail User Agent (MUA) to display
  134.    the "start" entity alone when it could process the media type as a
  135.    basic type but not as Multipart/Related.
  136.  
  137. 3.2.  The Start Parameter
  138.  
  139.    The start parameter, if given, is the content-ID of the compound
  140.    object's root.  If not present the root is the first body part in the
  141.    Multipart/Related entity.  The root is the element the application
  142.    processes first.
  143.  
  144.    In the case of a Multipart/Alternative body part containing several
  145.    entities with identical content-IDs the start entity should be
  146.    selected using the Multipart/Alternative rules.
  147.  
  148.    Note: The "start" parameter allows for types in which the root
  149.    element gets generated by the sending application, perhaps on the
  150.    fly.  Such an application can create the "start" content-id when
  151.    processing begins and then insert the body part when it is complete.
  152.  
  153. 3.3.  The Start-Info Parameter
  154.  
  155.    Additional information can be provided to an application by the
  156.    start-info parameter.  It contains either a string or points, via a
  157.    content-ID, to another MIME entity in the message.  A typical use
  158.    might be to provide additional command line parameters or a MIME
  159.    entity giving auxiliary information for processing the compound
  160.    object.
  161.  
  162.    Applications that use Multipart/Related must specify the
  163.    interpretation of start-info.  User Agents shall provide the
  164.    parameter's value to the processing application.  Processes can
  165.    distinguish a start-info reference from a token or quoted-string by
  166.    examining the first non-white-space character, "<" indicates a
  167.  
  168.  
  169.  
  170. Levinson                      Experimental                      [Page 3]
  171.  
  172. RFC 1872                   Multipart/Related               December 1995
  173.  
  174.  
  175.    content-id reference.
  176.  
  177. 3.4.  Syntax
  178.  
  179.      related-param    := [ ";" "start" "=" cid ]
  180.                          [ ";" "start-info"  "="
  181.                            ( cid-list / value ) ]
  182.                          [ ";" "type"  "=" type "/" subtype ]
  183.                          ; order independent
  184.  
  185.      cid-list        := cid cid-list
  186.  
  187.      cid             := msg-id     ; c.f. [822]
  188.  
  189.      value           := token / quoted-string    ; c.f. [MIME]
  190.                              ; value cannot begin with "<"
  191.  
  192.    Note that the parameter values will usually require quoting.  Msg-id
  193.    contains the special characters "<", ">", "@", and perhaps other
  194.    special characters.  If msg-id contains quoted-strings, those quote
  195.    marks must be escaped.  Similarly, the type parameter contains the
  196.    special character "/".
  197.  
  198. 4.  Examples
  199.  
  200. 4.1 Application/X-FixedRecord
  201.  
  202.    The X-FixedRecord content-type consists of one or more octet- streams
  203.    and a list of the lengths of each record.  The root, which lists the
  204.    record lengths of each record within the streams.  The record length
  205.    list, type Application/X-FixedRecord, consists of a set of INTEGERs
  206.    in ASCII format, one per line.  Each INTEGER gives the number of
  207.    octets from the octet-stream body part that constitute the next
  208.    "record".
  209.  
  210.    The example below, uses a single data block which the sender
  211.    processes on the fly to generate the record length list.
  212.    Consequently the list appears after the data.
  213.  
  214.      Content-Type: Multipart/Related; boundary=example-1
  215.              start="<950120.aaCC@XIson.com>";
  216.              type="Application/X-FixedRecord"
  217.              start-info="-o ps"
  218.  
  219.      --example-1
  220.      Content-Type: Application/octet-stream
  221.      Content-Description: The fixed length records
  222.      Content-Transfer-Encoding: base64
  223.  
  224.  
  225.  
  226. Levinson                      Experimental                      [Page 4]
  227.  
  228. RFC 1872                   Multipart/Related               December 1995
  229.  
  230.  
  231.      Content-ID: <950120.aaCB@XIson.com>
  232.  
  233.      T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
  234.      BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
  235.      IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
  236.      BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
  237.      YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
  238.      NrIHF1YWNrCkUgSSBFIEkgTwo=
  239.      --example-1
  240.      Content-Type: Application/X-FixedRecord
  241.      Content-ID: <950120.aaCC@XIson.com>
  242.  
  243.      25
  244.      10
  245.      34
  246.      10
  247.      25
  248.      21
  249.      26
  250.      10
  251.      --example-1--
  252.  
  253. 4.2 Text/X-Okie
  254.  
  255. The Text/X-Okie is an invented markup language, similar to
  256. HTML, that permits the inclusion of images with text.  A
  257. feature of this example is the inclusion of two additional
  258. body parts, both picture. They are referred to internally by
  259. the encapsulated document via each picture's body part
  260. content-ID.  Usage of "cid:", as in this example, may be
  261. useful for a variety of compound objects.  It is not, however,
  262. a part of the Multipart/Related specification.
  263.  
  264.      Content-Type: Multipart/Related; boundary=example-2;
  265.              start="<950118.AEBH@XIson.com>"
  266.              type="Text/x-Okie"
  267.  
  268.      --example-2
  269.      Content-Type: Text/x-Okie; charset=iso-8859-1;
  270.              declaration="<950118.AEB0@XIson.com>"
  271.      Content-ID: <950118.AEBH@XIson.com>
  272.      Content-Description: Document
  273.  
  274.      {doc}
  275.      This picture was taken by an automatic camera mounted ...
  276.      {image file=cid:950118.AECB@XIson.com}
  277.      {para}
  278.      Now this is an enlargement of the area ...
  279.  
  280.  
  281.  
  282. Levinson                      Experimental                      [Page 5]
  283.  
  284. RFC 1872                   Multipart/Related               December 1995
  285.  
  286.  
  287.      {image file=cid:950118.AFDH@XIson.com}
  288.      {/doc}
  289.      --example-2
  290.      Content-Type: image/jpeg
  291.      Content-ID: <950118.AFDH@XIson.com>
  292.      Content-Transfer-Encoding: BASE64
  293.      Content-Description: Picture A
  294.  
  295.      [encoded jpeg image]
  296.      --example-2
  297.      Content-Type: image/jpeg
  298.      Content-ID: <950118.AECB@XIson.com>
  299.      Content-Transfer-Encoding: BASE64
  300.      Content-Description: Picture B
  301.  
  302.      [encoded jpeg image]
  303.      --example-1--
  304.  
  305. 5.  User Agent Requirements
  306.  
  307.    User agents that do not recognize Multipart/Related shall, in
  308.    accordance with [MIME], treat the entire entity as Multipart/Mixed.
  309.    MIME User Agents that recognize Multipart/Related entities but are
  310.    unable to process the given type shall either suppress the entire
  311.    Multipart/Related body part or process the root alone.  In either
  312.    case the user should be notified of the MUA's action.
  313.  
  314.    Handling Multipart/Related differs from other media types in that
  315.    processing cannot be reduced to handling the individual entities.
  316.    Existing media types are handled by MIME-capable MUAs handle in a
  317.    straightforward manner.  For basic media types (e.g., text, image,
  318.    etc.) the body of the entity can be directly passed to a display
  319.    process.  Composite media types can be reduced to handing one or more
  320.    discrete types.
  321.  
  322.    Multipart/Related provides an irreducible composite media type.
  323.  
  324.    The following sections discuss what information the processing
  325.    application requires.
  326.  
  327.    It is possible that an application specific "receiving agent" will
  328.    manipulate the entities, after initial processing by the MIME User
  329.    Agent, prior to invoking actual application process.  From the
  330.    viewpoint of the MUA, the receiving agent is the application.  Okie,
  331.    above, demonstrates this; it may need a receiving agent to parse the
  332.    document and substitute local file names for the originator's file
  333.    names.  Other applications may just require a table showing the
  334.    correspondence between the local file names and the originator's.
  335.  
  336.  
  337.  
  338. Levinson                      Experimental                      [Page 6]
  339.  
  340. RFC 1872                   Multipart/Related               December 1995
  341.  
  342.  
  343.    The receiving agent takes responsibility any for such processing.
  344.  
  345. 5.1 Data Requirements
  346.  
  347.    MIME-capable MUAs are required to provide the application:
  348.  
  349.    (a)  the bodies of the MIME entities and the entity Content-*
  350.         headers,
  351.  
  352.    (b)  the parameters of the Multipart/Related Content-type
  353.         header, and
  354.  
  355.    (c)  the correspondence between each body's local file name,
  356.         that body's header data, and, if present, the body part's
  357.         content-ID.
  358.  
  359. 5.2 Storing Multipart/Related Entities
  360.  
  361.    The Multipart/Related media type will be used for objects that have
  362.    internal linkages between the body parts.  When the objects are
  363.    stored the linkages may require processing by the application or its
  364.    receiving agent.
  365.  
  366. 5.3 Recursion
  367.  
  368.    MIME is a recursive structure.  Hence one must expect a
  369.    Multipart/Related entity to contain other Multipart/Related entities.
  370.    When a Multipart/Related entity is being processed for display or
  371.    storage, any enclosed Multipart/Related entities shall be processed
  372.    as though they were being stored.  It shall be the responsibility of
  373.    the application handling the outermost Multipart/Related to insure
  374.    the appropriate processing of embedded Multipart/Related entities.
  375.  
  376. 5.5 Configuration Considerations
  377.  
  378.    It is suggested that MUAs that use configuration mechanisms, see
  379.    [CFG] for an example, refer to Multipart/Related as
  380.    Multipart/Related/<type>, were <type> is the value of the "type"
  381.    parameter.
  382.  
  383. 6.  Security Considerations
  384.  
  385.    Security considerations relevant to Multipart/Related are identical
  386.    to those of the underlying content-type.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Levinson                      Experimental                      [Page 7]
  395.  
  396. RFC 1872                   Multipart/Related               December 1995
  397.  
  398.  
  399. 7.  Acknowledgments
  400.  
  401.    This proposal is the result of conversations the author has had with
  402.    many people.  In particular, similar work was described by Harald A.
  403.    Alvestrand (early drafts of Multipart/Related), Dave Crocker
  404.    (Multipart/Families), and Keith Moore (Multipart/References). In
  405.    addition, James Clark, Charles Goldfarb, Gary Houston, Ned Freed, Ray
  406.    Moody, and Don Stinchfield, provided both encouragement and
  407.    invaluable help.  The author, however, take full responsibility for
  408.    all errors contained in this document.
  409.  
  410. 8.  References
  411.  
  412.    [822]       Crocker, D., "Standard for the Format of ARPA
  413.                Internet Text Messages", STD 11, RFC 822, UDEL,
  414.                August 1982.
  415.  
  416.    [CFG]       Borenstein, N., "A User Agent Configuration
  417.                Mechanism For Multimedia Mail Format Information",
  418.                RFC 1524, Bellcore, September 1993.
  419.  
  420.    [MIME]      Borenstein, N. and and N. Freed, "MIME (Multipurpose
  421.                Internet Mail Extensions) Part One: Mechanisms for
  422.                Specifying and Describing the Format of Internet Message
  423.                Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
  424.  
  425. 9.  Author's Address
  426.  
  427.    Edward Levinson
  428.    Accurate Information Systems, Inc.
  429.    2 Industrial Way
  430.    Eatontown, NJ  07724-2265
  431.    USA
  432.  
  433.    Phone: +1 908 389 5550
  434.    EMail: ELevinson@Accurate.com
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Levinson                      Experimental                      [Page 8]
  451.  
  452.