nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] (no subject)

2014-08-20 08:46:54
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>