[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: BOF

> Let's finish this useless discussion!

As there is no such thing as "the general stream of the development",
discussion on it is not so useful.

On the other hand, discussion on terminology could be useful especially
when people have different idea on the same terminology.

Especially, it is quite important that the ultimate solution is not 16 bit.

It was agreed in the BOF that the ultimate goal is 32 bit.

> >It's much better to argue first on what we are working before we start
> >working.
> 
> Agreement can be achieved without contra-productive arguing!

Eliminating something from the beginning based on purely scientific
reasoning is the productive way.

On the other hand, targeting everything and try to politically resolve
later contradiciton is the most contra productive way.

> You are arguing about nothing! There is no difference between the wording
> in the BOF and what you are saying, the only "mistake' is that in my
> explanation to you I have used 16-bit term vs ISO 2022 instead of ISO 10 646.
> O.K. This was just explanation and that term was not maybe the most appropriate.

Of course, your mistake is so serious that I can't argue anythign here other
than correcting your mistake.

> >What someone is doing with 16 bit is to use bare, ASCII incompatible
> >16 bit encoding, where ASCII 'A' is, for example, represented with
> >two octets: NUL and 'A'.
> 
> >OK?
> 
> No, it was you suggesting on the BOf the use of 16bits coding (not full
> ISO 10 646) with addition of 5 bits and not the other people.

You still don't understand the difference between UTF and bare 16 bit
encoding.

IT IS THE SERIOUS MISUNDERSTANDING.

UTF is the form for information exchange. OK?

It may or may not be equal to the form for internal processing. OK?

What I proposed was IUTF, a variant of UTF, whose internal representation
ICODE was, AT LEAST but not necessarily limited to, 21 bit.

> >After that, no one said 16 bit.
> 
> >OK?
> 
> Could you understand that 16-bits was used somehow as a synonim for the
> way ISO 10 646 is coding a character (row/cell)??

Wrong. Your statement is completely unfounded.

> >The attendees agreed to develop something based on 10646. My impression
> >is that the attendee preferd ASCII compatible approach.
> 
> Maybe you are right but I have not seen any further complain regarding the
> minutes except you.

I have not seen any complaing regarding my comment except you.

> I discussed your summary of the BOF with some other
> people and got confirmed my view that it was not correct.

There is no such thing as your view in charsets mailing list that my
summary is incorrect.

If you think I'm wrong, say so quoting appropriate part of my opinion.

Or, everybody in the ML assumes you don't disagree with me.

> >The point here is that MIME approach is not the existing stream. Though
> >I don't think it so good for general purpose, it ratifies existing practices
> >in Japan, Korea and other countries.

> But we are not discussing MIME here, don't we??

No, of course. Not MIME specifically. The point is that MIME and several
other encoding methods are ones of the streams of development.

> >> And again RFC 1345 is ISO 10 646 based!!

> >It's character mnemonic, except for Han characters, is 10646 based.
> 
> So, what is wrong with what I have said.

RFC 1345 is not based on 10646.

> I have seen some countries complaining
> about RFC1345 not to be applicable for their languages because is not
> readable. But, we are not supposed to discuss here MIME and MNEMONICS?

We are not supposed to discuss here on specifically on RFC 1345, at all.

						Masataka Ohta