[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New UTF-7 draft
- To: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
- Subject: Re: New UTF-7 draft
- From: Borka Jerman-Blazic <jerman-blazic@ijs.si>
- Date: Mon, 28 Mar 1994 10:13:27 +0200
- Cc: David_Goldsmith <David_Goldsmith@taligent.COM>,ietf-charsets <ietf-charsets@INNOSOFT.COM>
- Conversion: Prohibited
- In-reply-to: <9403250158.AA10139@necom830.cc.titech>
- X400-Content-type: P2-1984 (2)
- X400-MTS-identifier: [/PRMD=ac/ADMD=mail/C=si/;940328101327]
- X400-Originator: jerman-blazic@ijs.si
- X400-Received: by mta kanin.arnes.si in /PRMD=ac/ADMD=mail/C=si/; Relayed; Mon,28 Mar 1994 11:15:07 +0200
- X400-Received: by /PRMD=ac/ADMD=mail/C=si/; Relayed; Mon,28 Mar 1994 10:13:27 +0200
- X400-Recipients: non-disclosure:;
I have not read the new draft yet. This is general comment to John's
letter.
>David, as we have discussed privately, the _experimental_
>question of whether Unicode and some encoding for it are
>appropriate (unmodified and without further qualification/
>profiling) for broad-based internet use is separable from the
>similar question about 10646. For Unicode, one of the important
>questions is whether it is comprehensive enough in terms of
>characters represented and distinctions made. For 10646, one
>opens up, as Ohta-san has pointed out, all of the problems of
>dealing with an extensible standard/family of standards and the
>special one of dealing with one of those when the extension
>model is not yet established (we at least know the extensibility
>parameters for 2022).
To my knowledge UNICODE v.1.1 is the same as ISO 10 646 MBP. With
specification about the level of use of ISO 10 646 i.e Level 1 and
the version of the Basic Multilingual Plane no distinction can be
made between Unicode and ISO 10 646, but the problem is somewhere else
and it is similar to ISO 2022. We know the extensibility of ISO
2022 parameters but we don't know how much additional parameters have
been invented and how much different character sets are on that way
supported. I can not imagine that a simple and widely used client
application to support all possible ISO 2022 parameters and character
sets as I can not imagine a client application to support the whole
BMP and all levels of ISO 10 646 or UNICODE. So, subsetting of
ISO 10 646 is on the way and definition of object identifier for
applications based on ASN.1 is also underway. Having this subsets
registred and well defined (or profiled) then we can go further towards
definition of rules for general use of that standards.
>Ohta-san, David is proposing an experiment right now, not a
>standards-track document. Experiments are much more the IETF
>way of doing things than arguments from logic and theory. There
>is no applicability statement proposed that says "use this";
>there is no plan at the moment to push the thing onto the
>standards track. The _experiment_ will either succeed or fail,
>both in terms of who decides to use it and in terms of what
>problems they do (or don't) run into.
I will support this idea. Experiments and gathered experiences with
both approach and in different environment (Korea, Japan and Isreal)
can contribute to the common footing and general agreement regarding
international character sets use in Internet. We need not to forget that not
just e-mail and MIME have to be supported in multi-lingual exchange
of data. In Internet are other generic services which require to be
also fully multi-lingual. So, the experiences of our colleagues are most
wellcome.
>Even if we wanted to, there is no mechanism for either of us to
>prevent him from proposing that experiment and carrying it out.
>From the standpoint of [my understanding of] your position, the
>best thing to do would be to focus on getting his proposals to
>be as clear and precise as possible so that the results can be
>objectively analyzed.
I would add to that: not just clear and precise but also acceptable for other
parts of Internet.
Borka