Re: [Nmh-workers] Second release candidate for nmh 1.6 now available

[Ken Hornstein]

>I don't follow.  What if the email says that it's something
>that norm_charmap() would convert to US-ASCII or one of the
>others that it modifies.  How do we know if that matches
>the user's locale character set?

Look at the comments in norm_charmap(); it's sole purpose is to convert
from a locale character encoding to the proper name used in MIME standards.
That's the reason it has weird things like 8859 mapping to ISO-8859-xx
(because locales generally omit the '-').  It was never intended as a
general MIME character set canonicalization routine.

As for alias conversion ... well, currently it only supports a small
subset of the supported aliases for character sets.  In the case of
US-ASCII, I'm not actually sure any other name for it is allowed in
the RFCs.

If you're sending out an email with charset="ANSI_X3.4-1968" ... well,
I don't think that a call to iconv() is unreasonable here.  I guess
I think it's more reasonable to handle this stuff in iconv() rather
than maintain our own charset aliases; the worst case is stuff gets run
through iconv when it isn't necessary, but I do not consider that a huge
problem.

>And with mhfixmsg, the user's locale doesn't enter in at
>all.  The user can translate the message from whatever
>it is to whatever the user wants (assuming that iconv
>supports the translation).  mhfixmsg uses norm_charmap()
>when deciding whether that translation isn't necessary.
>I'd be OK with removing the norm_charmap() here, on the
>assumption that users (and emails) will say "US-ASCII"
>and not one of its aliases.

I have never seen an email that contained a charset parameter that used
an alias to US-ASCII, but I admit I could be wrong.  Like I said, I'm
perfectly fine with an extra call to iconv() for these bizarre corner
cases.  I think strcasecmp() is fine to test for charset equivalence.

--Ken