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
cs.utk.edu:/pub/MIME/draft-moore-mime-references-00.txt
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.
Keith
--------
Network Working Group Keith Moore
Internet Draft University of Tennessee
24 October 1993
Multipart/References MIME Content-Type
draft-moore-mime-references-00.txt
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
message.
+ 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
objects.
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 ]