Dave,
I appreciate your concern over the issue of the interaction
of multiple character sets. To summarize your concerns....
1) There is no world standard for character sets
2) The ability to choose arbitrary character sets is
a new ability with little experience.
so, the character stuff should be experimental.
I believe these concerns are not relevent to the current work. There
is not currently, not is there expected to be a International Standard
character set anytime soon. This is not good enough reason to derail
this important piece of pragmatic engineering.
This specification has been widely reviewed by IETF participants from
about 10 countries, including those from Western European, Slavic, and
Asian regions. The approach is accepted as a good way to allow the
use of existing mechanisms while leaving a migration path to a
"global" standard should one emerge.
Many people have put in much time to get something that works written
down. There are multiple interoperable implementations, which do
correctly select the intended character set and display it, or convert
it to local form.
To the issues you raised.
First, there is much experience with most character sets profiled for
use with this specification. Many ISO 8859 varients are in wide use
by many vendors. These varients are clearly defined, and their use is
clearly specified in the protocol. ASCII and the ISO 646 varients of
ASCII are also in wide use. (The 646 varients have known operational
deficiencies their use is discouraged in favor of their replacements,
the 8859 series)
ISO 2022 while not a character set per-se has been profiled by the
Japanese academic community for their use in such a way that it meets
all reasonable requirements as a usable character set. It is stable
and is widely used on the Internet. There is no formal specification
of this usage available outside Japan and in English. A summary of
the protocol was provided by a presumably knowlegable Japanese
participant in this working group, and was verified by two US based
implementors of Japanese language terminals. This summary is included
as an Appendix. Again, the usage is stable, but a formal spec is not
available in English.
Second, the intended use of this specification does not envision
dynamic shifting between character sets of differnet octet lengths.
This dynamic shifting is a difficult problem and this document makes
no effort to standardize a mechanism. This is still a research effort.
This message specification was intended merely to be a formal way to
document current usage, for which there is plenty of experience.
Now, the IETF mail extensions protocol does include references to two
non-stanard works. The first, called Mnemonic Encoding, allows for
text which cannot be displayed on old terminals in native glyps to be
encoded in such a fashion that a human has a reasonable chance of
interpreting it when viewed on an ASCII terminal. This mechanism has
broad community support among the Northern European networking (NETF,
Nordunet) as a transition path until the infrastructure can be
upgraded to display the native character set glyphs.
The other non-standard character set is ISO 10646. This is not
strictly speaking profiled by this document. No stable document
exists at this time. The only thing stable is the name. As such, the
IETF working group has paid lip service to it as the intended world
standard, and reserved 10646 as an identifier for it. It is not
requried to be implemented to be fully conformant to the protocol.
Again, I think these issues have been well discussed and resolved.
Greg Vaudreuil