[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments |
Date: |
Thu, 06 Feb 2014 15:49:34 -0500 |
>Actually, I also wonder - how this feature [do not show attachments]
>will interact with not calling PAGER multiple times, for each MIME part.
It's important to understand a few things here. For one, I haven't
really worked out the details; it's a vague statement. Secondly, there
may be some technical issues that muddy the waters (in nmh, there almost
always are). But let's step back a bit.
First off, I don't think anyone disagrees that the current interface
with "mhshow" kind of sucks. Specifically, showing a message with lots
of parts kinda bites. Showing a message with a single part kind of bites,
actually. So that should be improved.
But this gets into a couple of meta-questions about user interface.
These are things that nmh has to grapple with, and traditionally we
haven't done so well. Generally nmh deals with text, and how to handle
that is mostly straightforward. But what happens when you encounter
non-text parts, like images, video, or binary content like MS Word
documents? You can't really display those in an xterm. So what should
we do?
Luckily, the standards provide some hints. Here's some text from RFC 2183:
Two common ways of presenting multipart electronic messages are as a
main document with a list of separate attachments, and as a single
document with the various parts expanded (displayed) inline. The
display of an attachment is generally construed to require positive
action on the part of the recipient, while inline message components
are displayed automatically when the message is viewed. A mechanism
is needed to allow the sender to transmit this sort of presentational
information to the recipient; the Content-Disposition header provides
this mechanism, allowing each component of a message to be tagged
with an indication of its desired presentation semantics.
Later on, it says:
Bodyparts can be designated `attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user. The MUA might instead present the user of a
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the
user could select for viewing or storage.
So it seems consistent to me that at least the default mode with
mhshow should not show items with a disposition of "attachment". If
people want to add an option to mhshow to make it shows those things,
then that's fine with me. I'm just talking about defaults.
Also, in general this jibes with my personal experience; items that
are marked as "attachment" are stuff you don't want to view directly, but
you want to save and look at with another program. Fine, if people want
to override that behavior, that's their option.
>Does the last one implies, that some kind of meta-message will be
>constructed, and if someone send email with few text/x-diff's, for
>example, user will see the message and the diff's with one shot of
>mhshow?
Well, first off ... text/x-diff? Who produces that Content-Type? Fine,
there's not really a standard for that. RFC 2046 suggests it's safe to
show unknown text subtypes directly to a user directly. The real question
is: what's the disposition of those MIME parts? RFC 2183 is silent on
what you're supposed to do if there is no disposition header, but I
would argue you should default to "inline".
>If last one assumption is true, personally, I'd like to see attachments
>instead of hiding them by default.
And you're free to change that!
>Although, for binary ones, it can be
>replaced with something useful, like:
>[[ attachment: document.doc ]]
>[[ type: application/msword ]]
>[[ size: 10 Mb ]]
That sure would be a lot better than what happens now (you get an error).
--Ken
- [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Mikhail, 2014/02/02
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Ken Hornstein, 2014/02/02
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Mikhail, 2014/02/03
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Ken Hornstein, 2014/02/03
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Mikhail, 2014/02/04
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Ken Hornstein, 2014/02/04
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Mikhail, 2014/02/06
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments,
Ken Hornstein <=
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Mikhail, 2014/02/10
- Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments, Ken Hornstein, 2014/02/10