Re: SEGV when replying to mail.

[Brian Stafford <brian stafford uklinux net>]

On Mon, 27 August 19:09 M . Thielker wrote:
> Hi,
> 
> On 2001.08.27 14:06 Brian Stafford wrote:
> > > reasonable. but why keep "us-ascii" as default ? i like iso-8859-1
> > > much better ;)
> > > peeve ;)
> > 
> > On the one hand, us-ascii is a good choice because the RFC 821/822 legacy
> > makes e-mail a 7 bit medium.
> > 
> > On the other hand, since MIME encoding support is in place, the actual
> > default
> > should be an application preference.
> 
> No. The way it works is that it takes the charset from the body of the
> original message and creates the reply body using that charset. Seems
> reasonable, because the content of the original message will be quoted and
> should therefore display properly in the newly created message body.

Well this is what I figured.  In any case, in all the problematic messages
I have, libmutt appears to translate the explicit 'charset="us-ascii"' parameter
on the content-type: heaedr to NULL.  This would suggest that translating
NULL to "us-ascii" is the only reasonable thing to do.

In all other cases, the reply would appear to be in the same characetr set
as the original message.

> Legacy code in libmutt equates NULL to us-ascii, there is no choice. This is
> not a preference, but a requirement and the default of us-ascii is not
> changeable.
> Of course, this strategy leads to numerous problems. How, for example, can I
> reply to a message in simplified Chinese using roman letters? Two encodings,
> but only one charset specifier.

UTF-8 perhaps?

> So, sometimes a reply to a message is possible only in the charset of the
> originator.
> That also makes a twisted kind of sense, because when I get an email encoded
> in us-ascii, it's likely that the senders terminal can only display
> us-ascii.

Not necessarily.  We're stuck with the US-centric 7bit legacy.  Before MIME,
8 bit mails with international characters were becoming common.  Senders and
recipients agreed character sets by mutual understanding rather than via an
explicit mechanism.

> There's no point trying to reply with charset = iso-8859-1. His
> terminal probably wouldn't display accented characters properly, anyway.
> There is a reason to set the charset of a reply to the originator's charset.
> Of course, most PC terminals today can display iso-8859-1 and only use
> us-ascii as a convention. Us-ascii is a subset of iso-8859-1, rather, code
> page 437 and 850 have a common subset, which fully contains us-ascii.

More accurately, the other character sets are usually a superset of us-ascii.
Not all though.  Some character sets substitute some of the ascii characters,
see ITU T.50 for an example of this sort of thing.

> So, there may be a point in translating NULL into iso-8859-1, at that.

Why not, say, iso-8859-7 then?  The reason I thought about making it a
preference
(or at least a per-message selection) is that lacking an explicit character set
in the original message a sender can probably guess the character sets a
recipient can display from the natural language of the message.

> Melanie

Brian