In "Re: C-D: Attachment Clarification" Rens Troost <rens(_at_)imsi(_dot_)com>
writes:
My original idea was that that should be left up to the MUA designer;
attachments could either be 'inline attachments (NeXTmail style)' or
bottom-of-page (zmail style). The only baggage that an attachment has
in my mind is that display is not automatic.
The problem with leaving this undefined is that a message with "inlined
attachment icons" may become nonsensical if the attachment body parts are
simply yanked out of the body without any indication. For example, given a
message like "Use this file <...>, not this one <...>", you'd have to insert
some guiding text that would link the missing icons to the external
attachments if you aren't able to present them in the body, eg. "Use this file
[attachment foo.dat goes here], not this one [attachment bar.dat goes here]."
with foo.txt and bar.txt available through some other part of the interface.
Unfortunately, there is now no way to distinguish this use of the attachment
disposition from the one where they are indeed supposed to be listed
separately. For example, I might have a NeXTmail-type message like the one
above saying: "Use these two files: <...> <...>" and I might have a zmail-like
message saying "Use these two files" with the two attachments listed
separately. Both messages translate into:
multipart/mixed
text/plain
application/octet-stream -- attachment
application/octet-stream -- attachment
The question is, if I receive a message like this with a zmail-type MUA,
should it be presented with that extra linking text or not? If you say it
should have that text, then presentation isn't idempotent, which among other
things mean that it will accumulate a guiding phrase each time it's forwarded.
If you say that it shouldn't have linking text added to it, then you run the
risk of the message not making sense because of its lost context again. It
might be enough to say that all attachments appearing at the end of a message
should be interpreted as zmail-style attachments, but that sounds rather
kludgy to me.
Someone else suggested that the NeXT-mail type of iconic attachments should
be tagged with "inline" instead. Unfortunately, this will not work as you
then cannot distinguish an attached, iconic text file with a piece of text
that is part of the body -- both would have C-T: text/plain and C-D: inline.
The same goes for images, but that might not be quite as severe.
I'm still wondering if it wouldn't make sense to add a third disposition, as
Harald suggested earlier. Perhaps something like "iconic-attachment" or
"inlined-icon" (or just "icon").
Registering a new kind of disposition to server as a hint sounds
wrong; it may result in wrong behavior (if an MUA does not know about
disposition 'inline-attachment', how does it know it's an
attachment?). A parameter might be better.
Not if it is listed in the initial standard. Adding it as an afterthought
could definitely cause this to happen, though.
By the way, it would be interesting to see if there are any other models
presently in use. The ones I know of are:
rich body text (NeXT, Andrew)
mixed body text & graphics (NeXT, Andrew)
mixed body text & attachments (NeXT)
separate list of attachments (ViewPoint, Eudora, zmail, cc:Mail)
Cheers,
--Lennart