2. The richtext parser can get confused if the intermediate
encoded form of the Unicode characters contains bytes
with values 60 or 62 ('<' or '>'). Rhys Weatherley is
trying to untangle a horrible snarl introduced by the
presence of such bytes in ISO-2022-JP when integrated
with richtext.
The snarl, which was not as horrible as you seem to think, has already
been untangled by Rhys, Yutaka Sato and others. The answer is simple:
just use the charset parameter in the Content-Type header. MIME
itself even points to this answer:
The syntax of "richtext" is very simple. It is assumed, at
the top-level, to be in the US-ASCII character set, unless
of course a different charset parameter was specified in the
Content-type field.
A richtext implementation that does not support iso-2022-jp therefore
cannot parse an iso-2022-jp message, and should not attempt to do so,
otherwise bytes corresponding to ASCII "<" will cause headaches. If
the implementation ignores the charset parameter and tries to parse
the message anyway, it is obviously not complying with the above
specification in MIME.
Now, there are some other issues, related to switching between
character sets within the richtext body itself, but, frankly, I myself
will not lose any sleep over this, as I don't see the need for such
features just yet, particularly since richtext itself is not exactly
established. When richtext finally settles down, it'll probably be
easier to just use Unicode in one of its encodings.
Cheers,
Erik