On Apr 29, 4:27pm, Nathaniel Borenstein wrote:
Subject: Re: a plea for simplicity
% I also think that the idea that our current version of "text" works
% "well enough" is a very USA-centric view. However reverting to a
% content-type of "text" with a place to specify character sets (either in
% a separate header or as part of content-type) is a clear and simple
% solution. What makes it messy, as we have seen, is the enumeration of
% what character sets are "standard".
End of excerpt from Nathaniel Borenstein
I don't think that it is all that messy to enumerate character sets
which need to be supported. The ISO 646-N standards are superceded by
the ISO 8859/X standards and Asian language support is added in ISO
DIS 10646. US ASCII should still be the default type.
I really am fairly disinterested about multi-parts or single parts or
lots of the "gee whiz" extensions for FAX and so forth that are being
proposed. If others can reach consensus about them, that is great but
it isn't likely to affect me very much.
I care A Whole Lot about being able to send e-mail to others in
languages other than English. I would regularly use at least German,
Vietnamese, and Chinese in e-mail if it were practical. Unfortunately,
it isn't just now.
Support for the various ISO 8859/x 8-bit character encodings is
becoming fairly common in commercial systems. Even most of the US
vendors are now supporting ISO 8859/1 which is commonly known as "ISO
Latin-1" and several are also supporting the others in the 8859
family.
It is unrealistic to think that all sites will be able to correctly
display these 8-bit character encodings, but the encodings should be
clearly marked using a standard (but optional) header and cooperating
SMTP links should be able to transport the bits properly (a draft set
of SMTP extenstions to support this was just posted to that list).
Similarly it should be possible to transport the bits properly for the
ISO DIS 10646 character encoding and to mark the content as being
encoded in ISO 10646 (though support for ISO 10646 is less important
than the fundamental of supporting ISO 8859/x).
The "character encoding" header should not be also used to specify
information such as "troff" or "TeX" but should only address character
encodings. That way, mail gateways supporting optional character set
extensions will not be needlessly complex to implement. The default
character encoding should be 7-bit US ASCII (X3.4 - 1986) for full
backwards compatibility.
If the new RFCs will let me send/receive 8-bit ISO 8859/x mail and
ideally also send/receive ISO DIS 10646-encoded mail with some
cooperating set of hosts and users, I will be satisfied. The strings
"ISO-8859-1" through "ISO-8859-N" (where N is the last in that family
of standards) and the string "ISO-10646" should be defined for use to
indicate that that is the character set encoding standard used for the
mail message. If other such ISO or national sets are also desired,
they could be added either now or later. It is not clear to me that
others are really necessary beyond US ASCII, ISO-8859-N, and ISO 10646
(if there are deficiencies in ISO DIS 10646, there is still time to
get them fixed by contacting the ISO WG with the details of the
problems).
Note that I am suggesting that the draft RFC specify how character
set encodings are to be marked if such extensions are present in an
implementation, but I am not suggesting that such support be
mandatory. The result will be that cooperating users and sites can
successfully interoperate.
Randall Atkinson
randall(_at_)Virginia(_dot_)EDU