For backwards compatibility with RFC-822, the default character set
has to be US ASCII (ANSI X3.64-1986) so that existing conforming
implementations aren't obsoleted.
We should make every effort to avoid being Euro-centric to the
disadvantage of the Asian languages in the devising of the new
standard. I myself have regular enough need to use Vietnamese and
Chinese that 8859/1 just won't suffice. The other languages in the
8859 family shouldn't be given short shrift either (e.g. Arabic).
To be inclusive of major languages, we should formally support the
ISO 8859 family (not just 8859/1) and also the ISO 10646 standard
(once it is finalised). This would permit European languages to be
efficiently coded in the 8-bit ISO 8859 series of standards while also
supporting the Asian and other languages that are encoded using ISO
10646. The current draft of the 822 extensions is in the neighborhood
of what I'd like to see in this regard.
The current draft doesn't specify the meaning of the ISO 2022
content sufficiently well to implement and if RICHMAIL is going
to be moved to a distinct RFC, I think that the ISO 2022 material
should likewise be moved to a distinct RFC where it will be clearly
defined.
[ None of this is new thinking on my part, but I repost as reaction
to the recent note suggesting that 8859/1 be the preferred encoding
under the new RFC. Thanks for your patience with my repetition. :-) ]
Randall Atkinson
randall(_at_)Virginia(_dot_)EDU