Subject: Re: [idn] opting out of SC/TC equivalence

From: [email-masked]
Date: Thu, 16 Aug 2001 08:29:28 -0700

The following SC/TC equivalence comtains a mistake:

	IDNA?			[nameprep]?		ACE
GB > Unicode SC
Big5>Unicode > SC Unicode	Latin Case folding	ACE encoding
Mixed Unicode > SC Unicode	

and it should be:

	IDNA?			[nameprep]?		ACE
GB > SC Unicode 
Big5>SC Unicode		Latin Case folding	ACE encoding
Mixed Unicode > SC Unicode	

So, the proposal is:

	[nameprep]			ACE
GB > SC Unicode 
Big5>SC Unicode			ACE encoding
Mixed Unicode > SC Unicode	
Latin Case folding
JIS > SC Unicode
KSC > TC Unicode
ISCII > Indic Unicode

There are limited number of standards which is referenced 
by Unicode standard, where we can allow limited number of
them to make into [nameprep].  

Liana

---

From: David Hopwood <[email-masked]>
Date: Thu, 16 Aug 2001 08:03:25 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> them to make into [nameprep].

Why would we want or need to make any restriction on other charsets that
can be mapped into Unicode? A name is assumed to be expressible as a
sequence of Unicode characters; that's all that is required. nameprep
is a step that is applied to labels *after* expressing them in that way
(so that if a label contains both alphabetic and ideographic or syllabic
characters, for example, case folding will apply to the alphabetic
characters). There is no difference in treatment of labels according to
which charset they may originally have been encoded as.

The only technical requirement needed to make this work is that nameprep
folds at least canonically equivalent strings, so that there are no
artificial differences introduced by transcoding, and so that
NFC-normalizing transcoders can be used (as recommended by the W3C
character model).

In any case, do we have a concensus on the following point: that any
TC/SC folding will not be implemented in nameprep? ('nameprep' here
refers to whatever client-side canonicalization algorithm is applied
automatically to all names.) That is the only thing we need to decide
about TC/SC equivalence as far as the protocol definition is concerned.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip