RE: General policy

[Masataka Ohta <mohta@necom830.cc.titech.ac.jp>]

> The important "2022 is not a character set" principle, in the MIME
> context, derives primarily from the fact that one cannot deduce from
> knowing that a text body part is "in 2022" what graphics will be needed
                                             ^^^^^^^^^^^^^^^^^^
> and what registrations will occur.

> In this context, and for MIME, the labels that would have been
> associated with 10646 DIS-1 or -- if one believes in Han unification -- 
> UNICODE or IS 10646 BMP pose no particular problems (although the more
> paranoid among us might insist on a date as part of the label):

Wrong.

10646 level 2 or level 3 is explicit in not defining "what graphics
will be".

Also, without knowing which of CJK character is needed, one can not
deduce from knowing that a text body part is "in 10646" what graphics
will be needed.

> These
> provide Standard character code tables, whose content and required
> graphics are known at time of publication

Required graphics? Allowing combining characters and saying that the
graphics of the combined result is undefined can not mean "required
graphics are known at time of publication".

Also, listing 4 different and incompatible graphics for a single code point
for CJK Hans in section 26 of 10646 can not mean "required graphics are
known at time of publication".

> and revised very infrequently
> and usually compatibly.  

As you have pointed out as for changes in private areas, ISO, in general,
does not have much interest in maintaining backward compatibility.

> But "unrestricted 2022" or "IS 10646 including planes and groups not yet
> defined" are much harder to label in a useful way since it is difficult,

Of course, "unrestricted 2022" or "IS 10646 including planes and groups
not yet defined" are not good enough.

But, unrestricted 2022 of good old days is much better than unrestricted
10646 because, in 2022, graphics is at least unambiguously defined by
refering to the corresponding national standards. The problem is that,
both 2022 nor 10646 does not provide unified way of internationalized text
processing. But, 2022 is much better as the way for national text processing
is defined by each national standard bodies, while with 10646, almost
nothing is defined.

Anyway, I don't think anyone in this ML is interested in such broken ISO
thingy as the ultimate encoding.

> Note that I'm trying to state a problem here, not suggesting an answer. 

Judging from the "Subject:" we should be discussing on the general
policy of this "charsets" ML, shouldn't we?

> But I do suggest that anything that proports to be a definition for
> "full 10646" in the MIME context must address this issue.

I think '"full 10646" in the MIME context' should be discussed in
822ext ML.

						Masataka Ohta