[Tickets #7981] Re: No way to get some attachments to a multipart message

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7981
------------------------------------------------------------------------------
  Ticket             | 7981
  Updated By         | Chuck Hagenbuch <chuck at horde.org>
  Summary            | No way to get some attachments to a multipart message
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Horde Developers, Michael Slusarz
------------------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2009-07-09 23:11) wrote:

> I think we are talking about 2 separate issues here.  Issue 1 is how  
> to display (alleged) attachments that are not ordinarily displayable  
> in a MIME message.  Two examples would be parts of a  
> multipart/related message that are not linked in the base message  
> and multipart/alternative parts that are not displayable in the  
> browser (which, as it turns out, is not the present issue - see  
> below).  In both cases, for exactly the usability reasons discussed  
> below, these parts CAN NOT be displayed inline as attachments unless  
> attachment inline viewing is turned on.  Doing so means that there  
> is no longer multipart/related or multipart/alternative messages -  
> we just display everything as multipart/mixed.  This can not be the  
> case.

Agreed.

> e.g. For multipart/alternative parts, displaying the "alternative  
> parts" box was a usability nightmare also so that should not be  
> brought back.  Especially in light of this mandate from the RFC:  
> "What is most critical, however, is that the user not automatically  
> be shown multiple versions of the same data."

Also agreed.

> The 2nd issue is simpler: tweaking the display of  
> multipart/alternative parts.  That is the present case.  The MIME  
> structure here is as follows:
>
> multipart/alternative
>  text/plain
>  multipart/mixed
>   test/html
>   application/vnd.ms-excel
>   test/html
>
> This oh-so-unenlightening remark from RFC 2046 [5.1.4] is the key:
>
>    In the case where one of the
>    alternatives is itself of type "multipart" and contains unrecognized
>    sub-parts, the user agent may choose either to show that alternative,
>    an earlier alternative, or both.
>
> So the RFC tells us nothing in this situation.  Useful.  Displaying  
> both is just bad usability IMHO.

I'm not sure it is. Looking at the message structure, you have text  
vs. mixed. So if we can display mixed, and we can, seems like we  
should just treat the message as though it were html - excel - html.  
The entire 3-part string is the alternative - they aren't alternatives  
for each other.

> Finally, my rant: This message does nothing to alter my view of  
> Mail.app (and it's not just me - if you want to see some real  
> Mail.app bashing, read the dovecot list sometime).  This message  
> apparently assumes that the receiving user is on a desktop-ish  
> machine - it seems as though the message wants the spreadsheet  
> attachment to be living in the middle of the HTML part.  This  
> display tactic may work on a desktop machine, where one can display  
> a little spreadsheet icon a user can click/drag-drop/etc., but is  
> not practical on something like webmail.

Actually, why can't we put a download icon there? We might not want  
to, and the code for it might be ugly, but technically it's possible.

> clients that can't generate this kind of UI (webmail,  
> pine/alpine/elm) will be an HTML part, a link to download the  
> spreadsheet attachment, and then *another* HTML part that is  
> completely empty of content.  With that last part: how is that not a  
> usability nightmare?  I can imagine a bunch of users complaining why  
> they are being shown a part with no content and/or why the software  
> is broken and not showing the correct contents of that part.

This is why it's not necessarily great usability to flag for the user  
each different part of the message. If we don't call out each part,  
but display what we can and provide download links for the rest, then  
the user doesn't have to *know* there's an empty part. There might  
just be a little extra space at the end of the message. But they don't  
need to care about it, because the UI doesn't have to make it obvious.

In the end, as long as we can do something where I get a download link  
for the spreadsheet in this message, without having to turn on the  
full parts list (which I don't think is a user-friendly thing, but  
that's a separate issue perhaps), then I'm happy.

Thanks for working through this.