[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] semantics of mhshow -type and -part

From: Paul Fox
Subject: Re: [Nmh-workers] semantics of mhshow -type and -part
Date: Mon, 02 Feb 2015 07:00:14 -0500

david wrote:
 > Paul F. wrote:
 > > as an aside, i actually think "the sender's ranking" is a highly
 > > overrated, and possibly even obsolete concept these days, RFCs
 > > notwithstanding.
 > I'm not sure about that.  My phone seems to handle it
 > (multipart/alternative) nicely.

and nmh does (or could) too, right now, if we were all willing to hand
html mail to our browsers for display.  but most of would prefer to
see text/plain over text/html, or perhaps even choose which based on
sender.  i'd like to see that made easier than it is now, because
while its nice to know what the "sender" would prefer me to look at,
that preference can be difficult for me to accomodate.

 > On the other hand, I have been getting emails with text/html and
 > text/plain in a multipart/related.  But those two text parts
 > appear to be just different representations of the same content,
 > so they really should be in a multipart/alternative.  I had been
 > thinking that these are mistakes.  But now I wonder if that's
 > the sender's way of punting the choice to the recipient.

does it matter?  again, this suggests that we need better mechanisms
for choosing among alternative mime parts in ways that are somewhat
independent of the sender's supposed preference.


 > mhshow shows both, which is a bit annoying.  Could we do better
 > by default?  I've been relying on -type text/html, which is OK.
 > My phone shows the first inline and makes the others available
 > as attachments, even if they all have inline disposition.  That
 > doesn't seem right.
 > David
 > _______________________________________________
 > Nmh-workers mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

 paul fox, address@hidden (arlington, ma, where it's 10.6 degrees)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]