David,
I need to slip on my Area Director hat and inject a few policy
statements into this evolving discussion. I want to stress that they are
policy statements, and not technical ones. Discussion needs to continue
on the technical issues until something reasonably approximately
consensus is reached. I don't think anything here contradicts what
Nathaniel and Ned told you.
(1) Please be very clear about whether you are discussing UNICODE or IS
10646-1:1983 ("BMP", henceforth in this note "10646"). While the code
point mappings are the same, the introductory and conformance texts
appear to be different. It will be much easier for you to pick one and
use it than to prove that the two are the same and therefore, the two
can be taken as equivalent. There is a deliberate bias in MIME toward
use of the ISO standard, so take that as a preference unless there are
strong reasons for using UNICODE.
(2) 10646 does not specify the presentation order of characters on,
e.g., a screen, relative to characters in the data stream. For
languages whose characters are read from right to left, this implies a
profiling issue, since there are several methods in use of writing the
characters of those languages into the data stream. This issue was
addressed in a special review at the Houston IETF and the conclusion was
that the character sets used with Hebrew and Arabic should be registered
three times each, to correspond to the presentation orders defined in
the relevant ECMA/ISO standard. A "charset" definition for 10646 must
address this issue or it doesn't meet the profile-free MIME requirement.
(3) Your text includes the statements:
The United States bodies X3L2 and X3V1 have recently developed a
character/glyph model whose main purpose is to clarify the use of these
terms and provide examples of their usage. This character/glyph model was
developed at the request of the relevant ISO bodies and has been forwarded
both to SC2 and SC18 for formal approval.
As a general rule, IETF is very nervous about basing our work on
something that is halfway through the ISO process. That rule has been
strongly reinforced, probably to "showstopper" level in this particular
area by the history of 10646. When MIME was first being designed, the
working group was told, essentially, that 10646 was a done deal and
should be IETF-standardized on the basis of the DIS. Unfortunately,
that was DIS-1, and the turmoil DIS-2 and the current Standard had yet
to happen and was, at that time, unexpected.
Consequently, if the definition you are proposing depends on an emerging
piece of work in JTC1, and the quality or utility of that definition
would be changed significantly if JTC1 decides to do "something else",
your efforts are likely to go into IETF-hold until JTC1 does something
definitive.
(4) As Nathaniel mentioned, the use of 10646 was specifically intended
as soon as it settled down enough to be adequated defined. It was not
included in-line in RFC 1521 and its predecessor along with US-ASCII and
the 8859 group only because those definitions were not in place.
Precisely because it is considered very important, you should assume
that we will want to place any definitional, external profiling, or
restrictive information that goes with MIME use of 10646 on the IETF
standards track.
--john