[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] opting out of SC/TC equivalence
On Thu, 16 Aug 2001 08:03:25 +0100 David Hopwood
<david.hopwood@zetnet.co.uk> writes:
> -----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.
Because there are large existing user base using particular
national standard, and the users do not want download
anything large and they do not want to use. For example,
the users in China are happy with their GB coded software.
In such a case, it is the server doing the IDN. Other new
users can use a new IDN, Unicode enabled software directly.
> 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.
So, there will not be any consideration for CJK users as it was
in DNS system?
>
> 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).
>
What is your definition of "artificial differences"? Could you give me
some specific examples?
Liana
>
> 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-----
>
>