RE: BOF

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

Let's finish this useless discussion!

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

>I want to clarify the purpose.

O.K

>It's much better to argue first on what we are working before we start
>working.

Agreement can be achieved without contra-productive arguing!

> >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.

>I'm afraid you don't understand what UTF is. YOU said:

>>> - 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.

>UTF-2 is ASCII compatible, 8 bit oriented encoding scheme of 32 bit UCS4.

>It is absolutely not 16 bit.

>OK?

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.

>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. Harald 
was explaining the two streams i.e ISO 2022 vs ISO 10 646. 

>In the BOF, I explicitely asked whether we need ASCII compatibility or not
>explaining that ASCII incompatibility means we must label protocols
>(existing one's and upcoming one's) whether they are using ASCII or
>something else.

>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)??

>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 discussed your summary of the BOF with some other
people and got confirmed my view that it was not correct.

>> If we can not agree on neither of them then what do you propose.
>> Supporting both is maybe not the best approach.

>Supporting both is the worst approach.

Here you are quite clear!

>> >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.

>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??

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

>Could you read it?

>It's character mnemonic, except for Han characters, is 10646 based.

So, what is wrong with what I have said. 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?

>But, it is a collection of MIME charsets (sorry Keld to have misunderstood
>that they are not registered) including 2022 and EBCDIC.

>> >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.

>The problem is just saying UTF2 does not have enough precision.

>10646 is too vague.

O.K, but it was one of the purposes for invating the people to the BOF.
Because 10 646 is too vague and because just saying  UTF2 does not give
enough precision we had the BOF. BOF minutes do not imply anything final.
They just indicates that some work has  to be done. Don't you understand that?
The charter of a WG indicates more precisely what is the goal/aims of the work.
I thought that is enough clear to you. 

> O.K. what is your proposal?

>My proposal, on what we should work on, is to have a general purpose
>text encoding schem based on 10646 for international infomation exchange.
>With the scheme, all the languages in the world can be encoded/decoded
>even if dozens of languages are mixed freely within single text. The
>scheme should not have long term state or initial labeling, because it
>makes the scheme just as complex as 2022.

O.K

>The scheme could be better if it has several othere properties, but, I
>think it should be discussed later after we agree on the general policy.

O.K


>> 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.

>If we create something too ambiguous so that it can not be used without
>protocol-wise profiling, we, indeed, need such protocol-wise discription.

O.K


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

>So, if we, like ISO, successfully created a chimeric monster, I will
>actively agree that protocol-wise specification is necessary.

O.K, but how do you know in advance that we will create a chimeric monster??

Borka