RE: BOF

[Borka Jerman-Blazic <jerman-blazic@ijs.si>]

>> I went very quickly over Ohta san comments on the BOF Minutes and find out 
>> that even he agree on the common issues to be worked out.

>Even me? Good joke. Anyway,

But you are arguing all the time about everything and I still don't have
clear mind what you really want to happen.

>> Do you know any other scheme of development of character sets code on
>> international level? I do not.

>	Full ISO 2022
>	EUC
>	compound text of X consorcium
>	ISO-2022-JP-2 (recently deveolpped and will soon be announced)

>are ISO 2022 based character sets.

I got the impression that Harald's proposal to follow one of the existing
streams (ISO 2022 or ISO 10 646/UNICODE)
for support of character sets required for different languages
was accepted as the stream to be followed. Harald presented two streams:
16-bits and ISO 2022 stream. The last apperaed to be too complex and more
difficult. It was not precisely elaborated but I understood that the other
one - i.e 16 bits was prefered by the attendees.

If we can not agree on neither of them then what do you propose.
Supporting both is maybe not the best approach. Let's see what the
other concerned people have in mind: both stream or only one, ISO 2022
or ISO 10 646.

>Also, with charset scheme of MIME, various non-2022 codes are defined
>in RFC1345 (they are not currently valid MIME names, but it could be if
>some desires so). Several other are developped in various countries.

RFC 1345 in MIME context was heavily discussed on 822ext list and final
standpoint was issued by IESG a few months ago, so I do not want 
to rise again the RFC 1345 and MIME issue again. Please don't ask for that.
And again RFC 1345 is ISO 10 646 based!!

>As for 10646, ISO says, as always, everything. 10646 could be used with
>UCS2, UCS4 or UTF1 with arbitraly any subsetting.

That is why we need to define and agree what will be acceptable on Internet.
That was the purpose of the BOF besides other relevant issues discussed
on the BOF.

>I don't know precisely what X/Open is doing but they should be using
>UTF2.

To my knowledge X/Open is using UTF2 and is working on its promotion.
It will be registred somehow in ISO too.

>Plan9 support only 16bit of 10646 with UTF2, though its handlig of the
>32-th bit is somewhat different from what X/Open says.

>Microsoft also support 16 bit only. It use bare 16 bit representation (maybe
>with little endean in octet serialized files). It does not support all Han
>characters (JIS only in Japan). They also support existing MS Kanji code
>(so called shift JIS) in Japan.

>How is apple? I won't be so much surprised if they use big endean in files.

O.K. what is your proposal?


>> What is the problem with the text of the BOF?

>The problem (full bidirectionality support can not be done with finite
>state and, thus, not plain text) is identified by me and then discussed,
>I think. But, if you think there is other bidirectionality problems
>identified, it's OK.

Have you seen the latest RFC draft on handling bi-directional 
text in MIME submitted by Nussbacher?


>> I do not mean anything. We just pointed out the most concerned services
>> based on plein text and that is all about. We did not suggest any solution!

>So, could you explain how is the most concerned services? I just want to
>know, because I don't think we can seek the solution for all the
>multilingual problem here now.

The services concerned were identified by Haralad already (GOPHER, FTP 
FILE NAMES, WHOIS, WWW, DNS). The idea was the ch.sets issues (I think that
was mentioned by Simon Spero but I am not sure) to be handled "in general"
as security issues are handled in the emerging RFCs.

>As for the character encoding scheme, I think we should make the scheme
>with which all the languages in the world can be encoded/decoded even
>if dozens of languages are mixed freely within single text.

Yes, of course.

>But, should we address the further multilinguality issues? For example,
>specifying 8859-1 does not mean one can accept both English, French and
>German. Should we develop protocols to treat that type of multilinguality
>now?

With ISO 8859/1 you can not write text in French, the ligature oe is
missing and ISO 8859/1 is too restrictive even for european languages
which script is based on the latin alphabet. 

>I think we shouldn't until we have an agreed ultimate encoding scheme.

Probably.

>I think the input issue will be much more important within 3, 5 or maybe
>10 years when terminals without full graphic capability disappears with
>mainframes (which does not mean we don't have to address the output issue
>now). And, then, the commonly available keyboard will still be ASCII. So,
>could you make it explicite?

Yes, and we are working within C3 project on that problem and in the
same time in the CEN TC 304 committee. Paper and sw will be submitted
soon.

> >>> -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.
> 
> >O.K. Let us try. Maybe the problem is so difficult and we will not come to
> >an agreement but what is your proposal?

>I don't think the problem is technically difficult. I have no proposal.
>So, do it, if someone want to do.

I agree with you that the problem is not technically difficult. It is
more "political", but there are people thinking about it.

>But, as I want to have a single, general purpose solution so that each
>protocol does not have to worry about character set issues, I don't
>think I have to do it by myself.

No one is expecting from you to do it yourself but you have a proposal
don't you??

Borka