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-mhtml-rel-v2-00.txt < prev    next >
Text File  |  1997-09-09  |  18KB  |  506 lines
  1. MIMEHTML Working Group                                       E. Levinson
  2. draft-ietf-mhtml-rel-v2-00.txt
  3. IETF Status: To replace RFC 2112 as a new Proposed Standard
  4. Expires: March 1998                                       September 1997
  5.  
  6.  
  7.                  The MIME Multipart/Related Content-type
  8.  
  9.  
  10.    This draft document is being circulated for comment.  Please send
  11.    your comments to the authors or to the mimesgml mail list
  12.    mhtml@segate.sunet.se.
  13.  
  14.    Status of this Memo
  15.  
  16.    This document is an Internet Draft; Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF) its Areas,
  18.    and Working Groups.  Note that other groups may also distribute
  19.    working documents as Internet Drafts.
  20.  
  21.    Internet Drafts are draft documents valid for a maximum of six
  22.    months.  They may be updated, replaced, or obsoleted by other
  23.    documents at any time.  It is not appropriate to use Internet Drafts
  24.    as reference material or to cite them other than as a "working draft"
  25.    or  "work in progress".
  26.  
  27.    Please check the abstract listing in each Internet Draft directory
  28.    for the current status of this or any other Internet Draft.
  29.  
  30. Abstract
  31.  
  32.    The Multipart/Related content-type provides a common mechanism for
  33.    representing objects that are aggregates of related MIME body parts.
  34.    This document defines the Multipart/Related content-type and provides
  35.    examples of its use.
  36.  
  37. 0.  Changes from previous draft (RFC 2112)
  38.  
  39.    Corrected cid urls to conform to RFC 2111; the angle brackets were
  40.    removed.
  41.  
  42. 1.  Introduction
  43.  
  44.    Several applications of MIME, including MIME-PEM, and MIME-Macintosh
  45.    and other proposals, require multiple body parts that make sense only
  46.    in the aggregate.  The present approach to these compound objects has
  47.    been to define specific multipart subtypes for each new object.  In
  48.    keeping with the MIME philosophy of having one mechanism to achieve
  49.    the same goal for different purposes, this document describes a
  50.    single mechanism for such aggregate or compound objects.
  51.  
  52.  
  53.  
  54.  
  55. Levinson                  Expires January 1998                  [Page 1]
  56.  
  57. Internet Draft              Multipart/Related                 July, 1997
  58.  
  59.  
  60.    The Multipart/Related content-type addresses the MIME representation
  61.    of compound objects.  The object is categorized by a "type"
  62.    parameter.  Additional parameters are provided to indicate a specific
  63.    starting body part or root and auxiliary information which may be
  64.    required when unpacking or processing the object.
  65.  
  66.    Multipart/Related MIME entities may contain Content-Disposition
  67.    headers that provide suggestions for the storage and display of a
  68.    body part.  Multipart/Related processing takes precedence over
  69.    Content-Disposition; the interaction between them is discussed in
  70.    section 4.
  71.  
  72.    Responsibility for the display or processing of a Multipart/Related's
  73.    constituent entities rests with the application that handles the
  74.    compound object.
  75.  
  76. 2.  Multipart/Related Registration Information
  77.  
  78.    The following form is copied from RFC 1590, Appendix A.
  79.  
  80.  
  81.      To:  IANA@isi.edu
  82.      Subject:  Registration of new Media Type content-type/subtype
  83.  
  84.      Media Type name:           Multipart
  85.  
  86.      Media subtype name:        Related
  87.  
  88.      Required parameters:       Type, a media type/subtype.
  89.  
  90.      Optional parameters:       Start
  91.                                 Start-info
  92.  
  93.      Encoding considerations:   Multipart content-types cannot have
  94.                                 encodings.
  95.  
  96.      Security considerations:   Depends solely on the referenced type.
  97.  
  98.      Published specification:   RFC-REL (this document).
  99.  
  100.      Person & email address to contact for further information:
  101.                                 Edward Levinson
  102.                                 47 Clive Street
  103.                                 Metuchen, NJ  08840-1060
  104.                                 +1 908 494 1606
  105.                                 XIson@cnj.digex.net
  106.  
  107. 3.  Intended usage
  108.  
  109.  
  110.  
  111. Levinson                  Expires January 1998                  [Page 2]
  112.  
  113. Internet Draft              Multipart/Related                 July, 1997
  114.  
  115.  
  116.    The Multipart/Related media type is intended for compound objects
  117.    consisting of several inter-related body parts.  For a
  118.    Multipart/Related object, proper display cannot be achieved by
  119.    individually displaying the constituent body parts.  The content-type
  120.    of the Multipart/Related object is specified by the type parameter.
  121.    The "start" parameter, if given, points, via a content-ID, to the
  122.    body part that contains the object root.  The default root is the
  123.    first body part within the Multipart/Related body.
  124.  
  125.    The relationships among the body parts of a compound object
  126.    distinguishes it from other object types.  These relationships are
  127.    often represented by links internal to the object's components that
  128.    reference the other components.  Within a single operating
  129.    environment the links are often file names, such links may be
  130.    represented within a MIME message using content-IDs or the value of
  131.    some other "Content-" headers.
  132.  
  133. 3.1.  The Type Parameter
  134.  
  135.    The type parameter must be specified and its value is the MIME media
  136.    type of the "root" body part.  It permits a MIME user agent to
  137.    determine the content-type without reference to the enclosed body
  138.    part.  If the value of the type parameter and the root body part's
  139.    content-type differ then the User Agent's behavior is undefined.
  140.  
  141. 3.2.  The Start Parameter
  142.  
  143.    The start parameter, if given, is the content-ID of the compound
  144.    object's "root".  If not present the "root" is the first body part in
  145.    the Multipart/Related entity.  The "root" is the element the
  146.    applications processes first.
  147.  
  148. 3.3.  The Start-Info Parameter
  149.  
  150.    Additional information can be provided to an application by the
  151.    start-info parameter.  It contains either a string or points, via a
  152.    content-ID, to another MIME entity in the message.  A typical use
  153.    might be to provide additional command line parameters or a MIME
  154.    entity giving auxiliary information for processing the compound
  155.    object.
  156.  
  157.    Applications that use Multipart/Related must specify the
  158.    interpretation of start-info.  User Agents shall provide the
  159.    parameter's value to the processing application.  Processes can
  160.    distinguish a start-info reference from a token or quoted-string by
  161.    examining the first non-white-space character, "<" indicates a
  162.    reference.
  163.  
  164.  
  165.  
  166.  
  167. Levinson                  Expires January 1998                  [Page 3]
  168.  
  169. Internet Draft              Multipart/Related                 July, 1997
  170.  
  171.  
  172. 3.4.  Syntax
  173.  
  174.      related-param   := [ ";" "start" "=" cid ]
  175.                         [ ";" "start-info"  "="
  176.                            ( cid-list / value ) ]
  177.                         [ ";" "type"  "=" type "/" subtype ]
  178.                         ; order independent
  179.  
  180.      cid-list        := cid cid-list
  181.  
  182.      cid             := msg-id     ; c.f. [822]
  183.  
  184.      value           := token / quoted-string    ; c.f. [MIME]
  185.                            ; value cannot begin with "<"
  186.  
  187.    Note that the parameter values will usually require quoting.  Msg-id
  188.    contains the special characters "<", ">", "@", and perhaps other
  189.    special characters.  If msg-id contains quoted-strings, those quote
  190.    marks must be escaped.  Similarly, the type parameter contains the
  191.    special character "/".
  192.  
  193. 4.  Handling Content-Disposition Headers
  194.  
  195.    Content-Disposition Headers [DISP] suggest presentation styles for
  196.    MIME body parts.  [DISP] describes two presentation styles, called
  197.    the disposition type, INLINE and ATTACHMENT.  These, used within a
  198.    multipart entity, allow the sender to suggest presentation
  199.    information.  [DISP] also provides for an optional storage (file)
  200.    name.  Content-Disposition headers could appear in one or more body
  201.    parts contained within a Multipart/Related entity.
  202.  
  203.    Using Content-Disposition headers in addition to Multipart/Related
  204.    provides presentation information to User Agents that do not
  205.    recognize Multipart/Related.  They will treat the multipart as
  206.    Multipart/Mixed and they may find the Content-Disposition information
  207.    useful.
  208.  
  209.    With Multipart/Related however, the application processing the
  210.    compound object determines the presentation style for all the
  211.    contained parts.  In that context the Content-Disposition header
  212.    information is redundant or even misleading.  Hence, User Agents that
  213.    understand Multipart/Related shall ignore the disposition type within
  214.    a Multipart/Related body part.
  215.  
  216.    It may be possible for a User Agent capable of handling both
  217.    Multipart/Related and Content-Disposition headers to provide the
  218.    invoked application the Content-Disposition header's optional
  219.    filename parameter to the Multipart/Related.  The use of that
  220.  
  221.  
  222.  
  223. Levinson                  Expires January 1998                  [Page 4]
  224.  
  225. Internet Draft              Multipart/Related                 July, 1997
  226.  
  227.  
  228.    information will depend on the specific application and should be
  229.    specified when describing the handling of the corresponding compound
  230.    object.  Such descriptions would be appropriate in an RFC registering
  231.    that object's media type.
  232.  
  233. 5.  Examples
  234.  
  235. 5.1 Application/X-FixedRecord
  236.  
  237.    The X-FixedRecord content-type consists of one or more octet-streams
  238.    and a list of the lengths of each record.  The root, which lists the
  239.    record lengths of each record within the streams.  The record length
  240.    list, type Application/X-FixedRecord, consists of a set of INTEGERs
  241.    in ASCII format, one per line.  Each INTEGER gives the number of
  242.    octets from the octet-stream body part that constitute the next
  243.    "record".
  244.  
  245.    The example below, uses a single data block.
  246.  
  247.  
  248.      Content-Type: Multipart/Related; boundary=example-1
  249.              start="<950120.aaCC@XIson.com>";
  250.              type="Application/X-FixedRecord"
  251.              start-info="-o ps"
  252.  
  253.      --example-1
  254.      Content-Type: Application/X-FixedRecord
  255.      Content-ID: <950120.aaCC@XIson.com>
  256.  
  257.      25
  258.      10
  259.      34
  260.      10
  261.      25
  262.      21
  263.      26
  264.      10
  265.      --example-1
  266.      Content-Type: Application/octet-stream
  267.      Content-Description: The fixed length records
  268.      Content-Transfer-Encoding: base64
  269.      Content-ID: <950120.aaCB@XIson.com>
  270.  
  271.      T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
  272.      BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
  273.      IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
  274.      BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
  275.      YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
  276.  
  277.  
  278.  
  279. Levinson                  Expires January 1998                  [Page 5]
  280.  
  281. Internet Draft              Multipart/Related                 July, 1997
  282.  
  283.  
  284.      NrIHF1YWNrCkUgSSBFIEkgTwo=
  285.  
  286.      --example-1--
  287.  
  288. 5.2 Text/X-Okie
  289.  
  290.    The Text/X-Okie is an invented markup language permitting the
  291.    inclusion of images with text.  A feature of this example is the
  292.    inclusion of two additional body parts, both picture. They are
  293.    referred to internally by the encapsulated document via each
  294.    picture's body part content-ID.  Usage of "cid:", as in this example,
  295.    may be useful for a variety of compound objects.  It is not, however,
  296.    a part of the Multipart/Related specification.
  297.  
  298.      Content-Type: Multipart/Related; boundary=example-2;
  299.              start="<950118.AEBH@XIson.com>"
  300.              type="Text/x-Okie"
  301.  
  302.      --example-2
  303.      Content-Type: Text/x-Okie; charset=iso-8859-1;
  304.              declaration="<950118.AEB0@XIson.com>"
  305.      Content-ID: <950118.AEBH@XIson.com>
  306.      Content-Description: Document
  307.  
  308.      {doc}
  309.      This picture was taken by an automatic camera mounted ...
  310.      {image file=cid:950118.AECB@XIson.com}
  311.      {para}
  312.      Now this is an enlargement of the area ...
  313.      {image file=cid:950118:AFDH@XIson.com}
  314.      {/doc}
  315.      --example-2
  316.      Content-Type: image/jpeg
  317.      Content-ID: <950118.AFDH@XIson.com>
  318.      Content-Transfer-Encoding: BASE64
  319.      Content-Description: Picture A
  320.  
  321.      [encoded jpeg image]
  322.      --example-2
  323.      Content-Type: image/jpeg
  324.      Content-ID: <950118.AECB@XIson.com>
  325.      Content-Transfer-Encoding: BASE64
  326.      Content-Description: Picture B
  327.  
  328.      [encoded jpeg image]
  329.      --example-2--
  330.  
  331. 5.3 Content-Disposition
  332.  
  333.  
  334.  
  335. Levinson                  Expires January 1998                  [Page 6]
  336.  
  337. Internet Draft              Multipart/Related                 July, 1997
  338.  
  339.  
  340.    In the above example each image body part could also have a Content-
  341.    Disposition header.  For example,
  342.  
  343.      ...
  344.      --example-2
  345.      Content-Type: image/jpeg
  346.      Content-ID: <950118.AECB@XIson.com>
  347.      Content-Transfer-Encoding: BASE64
  348.      Content-Description: Picture B
  349.      Content-Disposition: INLINE
  350.  
  351.      [encoded jpeg image]
  352.      --example-2--
  353.  
  354.    User Agents that recognize Multipart/Related will ignore the Content-
  355.    Disposition header's disposition type.  Other User Agents will
  356.    process the Multipart/Related as Multipart/Mixed and may make use of
  357.    that header's information.
  358.  
  359. 6.  User Agent Requirements
  360.  
  361.    User agents that do not recognize Multipart/Related shall, in
  362.    accordance with [MIME], treat the entire entity as Multipart/Mixed.
  363.    MIME User Agents that do recognize Multipart/Related entities but are
  364.    unable to process the given type should give the user the option of
  365.    suppressing the entire Multipart/Related body part shall be.
  366.  
  367.    Existing MIME-capable mail user agents (MUAs) handle the existing
  368.    media types in a straightforward manner.  For discrete media types
  369.    (e.g. text, image, etc.) the body of the entity can be directly
  370.    passed to a display process.  Similarly the existing composite
  371.    subtypes can be reduced to handing one or more discrete types.
  372.    Handling Multipart/Related differs in that processing cannot be
  373.    reduced to handling the individual entities.
  374.  
  375.    The following sections discuss what information the processing
  376.    application requires.
  377.  
  378.    It is possible that an application specific "receiving agent" will
  379.    manipulate the entities for display prior to invoking actual
  380.    application process.  Okie, above, is an example of this; it may need
  381.    a receiving agent to parse the document and substitute local file
  382.    names for the originator's file names.  Other applications may just
  383.    require a table showing the correspondence between the local file
  384.    names and the originator's.  The receiving agent takes responsibility
  385.    for such processing.
  386.  
  387. 6.1 Data Requirements
  388.  
  389.  
  390.  
  391. Levinson                  Expires January 1998                  [Page 7]
  392.  
  393. Internet Draft              Multipart/Related                 July, 1997
  394.  
  395.  
  396.    MIME-capable mail user agents (MUAs) are required to provide the
  397.    application:
  398.  
  399.    (a) the bodies of the MIME entities and the entity Content-* headers,
  400.  
  401.    (b) the parameters of the Multipart/Related Content-type header, and
  402.  
  403.    (c) the correspondence between each body's local file name, that
  404.        body's header data, and, if present, the body part's content-ID.
  405.  
  406. 6.2 Storing Multipart/Related Entities
  407.  
  408.    The Multipart/Related media type will be used for objects that have
  409.    internal linkages between the body parts.  When the objects are
  410.    stored the linkages may require processing by the application or its
  411.    receiving agent.
  412.  
  413. 6.3 Recursion
  414.  
  415.    MIME is a recursive structure.  Hence one must expect a Multi-
  416.    part/Related entity to contain other Multipart/Related entities.
  417.    When a Multipart/Related entity is being processed for display or
  418.    storage, any enclosed Multipart/Related entities shall be processed
  419.    as though they were being stored.
  420.  
  421. 6.4 Configuration Considerations
  422.  
  423.    It is suggested that MUAs that use configuration mechanisms, see
  424.    [CFG] for an example, refer to Multipart/Related as Multi-
  425.    part/Related/<type>, were <type> is the value of the "type" parame-
  426.    ter.
  427.  
  428. 7.  Security considerations
  429.  
  430.    Security considerations relevant to Multipart/Related are identical
  431.    to those of the underlying content-type.
  432.  
  433. 8.  Acknowledgments
  434.  
  435.    This proposal is the result of conversations the author has had with
  436.    many people.  In particular, Harald A. Alvestrand, James Clark,
  437.    Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinch-
  438.    field, provided both encouragement and invaluable help.  The author,
  439.    however, take full responsibility for all errors contained in this
  440.    document.
  441.  
  442. 9.  References
  443.  
  444.  
  445.  
  446.  
  447. Levinson                  Expires January 1998                  [Page 8]
  448.  
  449. Internet Draft              Multipart/Related                 July, 1997
  450.  
  451.  
  452. [822]       Crocker, D., "Standard for the Format of ARPA Internet Text
  453.             Messages", August 1982, University of Delaware, RFC 822.
  454.  
  455. [CID]       E. Levinson, J. Clark, "Message/External-Body Content-ID
  456.             Access Type", 12/26/1995, RFC 1873 Levinson, E., "Mes-
  457.             sage/External-Body Content-ID Access Type", work in
  458.             progress, ftp://ds.internic.net/internet-drafts/draft-ietf-
  459.             mimesgml-access-cid-01.txt.
  460.  
  461. [CFG]       Borenstein, N., "A User Agent Configuration Mechanism For
  462.             Multimedia Mail Format Information", September 23, 1993, RFC
  463.             1524
  464.  
  465. [DISP]      R. Troost, S. Dorner, "Communicating Presentation Informa-
  466.             tion in Internet Messages:  The Content-Disposition Header",
  467.             June 7, 1995, RFC 1806
  468.  
  469. [MIME]      Borenstein, N. and Freed, N., "MIME (Multipurpose Internet
  470.             Mail Extensions): Mechanisms for Specifying and Describing
  471.             the Format of Internet Message Bodies", June 1992, RFC 1341.
  472.  
  473.  
  474. 9.  Author's address
  475.  
  476.    Edward Levinson
  477.    47 Clive Street
  478.    Metuchen, NJ  08840-1060
  479.    USA
  480.    +1 908 494 1606
  481.    <XIson@cnj.digex.com>
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503. Levinson                  Expires January 1998                  [Page 9]
  504.  
  505.  
  506.