Excerpts from direct: 1-Mar-93 Re: file attachments in MIM.. Laurence
Lundblade(_at_)csgra (1061*)
The idea that some of us came up with was to add a parameter for all types
called something like "disposition" that would indicate if it should be
displayed in full or as an attachment. The good thing about this is that
it is easy to implement and it works for all the types. There's no
overloading some more meaning on to some types. For example deciding that
text parts should always be displayed. This way you also keep the type
info for each attachment (Image/GIF, App/PostScript...). This is important
at least in the case of text versus binary data to know when to convert to
the local new line convention.
Yes, you clearly need to keep all of the type information. The problem
with a scheme like adding a ``disposition'' parameter on Content-Type is
that this ``attachment'' characteristic is related to the situational
use of the document, not to its content, so you don't want to add this
situational notation to the basic set of headers of the document.
Imagine, for example, storing the attachment in a file, then visiting
the file later with a MIME-capable editor. This disposition parameter
would still be in the file, and still affecting use of the document.
This is why adding another subtype of multipart seems like a win -- you
are putting the the situational information about use at the right level
of the message ``document''.
I'd imagine the wording of the section describing
``multipart/attachments'' would be something like this:
7.2.4 The Multipart/attachments subtype
The multipart/attachments type is used when only one part of a
multipart message (called here the _primary_ part) is intended to be
displayed, the other parts acting as documents ``attached'' to that
primary part. User agents should only display the attachments in
some short form (.i.e., with a name or icon), but should display the
primary part in full. The primary part is specified to be the
*last* part of the multipart/attachments.
Bill