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

* Your Email Address
* Spam protection	Enter the letters below: .__.. . __..___.. . \| \|\|_/ (__ _/ \| \| \|__\\| \.__)./__.\|__\|
Comment	> [Note: I had written a long explanation of why this was message at > some point - evidently, it was never posted to the ticket. So my > response was probably not as clear as needed because it was lacking > this context] > > > >> Well, we need to find some way to reconcile the standards and > >> usability. The parts list is not a user friendly or obvious > >> solution to this. And your statements about what the sending user > >> intended are over inferential in my opinion. I'm pretty sure the > >> sender of the message that inspired this test intended me to be able > >> to download the excel spreadsheet without a). picking it from a raw > >> list of every part of the message, and b). being able to view it > >> inline in my mail client. > > > > 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. > > > > 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." > > > > 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. And the current method of handling > this message (displaying an earlier alternative) is what is being > complained about. So what needs to be done here is revamping the > display algorithm to show the later multipart alternative even if it > may contain parts that are not viewable inline. (Do we display the > multipart alternative even if it contains no viewable parts? It is > not clear from the RFC.) > > > > 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. The resulting display on > 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. At a > minimum, the generation of this MIME message is ignorant. > > > >> What do you think is wrong about how Mail.app displays this message? > > > > I don't have a Mac handy to view this. But see my desktop vs. > non-desktop discussion above. > > > >> We did a lot of work during the initial DIMP project on usability of > >> the attachments list, trying to match up with other user-friendly > >> clients, etc. I don't want IMP 5 to lose this. > > > > These changes have been brought about precisely because of the > numerous complaints of the way we currently handle attachment lists.
Attachment
Watch this ticket

Saved Queries