[Top] [All Lists]

yet another way to indicate related MIME body parts

1993-10-24 21:13:55
I've been working on a cleaner way to indicate relations among
MIME body parts.  I'd like to throw this one in as another strawman.

Whatever we choose, I'd much rather see a generalized mechanism
for composite content-types that need to reference one another, than 
having separate multipart contents for each composite type.

NOTE:  Since this is going out to the whole ietf-822 list, only 
the first abstract and introduction of the draft is below.  
The remainder can be had by ftp from

and eventually from the internet-drafts repositories.

This proposal is similar to several other proposals that have been
floated here.  It tries to define a general mechanism by which one
MIME content can reference another one, as long as both are contained
within the same multipart/references construct.  The downside is that
the programs that display (or more generally, "present") MIME contents
have to know how to access those contents from within.  An appendix
to this draft describes a fairly system-independent mechanism by which
this might be accomplished.


Network Working Group                                        Keith Moore
Internet Draft                                   University of Tennessee
                                                         24 October 1993

                 Multipart/References MIME Content-Type


1. Status of this Memo

[ this is boilerplate ]

2. Abstract

   This memo defines a new MIME content-type "multipart/references",
which can be used to denote a set of MIME contents, of which any one may
reference the others by its MIME content-id.  This mechanism may be used
by presentation languages that wish to be able to reference MIME
objects, or by other applications (file transfer, authentication,
delivery reports) which need to supply related information about another
MIME object.

3. Introduction

   Several new MIME [1] -based applications are being developed which
require data that is best represented (within a MIME message) as
multiple MIME body parts.  Frequently, such applications simply need to
"embellish" or provide additional information about one or more other
objects, which themselves are naturally represented as MIME body parts.
Examples of such applications include the following:

   + File transfer.  When using MIME to transfer a file, it is useful to
     represent the file being transferred as a MIME body part (with
     appropriate MIME content-type labelling), and provide additional
     information (ownership, creation date, permissions, icon, or data
     specific to a particular system) in a separate body part.  A MIME
     mail reader could present the contents of the file being
     transferred in addition to offering to store the file on the
     recipient's file system.

K. Moore                  Expires 24 April 1994                 [Page 1]

Multipart/References                                     24 October 1993

   + Authentication.  A separate body part could be used as a
     certificate of authorship and integrity check, using protocols such
     as PEM [2,3,4,5].

   + Delivery and receipt notifications.  A delivery status notification
     (or receipt notification) may include both the original message,
     and a separate body part indicating why the delivery of the message
     failed.  The mechanism defined in this memo could be used to
     illustrate the relationship between the two.

   + Hypertext systems.  It may be desirable to transmit a set of
     hypertext documents which reference one another, in a single MIME

   + Presentation languages.  Since MIME says little about how the
     objects it carries are to be presented, this extension may be used
     by presentation languages that wish to reference other MIME

   Although MIME [5] defines a content-id header which can be used for
this purpose, it provides no mechanism by which one body part can
reference another.  Neither does it provide a mechanism to indicate
whether a particular body part should be presented by a mail reader,
stored in a file (as in an attachment), or whether the body part is
intended to be referenced by another body part.

   This memo thus defines:

   + a "multipart/references" content-type to be used to indicate a set
     of body parts that may reference one another.

   + a new "internal" access-type for the message/external-body content-
     type, which instructs the mail reader to present another body part
     contained within the same multipart/references content.  (This is
     intended to be used within multipart/alternative, as a fallback for
     when better presentation languages are not supported.)

[ if you're still interested, get the whole document ]