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

RE: BOF minutes

> 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