The "Subject:" header is quite irritating.
Do all the people in unicored think 31 ASCII characters are more than enough
for all the possible "Subject:"?
I know unicoders foolishly think 16 bits are more than enough for all
the possible characters in the world.
Character set issues for MIME/10646
From: Masataka Ohta
BTW, is your ISO-10646-UNICODE big-endean, little-endean or bi-endean
As specified by ISO 10646 and in the documents I distributed, it is big
ISO 10646 says two things: "bigendean is the must" and "any endean is OK".
I now understand the issue you are raising, and we are preparing a detailed
Please make sure that your "detailed response" is, as short and concise as
Especially I hope it does not contain untechnical reasoning.
However, I will point out that ISO 10646 does not use the word
"glyph" anywhere, and if you interpret "glyph" to mean what the 10646 passages
you quote are referring to (namely, the visual form of a character), then none
ISO 10646 says "graphic symbol".
But, I strongly disfavour untechnical reasoning on how the difference
between ISO 10646 "graphic symbbol" and MIME glyph.
They are only as dirrerent as "A" in ASCII and "A" in ISO 8859-1: that is,
As far as application programs concerns, at least, ISO 10646 "graphic
symbol" is equivalent to MIME glyph. Both are "what is displayed on
of the ISO standards qualify as MIME character sets (including 8859-1 and JIS)
because they contain similar language. All of this will be covered in detail
in our reply.
Though I can't understand who is "we" or "our", please don't do that.
Detailed untechnical debates is too much boring.
This was a good point to bring up because the terminology in
character set standards in general has been a little fuzzy;
The only scientific way to make it clear is to give them
Trying to define something with long detailed debates with no concise
conclusion makes it much more uzzy.
I hope our
forthcoming response will help to clarify things a little.
ISOs untechnical debates only makes the matter worse.
One of the fundamental prolem of the development of ISO 10646 was that
the definition of "Universal" was not given.
Though ISO 10646 must be UCS (Universally ....), it does not give
the defition of "universal".
As a result, someone considered that "16bit encodng space is so large
that it must be universal".
Moreover, participants are like those who designed ISO 2022, proessionals
in one or two langages who knows well how his favourite languages could
be encoded with 94 (96 or 94*94) code points.
Thus, for USC, "no-universal common encoding space" was provided with
language-by-langage policies on encoding.
I would like to point out that the merits of 10646 or Unicode for any
particular purpose are not the subject of this document review; there are
other forums in which to have that discussion.
So, in my reply to you, I tried to choose the issues within the scope
of ietf-822 ML.
The purpose of this document
review is to discuss a proposal for encoding ISO 10646/Unicode within MIME.
ISO 10646 is an international standard, and has been or is in the process of
being adopted as national standards in many countries; it is also starting to
see commercial adoption and use. Therefore, it needs to be dealt with
regardless of other issues.
Just as OSI CLNP is an international standard, ISO 10646 is an international
standard. So what?