ietf-822
[Top] [All Lists]

Re: C-D: Attachment Clarification

1995-01-19 13:07:38
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