Re: [idn] WG Update

[liana.ydisg@juno.com]

From processing point of view, they are mappings
from one code point to another code point in 
[nameprep], it doesn't matter what the code 
point is.  It does not increase complexity nor 
decrease it.  In this sense, case folding or not is 
the same to every script. The matched values are
represented only in [a-z0-9].

On the other hand, when we speak about how to 
treat the code points, that is which one maps into
the other is linguistic issue. ( I hope at this point, 
no one dispute this with me anymore. :-)
If this is in a requirement to be discussed, then it has 
to be specific on different effects to different types
of scripts, otherwise there are little specifics to be a
useful study.  We can be here argue for Latin but not 
TC/SC forever.  To ask for more protocol to be provided 
is a good exercise for  the authors thinking through 
many different script use issues.  I suggest this to be
modified to "provide discussions on at least three different 
language users on how to implement the requirement, 
and among the three, one must from Alphabet language,
 one must from CJK languages and one must from 
the author's native language. "

Liana

On Mon, 8 Oct 2001 08:52:22 +0800 "tsenglm@????.??.tw"
<tsenglm@cc.ncu.edu.tw> writes:
> 
> ----- Original Message -----
> From: "David Hopwood" <david.hopwood@zetnet.co.uk>
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Erin Chen wrote:
> > > As in the 2. General Requirements of 2.3 Canonicalization
> > >
> > > [21] In order to retain backward compatibility with the current 
> DNS,
> > > the service MUST retain the case-insensitive comparison for 
> US-ASCII
> > > as specified in RFC 1035. For example, Latin capital letter A 
> (U+0041)
> > > MUST match Latin small letter a (U+0061). Unicode Technical 
> Report #21
> > > describes some of the issues with case mapping. 
> Case-insensitivity for
> > > non US-ASCII MUST be discussed in the protocol proposal.
> > >
> > > I recommend modify the last line "MUST be discussed" to be
> > > "MUST be provided", as to be " Case-insensitivity for non 
> US-ASCII MUST
> be
> > > provided in the protocol proposal"
> >
> > I disagree. As it happens, all of the proposals provide 
> case-insensitivity
> > for non-US-ASCII, but it is *not* a requirement. The protocol 
> would work
> > fine and would be perfectly acceptable to users without it. We 
> should be
> > clear about the difference between features that are *desirable* 
> (in this
> > case for consistency), and *required* features.
> >
>               I  think the requirement in case-insensitives for 
> non-US-ASCII
> should be specified in applied rang of UNICODE , that is only 
> applied to
> "Han" characters only.
> > In particular, preservation of case is wholly unnecessary, IMHO.
> > [21] is perfectly OK as it is (although much of the rest of the
> requirements
> > draft is not; I'll discuss that in another post).
> >
> >
> > <tsenglm@csie.ncu.edu.tw> wrote:
> > > The TC/SC equivalent class is always conceptually described by 
> the
> > > similar properties of  case in ASCII characters, ...
> >
> > No, it is not. TC/SC folding is an entirely separate issue to case
> > folding. As I've pointed out before, it is counterproductive to 
> try to
> > argue by an analogy that a consensus of the WG does not accept.
> >
>          Right !  Describing TC/SC with the term "case folding" will
> produce confusing .  TC/SC equivalence class will be translated to 
> ACE ASCII
> with CASE , so it can be caseinsensitive comparison  and  also be 
> recoveried
> to their original scripts form .  In this siyuation , it is very 
> different
> from pure-ASCII characters case folding.
> 
> L.M.Tseng
> 
>