On the attachment issue, I think it is clearly a presentation hint on an
object
by object basis. The approach of using a multipart subtype is basically
saying
- we need to attach additional information to this object, so we'll place
some structure around it and add a label to that structure. I think this is
wrong-headed, because you're really not specifying structure. An additional
Content-* header seems like the simplest way to go and the most direct.
Note that we've already got Content-ID: labels on each body part in a
message, it seems that we only need a way to refer to these in such a
way that the display to the user is done in a meaningful way.
Am I wrong, or is the critical distinction between an attachment and an
embedded object simply how it is presented to the user? Who says all
attachments have to go at the end of the document? In Slate, I would presume
that if someone indicates something is an attachment, I'd represent it in a
small iconic form (but it would show up whereever they had put it in the
document). The additional structure information would be useless to me.
(The parallel information is also useless - I treat parallel the same as
mixed).
I agree with Terry here. As another example, in NeXTmail, an iconic
image appears in the document at the point that the object was dragged
or pasted in. There is a difference between "attachment" and imbedded
objects, but that seems mostly an presentation artifact in NeXTmail.
For example, in NeXTmail, if I drag in a TIFF or EPS image, the
"contents" of the image are rendered in the display to the user
because the presentation agent directly supports these. On the other
hand, if I drag in foo.tar file or a Lotus Improv spreadsheet, I see
an iconic representation of the file that indicats what it is.
Presumably, if the software was *really* spiffy, it would use fancy
links with the applications to "render" the spreadsheet or whatever
and display that result in the mail agent.
In NeXTmail, the names of the accompanying objects are imbedded in the
(Microsoft RTF) text of the "message". It seems that a rather simple
extension to richtext could be proposed which would allow you to
reference another body part by Content-ID. That would be one way of
making use of the referential information with a particular body part
type.
Now I don't really want to hold up NeXTmail as a great example of how
multimedia mail should be done; in fact, I loathe to use the thing for
many other reasons. But its interested to note how this issue really
hasn't turned into a problem in application, which attempts to solve
some of the same problems as MIME.
I don't really see much of a difference between embedded object and
attachments, as it mostly seems to be an issue of what the
presentation agent supports. It doesn't seem to me that the addition
of more headers is necessary to solve the problem, whatever it might
be in this case.
Louis A. Mamakos
University of Maryland, College Park