Subject: [idn] nfc/nfkc/case mappings are freezed up ?

From: "Soobok Lee" <[email-masked]>
Date: Wed, 24 Oct 2001 14:52:38 +0900

Mark and Martin and Doug,

Case mapping / NFC /NFKC tables are already freezed up and will
remain unchanged forever even with future newly added scripts ????

There is no need to modify or upgrade all the tables?
Congratulations on the birth of the perfect baby if Doug's assertion is right.
Please clarify.

Soobok Lee

----- Original Message ----- 
From: "Soobok Lee" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 24, 2001 2:40 PM
Subject: Re: [idn] (bias) summary of reordering discussion

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 24, 2001 2:37 PM
Subject: Re: [idn] (bias) summary of reordering discussion

> In a message dated 2001-10-23 22:16:54 Pacific Daylight Time, 
> [email-masked] writes yet again:
> 
> > let's assume new nameprep with new added script  which contains mapping 
> X-->Y.
> 
> No, let's not assume this, because UTC/WG2 have said repeatedly that this 
> will not happen.  I keep saying this, and Soobok keeps ignoring it.

What if X->Y is a Case mapping ?
You said case folding would happend in the future added script ? Didn't you?

Soobok Lee

> -Doug Ewell
>  Fullerton, California

---

From: Martin Duerst <[email-masked]>
Date: Wed, 24 Oct 2001 17:39:20 +0900

>There is no need to modify or upgrade all the tables?

There may indeed be a need to upgrade some of the tables.

For casing, you usually would add both lower and upper case
at the same time, and add that to the table. The way nameprep
is currently designed, the lower case form of the new characters
could be used with old client software. There would be a need
for a client upgrade to use uppercase letters from the new script.
This seems to be a reasonable tradeoff.
But anyway, as far as I know, the scripts in the pipeline are
single-case only, so this is only theory.

For NFC, there is the change that e.g. some new precomposed
character is added. This chance is very low because the Unicode
consortium is on record that it won't do it. But assume it
happens; assume q-cedilla get's added. Then what would happen is
that a decomposition q-cedilla -> q, cedilla gets added to the
big data file, and in addition, q-cedilla gets added to the
so-called composition exclusions.

Now an old application will only know about q and cedilla
and will use these to represent the combination. A new application
may know about the new character q-cedilla, but it would then
also know how to normalize that, and because of the composition
exclusion, it would normalize to q, cedilla, i.e. stay decomposed.

So in both cases, you get the same decomposed result.

Regards,    Martin.