On Thu, 04 Mar 1993 16:52:26 -0500, Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> said:
Keith> MIME currently doesn't (and shouldn't) try to solve the problem
of how
Keith> to present each of the body parts of a message. The reason: we
don't
Keith> yet know how to do this well, and more experimentation is
needed. I
Keith> would recommend that those wanting to work on solutions define
their
Keith> own experimental MIME content-types, which reference the
content-ids
Keith> of other MIME body parts, and define how those body parts are to
be
Keith> presented. (NeXTmail essentially does this now -- the first
part of a
Keith> message is RTF that contains text mixed with references to
sounds,
Keith> graphics, etc., that appear in other body parts.)
This is well put; the spec makes it plain that for complicated
multipart formatting, an application subtype is appropriate. I expect
that there are several people working on this sort of thing; I recall
that a referencing mechanism was put forward during the
richtext/simpletext discussion. When a really good one is implemented,
I expect most mail will use it. This issue is close to my heart, as I
am working on just such a scheme.
But the disposition/presentation question is really more broad than
this. For instance, lets say we have an application subtype of the
sort mentioned (I'll call it an "organizer") , and also a bunch of
other bodyparts. The question arises; how to display the message? One
of three things could be true of a given bodypart:
1) It is not referenced by the organizer, and it should be displayed
inline.
2) It is not referenced by the organizer, and it should be displayed as
an attachment.
3) It is referenced by the organizer, and should not be otherwise
displayed.
This information should be available to the MUA without it having to
know about the structure of the organizer, allowing organizers to be
strapped in via mailcap, and eliminating redundant display.
Keith> Of the "quick" fixes to MIME that allow "attachments" to be
Keith> distinguished from "inline" body parts, I prefer simply adding an
Keith> (optional) parameter to Content-type. This seems like a less
Keith> drastic change to MIME, and one which we can more easily
deprecate (or
Keith> simply forget) later when we have a better way of defining the
Keith> presentation of the body parts of a message.
If you buy my analysis, I hope you will see that it is not just a
quick fix, but a substantial enhancement to the system. I of course am
promulgating the optional extra header, which is cleaner than mucking
about with subtypes of multipart.
Keith> If it turns out that we want presentation information in a
different
Keith> header, then I would recommend putting the "filename" parameter
in the
Keith> content-presentation header also.
This is a good idea, but would require revising MIME. I'll be putting
the Content-Disposition forward as a separate RFC; MIME should remain
stable at this point as more resources are coming online to implement
it!
-Rens
__ ___ , __
/__) /__ /| / ( | J. Laurens Troost Lehman Brothers Technical Services
/ \ (___ / |/ __) | *Opinions expressed herein are mine. Mine, I tell you!*
-------------------------------------------------------------------------------
INET: rens(_at_)cs(_dot_)columbia(_dot_)edu VOICE: (212) 464-3705
FAX: (212) 464-2040