On Tue, 2 Mar 1993 11:01:32 PST, Bill Janssen
<janssen(_at_)parc(_dot_)xerox(_dot_)com> said:
Bill> Yes, you clearly need to keep all of the type
Bill> information. The problem with a scheme like adding a
Bill> ``disposition'' parameter on Content-Type is that this
I did not propose it as a parameter, but as a separate header.
Bill> ``attachment'' characteristic is related to the
Bill> situational use of the document, not to its content, so
Bill> you don't want to add this situational notation to the
It is not clear to me how this follows.
Bill> basic set of headers of the document. Imagine, for
Bill> example, storing the attachment in a file, then visiting
Bill> the file later with a MIME-capable editor. This
Bill> disposition parameter would still be in the file, and
Bill> still affecting use of the document.
Not necessarily; it is perfectly valid (desirable, even) to remove
Content-Transfer-Encoding in the process of saving a bodypart as a
file. I think this is a better analogy. Onece a bodypart is stored as
an indovidual file, I see no reason to keep ANY mime-associated data
with it (except in the special case of a caching MTA); every platform
provides its own way to identify a file in native filesystem format
(extension, magic number, FileInfo, etc.)
Bill> This is why adding another subtype of multipart seems
Bill> like a win -- you are putting the the situational
Bill> information about use at the right level of the message
Bill> ``document''.
The only win inherent in subtyping multipart seems to me the
desirability of avoiding further gratuitous changes to the spec.
Bill> I'd imagine the wording of the section describing
Bill> ``multipart/attachments'' would be something like this:
Bill> 7.2.4 The Multipart/attachments subtype
Bill> The multipart/attachments type is used when only one
Bill> part of a multipart message (called here the _primary_
Bill> part) is intended to be displayed, the other parts
Bill> acting as documents ``attached'' to that primary part.
Bill> User agents should only display the attachments in some
Bill> short form (.i.e., with a name or icon), but should
Bill> display the primary part in full. The primary part is
Bill> specified to be the *last* part of the
Bill> multipart/attachments.
I am really uncomfortable with this as stated. First of all, the
"primary" should come first, to help out older MUAs. But this
multipart seems like a kludge to me. If we need to determine whether a
bodypart is intended as an attachment or an in-line item, it seems to
me that we are talking about an attribute of the bodypart in question;
the Content-Disposition header seems the best to me.
-Rens
__ ___ , __
/__) /__ /| / ( | J. Laurens Troost Lehman Brothers Technical Services
/ \ (___ / |/ __) | *Opinions expressed herein are mine. Mine, I tell you!*
-------------------------------------------------------------------------------
INET: rens(_at_)shearson(_dot_)com VOICE: (212) 464-3705 FAX:
(212) 464-2040
If trees could scream, would we be so cavalier about cutting them down? We
might, if they screamed all the time, for no good reason. -Jack Handey