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

[David Hopwood <david.hopwood@zetnet.co.uk>]

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

liana.ydisg@juno.com wrote:
> 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].

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 <david.hopwood@zetnet.co.uk>

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


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBO3twITkCAxeYt5gVAQGCrgf8CbjaVd8ihghg7QZSpeDg5zGBXq+NuJgz
scgLo+1d1L/xyVMqXP6INqashL7nCMYn8NslwGMgzk9N8NAvXvV81KE0qdOuGhMq
BMM2tCexcIFsg35llJGA1m0B7CHtDQYLXW4HxfD19d+KVfE6A7f2TMlAUQobR5zB
A/CcQ7X1aWomXKAqM6hZ+3K9RCOeGTijSqYjM00T3ArfmSxiBRUXPUVxaBjcmLd/
GbE4wydLWEMyItxCOFg/wT7yw4nqar9WVZ9xT0JhLMcIuNt8ImN7j6PCY/Oudd8G
yfBwaJxQGltt10i3Yr+bBff8+Zr6FuCaoV1yJ9KEzYvijbm7Ix2Mgw==
=OXdg
-----END PGP SIGNATURE-----