We should aim for ONE character coding for use when transfering mail with
MIME (ISO 10646). What you use locally at your site is your concern.
ISO 10646 is the logical choice. It has ASCII, ISO 8859-1 and Unicode as
true subsets both in character graphs and character coding.
As with richtext, we appear to be going in two separate directions here.
One theory, which Dan states a variation on above, is that the world
would be a better place if we viewed email as a transport and
interchange mechanism for which we wanted worldwide [character set]
interoperability. If that is the case, then the "fewer options equals
more interoperability" principle should cause us to be thinking about
migration plans to full 32-bit ISO 10646 support with the intention of
eliminating ASCII, ISO 8859-1, etc as separate character set types on
the network.
It is also possible to believe that the above is either undesirable or
completely unrealistic. If so, we get a number of variations on the
themes of trying to keep ASCII as ASCII while handling other things in
reasonable ways. UTF-2 is a member of that family, Erik has pointed out
that it isn't optimized for 7bit-land and other variations might be
better and feasible.
But can we figure out a way to address the underlying philosophical
difference head-on so that we can then focus on technical ways to do
what we want to do, rather than criticizing technical approaches from
the opposite philosophical viewpoint?
john