Re: [Nmh-workers] About mhshow tuning and replies to MIME messages with a attachments

[Ken Hornstein]

>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