It is clear (at least to me) that if DIS 2 of ISO 10646 were an
approved ISO standard now then smtp MUST support it on the 8 bit
paths.
There is no MUST about it. This is a decision that will be made first by proper
registration once there is a definition, second by seeing if anyone uses it
or not and whether it works or not, and finally by seeing if there's enough
support behind it to make it a requirement.
You may see usage as inevitable. I may see it as inevitable. (It turns out
that, given the platforms I use, that support for only the Unicode subset of
10646 is inevitable for me. Support for full 10646 is a long way from
inevitable. It is, in fact, quite unlikely. If everyone only supports the
Unicode subset, we may wish to specify the use of that subset rather than the
full thing. It is, however, far too early to be sure.) When these steps are
taken we'll be in a position to make 10646 support a MUST. But we cannot even
take the first step until we know what it is!
There are also no 8 bit SMTP paths. SMTP is a 7 bit protocol. If you have an 8
bit path, what you have is not standard SMTP. (This is intended to save Mark
Crispin a posting or two.)
For this reason, among others, it is inappropriate to talk about support for
10646 at the SMTP level. Support for 10646 has to happen at the MIME level
first, 822 level second, and only then with subsequent consideration given to
transports like SMTP. This is, however, only a niggle about your wording.
Since it is not now but it seems likely to pass this time
around and RFX-XXXX may be ready in the same time frame, I think it is
prudent to include it in any list of character sets that includes ISO
8859-1 for instance.
You may think it is likely to pass this time around. Other experts (I assume
you are one, given what you said) have also taken some time to assure me that
there is _no_ chance that 10646 will pass this time around, and that it may in
fact be years before closure is reached.
Who am I to believe? And does it matter? The bottom line is that 10646 is not a
standard now, but we have to finish the base MIME document now. We're up
against a deadline. There is also no problem in adding 10646 (or Unicode) to
MIME at a later point. Since we cannot have it in there now and there's no
problem with adding it later, I don't see why this is at all worrisome.
8859-1, on the other hand, is a standard. There are no liklies about it. People
are using it now. Even so, full support for 8859-n is not a MUST in MIME.
It is also clear to me that RCF-CHAR will never be an ISO standard.
I see no need to ever support it as anything but an X- charset.
RFC-CHAR should not be viewed as an alternative to 10646. It is, rather, a way
of using most (and perhaps all) of the 10646 repetoire on equipment that does
not support full 10646. While it is true that mnemonic can be classified as a
character set, this is largely a convenient category rather than an exact
description of what it is.
RFC-CHAR is also a tabulation of many of the character sets in the world and is
effectively a guide that shows how to convert them to 10646 as well as
mnemonic.
Since there is presently no equipment that supports 10646 (by definition since
there is no such thing as 10646), and any realistic estimate of the time it
will take to adopt 10646 after it is standardized is most readily measured in
decades, I tend to view RFC-CHAR and similar proposals as absolutely essential
to the long-term success of 10646. They provide the all-important bridge
between what we have now and what we want to have in the future.
Regardless, I don't think standardizing RFC-CHAR quickly so that we can
reference it in MIME is appropriate. It should proceed at its own pace without
impeding MIME or vice versa. This is simply good engineering.
Ned