>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" <[EMAIL PROTECTED]> writes: > > ----- Original Message ----- > From: "David Hopwood" <[EMAIL PROTECTED]> > > -----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). > > > > > > <[EMAIL PROTECTED]> 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 > >
