Re: macho 0.4 released

Klaus Weidner <[email protected]> Mon, 10 Nov 2003 17:10:25 -0600
Newsgroups gmane.lisp.clump
Message-ID <[email protected]>
On Mon, Nov 10, 2003 at 02:49:34PM -0800, Jan Rychter wrote:
> If we do this, let's get this right -- the breakage associated with most
> US programs assuming that the world is ASCII and most European ones
> assuming that the world is ISO-8859-1 has already been around way too
> long.
[...]
> I'm afraid Unicode is the only way out here. I don't think the solution
> you have proposed is any more "correct" than just leaving everything
> unexpanded and pretending that only ASCII exists...

That's why I changed my mind and described in my other mail how Macho
could be enhanced with Unicode *output* support with little effort.

On the input side, it's a fact of life that very many people are
*sending* mail using ISO-8859-1 (and other) encodings, and as long as the
encoding used is specified properly (as it is in the =?ISO-8859-1?
format) and not just unmarked 8bit characters, that should be supported
if it's not too much work. It's very easy for 8859-1, and for other
encodings it would be a matter of collecting and using existing
conversion tables to convert to UTF-8. 

I'm *not* proposing blindly interpreting all input as iso-8859-1 8bit
characters.

The old adage "be strict in what you produce, but liberal in what you
accept" applies here [1], and we can't retroactively fix the content of
existing mail archives. The output should definitely be
standards-compliant Unicode and not yet another kludged 8bit format.

The change I proposed would probably only be a couple of lines of code to
get the basic framework in place, and the more labor-intensive extensions
would at least fit in if someone gets around to doing them. I guess it's
time to put my fingers where my mouth is and code this if nobody beats me
to it :-)

-Klaus

[1] That arguably led to major brain-damage in the case of web browsers
accepting invalid HTML, which led to sloppy pages, which turned HTML into
a de-facto poorly specified mess because now *all* browsers needed to
accept invalid input. But that's a different situation - the =?CHARSET
encoding *is* the standard for getting non-ascii characters into e-mail
headers.