[Top] [All Lists]

New type suggested: Multipart/Related

1993-05-20 02:46:22
Here is my entry to the content-disposition debate.
This memo defines 2 things, which may or may not be a good idea:

- A way to tell the recipient MIME reader which body parts contain only
  info that is "about" the other body parts

- A way to tell the recipient MIME reader which is the "main" body part
  (and therefore, by extension, that all the others are "attachments").

I have not submitted it as an Internet-Draft; I thought I would solicit
comments off this list first.
The private consultations I have had on this provoked no more than
lukewarm reactions, so I'll see if there are more flames here....

In my (biased) opinion, this makes more sense than 
Content-Disposition: {main/attachment}, since it attaches the information
to where it belongs: The composite level.

If there are no significant claims that this does not make any sense,
I'll bother the CNRI about internet-drafting it, and let it stew for a while.
NOTE: This one *has* to be standards-track, because I want other RFCs to
be able to use it.
Please comment!

                       Harald Tveit Alvestrand
(No, this memo is *NOT* about character sets :-)

draft                     Multipart/Related                     May 93

                 The MIME Multipart/Related content-type

                     Thu May 20 11:17:05 MET DST 1993

                         Harald Tveit Alvestrand
                               SINTEF DELAB

    Status of this Memo

    This draft document is being circulated for comment.

    If consensus is reached it may be submitted to the RFC editor as a
    Proposed Standard protocol specificiation, for use with MIME.

    Please send comments to the author, or to the 822ext list <ietf-

    The following text is required by the Internet-draft rules:

    This document is an Internet Draft.  Internet Drafts are working
    documents of the Internet Engineering Task Force (IETF), its
    Areas, and its Working Groups. Note that other groups may also
    distribute working documents as Internet Drafts.

    Internet Drafts are draft documents valid for a maximum of six
    months. Internet Drafts 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 I-D abstract listing contained in each Internet
    Draft directory to learn the current status of this or any other
    Internet Draft.

Alvestrand                Expires Nov 20 93                   [Page 1]
draft                     Multipart/Related                     May 93

    1.  Introduction

    Several applications of MIME, including MIME-PEM and MIME-
    Macintosh, have had the need to provide content-types that
    provide, basically, two pieces of information:

    One, the "basis", which is of a content-type otherwise defined.

    One, the "header", which provides interesting information about
    the other part of the message. In PEM, this is the algorithm,
    signature and key information; in MIME-Macintosh, this is the
    Finder information. In both cases, it is possible for the message
    to be useful without this part being understood, but there is a
    lot of added functionality if this other part is also understood
    by the recipient.

    In other cases, a desire has been expressed for giving a hint to
    the recipient UA on whether it is intended to display the parts of
    the message at the same time or as attachments to a main message.

    In order to keep the MIME philosophy of having one mechanism to
    achieve the same object for different purposes, one single
    mechanism should be defined for doing such things.

    2.  Definition

    The following text is copied from RFC 1341, appendix F1.

                     MIME type name: Multipart

                     MIME subtype name: Related

                     Required parameters: None

                     Optional parameters:
                           Header=<MIME type>

                     Encoding considerations:
                           Multipart content-types cannot have encodings.

                     Security considerations:

Alvestrand                Expires Nov 20 93                   [Page 2]
draft                     Multipart/Related                     May 93

                           Not considered

                     Published specification:
                           This document

    3.  Intended usage

    3.1.  The Header= parameter

    In cases where the header= parameter is given, the part or parts
    with the given type(s) are understood to give information about
    the other part or parts of the Multipart.

    The placement of the type in the header serves 2 purposes:

    -    To identify the particular type which has to be treated

    -    To enable configuration-based UAs to switch to the correct
         processing module for that particular header type.

    In certain configurations it makes sense to list several "header"
    types, for instance when a Macintosh file is sent with a PEM
    signature applied to its Data fork (but not to its resource fork).

    How to associate each Header with its related Content part must be
    defined when defining the Header type; the most common cases will
    be that it is only legal to have it together with a single part
    not mentioned in the Header= list, or that it applies equally to
    all parts not mentioned in the Header= list.

    When an UA is able to process the Multipart/Related type, but not
    any of the types listed in the Header= parameter, it is allowed
    for the UA to suppress the part entirely when viewing the message,
    since it does not make much sense to store it separately.

Alvestrand                Expires Nov 20 93                   [Page 3]
draft                     Multipart/Related                     May 93

    3.2.  The Mainpart= parameter

    This parameter is a hint to the recipient UA that the sender
    intended the part with the Content-ID of the parameter to be
    displayed at once, and that the sender intended that the recipient
    should have to take specific action in order to view the other

    One possible implementation of this is to display the main part at
    once, and the others as an icon row.

    This RFC does not specify where the mainpart should be in the
    sequence of parts.

    4.  Registration forms

    Form for registering new parameters to the Content-Type
    Multipart/Related type

    Parameter value grammar:

    Authors' address

    Detach and submit to IANA for archiving.

    The IETF-822 list is suitable for discussion of such extensions
    prior to registration.

    5.  Example description

    Example describing the relationship between a body part mentioned
    in a Header= parameter and other body parts in the message

    <The example is bogus>

    The content-type Application/RecLenList is intended for use
    together with the Application/Octet-stream type inside a
    Multipart/Related, but can be used with any primitive MIME type.

Alvestrand                Expires Nov 20 93                   [Page 4]
draft                     Multipart/Related                     May 93

    In all cases, it refers to the canonical encoding of that type.

    The RecLenList consists of a set of INTEGERs in ASCII format, one
    per line, and each INTEGER gives the number of octets from the
    other body part that should be considered part of this "record".

    Multipart/related consideration

    The RecLenList applies to only one other body part, so when it is
    used in Multipart/Related, there should only be one body part
    present that is not mentioned in a Header= parameter.

    6.  Security considerations

    No security considerations relevant to this memo have been

    7.  Acknowledgments

    Acknowledgements are, as always, due to more people than can be
    listed.  However, I especially want to thank:

    -    Nathaniel Borenstein and Ned Freed, for writing the MIME that
         I can base this on

    -    Ned Freed and Patrik Faltstrom (diaeresis on the a end o in
         his last name), for trying to define the MIME body parts that
         led me to write this memo

    -    SAS catering, who provided the service during the airplane
         trip during which the first version of this document was

    8.  References

    RFC 1341 - MIME

    RFC 1421 - PEM

Alvestrand                Expires Nov 20 93                   [Page 5]
draft                     Multipart/Related                     May 93

    9.  Author's address

    Harald Tveit Alvestrand
    N-7034 Trondheim

    +47 7 59 70 94

Alvestrand                Expires Nov 20 93                   [Page 6]


<Prev in Thread] Current Thread [Next in Thread>