[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Character set issues for MI
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 <firstname.lastname@example.org>
> >BTW, is your ISO-10646-UNICODE big-endean, little-endean or bi-endean
> >with 0xff00?
> 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?