Re: [Nmh-workers] (no subject)

[David Levine]

kre wrote:

>   [David:]
>   | It makes sense to me to list the most preferred
>   | part first as part 1, the next second as part 2, and so on.
> 
> In that case, text/plain would be first, text/html somewhere near last,
> and application/msword deleted completely...

That's not right:

1) I use "preferred" the same way that RFC 2046 §5.1.4 uses it:

   "multipart/alternative" entities must place the body parts in
   increasing order of preference, that is, with the preferred format
   last.  For fancy text, the sending user agent should put the
   plainest format first and the richest format last.

2) The sender decides the preference.

3) It's not up to mhlist to delete alternatives.

>   | That is irrelevant to a user of mhlist/mhstore.  Why expose it?
> 
> Because (like all of MH) more than the MH (nmh) comands get used to
> process messages, and commands that are just sh scripts, that look
> for the boundaries, and count them, don't know about some fancy
> reordering that mhlist is doing because it thinks we prefer it that
> way (which we quite possibly don't in any case).

Boundaries are at a low level, MIME structure is at a higher
level.  mhlist doesn't present the boundaries, even with
-verbose.  It presents the MIME structure in the way that I
think is more useful; see below.  And see my previous comments
about non-MIME-conformant viewers (that term is also in the
RFC).

The MH and nmh behavior has been this way for at least 22 years
and is (recently) documented.  The reordering is not "fancy",
it's trivial and discussed by the RFC.

And, my whole point:  because scripts rely on MH/nmh commands,
don't change those commands (when not necessary).

> Even with reversing, you cannot just blindly assume that the first
> alternative listed is going to be the html variant (it might be in
> many messages, but there's no guarantee) - you have to look at a
> listing of the message structure and pick the part that you want to
> view, or store - given that, does it really make a difference if
> what you store is 1.3 rather than 1.1 (and every now and again it
> happens to be 1.2) ?

If I was writing a script that relied on output of mhlist to
choose a part of a multipart/alternative, I would iterate over
the parts until I found the one that I wanted (based on type,
not part number), then break out of the loop.  Just what mhshow
does.

If mhlist ordered multipart/alternative parts in increasing
order of preference, I'd have to iterate from the back.  Doable
but takes (me, but maybe not you and Ralph :-) more work.

> In this, I totally agree with Ken, presenting anything to the user
> other than what is actually in the message is just perverted.

mhlist does show what is actually in the message.  Nothing is
lost with the presentation.

David