- From: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
- Date: Tue, 17 Aug 1993 16:38:37 +0900 (JST)
- To: jerman-blazic@ijs.si (Borka Jerman-Blazic)
- Cc: ietf-charsets@INNOSOFT.COM
> He identifyed 5 properties which are required > to be present in the recommended coding system. These are: > Identity for encoding and decoding which he understand as unique > mapping between particular graphic character and its code (bit > combination), > > Causality understanded as independence of a processed coded character > from the other incomming characters in the data stream, > > Finite State Recognition, state dependence of the code required for > presentation/display of multi-octed coded data, > > Finite resynchronizability which means that the state of automation > can be determined uniquely by reading fixed finite number of octets, > > Equality, requirement that a character coded with different coding > system can be always recognized as the same character. > > Mr Ohta looked for the required properties in ISO 10 646 and find out > that the Causality and Finite resynchronizability are not satisfied. > Equality is not yet worked out. No, no, no! I pointed out full 10646 satisfies NONE of the above. I called "Identity" also as "Universality" and, thus 10646 is not universal. I also pointed out ISO 10646 level 1 satisfies all of the above if used only for major European languages. > The > discussion showed that the proposed solution is not in the general > stream of the development of the standard character set codes and > their applications in the computing systems. "the general stream of the development"? What's that? It was only that my proposal was not compatible with UCS4. It is, now. > He proposed an extension to the > existing UCS code system consisting of 5 additional bits which will > enable the deficiency of the UCS coding system to be overcomed. > In the discussion the problem of handling of > bidirectional text was also identified. Handling of bidirectionality is identified by me and solved in my proposal (1 of 5 additional bits is used only for bidirectionality). John Klensin's comment turned out to be a code conversion issue, later. > He also recommended the use of mailing lists > already working within IETF. They are: <ietf-charsets@innosoft.com> > and two others working on mailing issues (822ext and 821). He (John Klensin) has recommended 822ext!!!!!????? Any comment, John? He said we shouldn't use 822ext also at the BOF, I think. > As a summary the BOF decided to propose to IESG to consider the possi- > bility of setting up of a working group to work on the following work- > ing items: I have several comments. > - a document defining how UCS can be used in a uniform way in > Internet protocols, especially taking in consideration the UTF-2 > encoding of UCS. The document will provide guidance to other > protocols which have to deal with these items over the Internet, It was agreed to have some text encoding method based on 10646, but not especially UTF-2. > -a document identifying the languages and the characters required for > coding text written in particular natural language Yes. > (a sort of > guidelines for services dealing with multilinguality such as NIR > service based on usage of plein text), What do you mean? Aren't you assuming MIME-like labeling of character sets each containing only a limited number of characters? > -a document defining a tool for coded character sets conversion to be > provided within some services such as e-mail user agent including > fall-back representation of incoming characters that are outside the > supported character repertoire of the receiver, Yes. Shouldn't we also address input issues for outgoing characters from ASCII environment? > -a proposal for extending the mandatory issues which have to be > covered in the RFC standardization process to include character set > consideration/support. Really? Hmmm. Good luck. Masataka Ohta --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Tuesday, 17 August 1993 00:50:46 UTC