[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] IDN rechartering rev 3, and nameprep



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

Dave Crocker wrote:
> 
> There has been no further discussion about the revised charter, for more
> than one week.  That suggests that it is time to adopt it and send it to
> the IESG.

> Goal & Milestone:
> Nov 2001        domain name identifiers normalization draft last call

This is completely unrealistic. There are many unresolved issues concerning
normalisation.


Here is one of them: the current nameprep draft doesn't always produce
identical results for two canonically equivalent names.

For example, "\u1F70\u0345" and "\u1FB2\u0300" are canonically
equivalent strings representing 'alpha with varia and ypogegrammeni'.
However:

  NFKC(fold("\u1F70\u0345")) = "\u1F70\u03B9" (alpha-varia, iota)
  NFKC(fold("\u1FB2\u0300")) = "\u1F70\u1F76" (alpha, iota-varia)

This could be fixed by using the "simple" versions of case foldings for
characters that include ypogegrammeni or prosgegrammeni, and removing
the folding for U+0345. (It isn't actually important to consider
ypogegrammeni to be equivalent to iota, but uniform treatment of
canonically equivalent strings is definitely important.)

Other issues relating to normalisation are:
 - whether to use NFKC or NFC
 - what set of characters to disallow (the current spec arguably
   allows too much)
 - treatment of Hangul compatibility Jamo
 - the point raised by Kent Karlsson about Jamo clusters
 - the definition of "stored" and "request" strings in stringprep

I frankly don't see how normalisation can be finalised without knowing
which protocol proposal will be used, or why it's necessary to finalise
it before then.

- -- 
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

iQEVAwUBO/BpvDkCAxeYt5gVAQHMTAf/W9dGXL/h7Bs2r4BBxluAz24wjIf7tyw1
ncVJCyaqIzgjel2mZWLGUib0h3RVEuVZDQKu7/X07pmL/Tkzaw+EoRVu0TUDNmdd
s6pFR0SMf8y6WIRPEcnn2y6iMOPIi5fE7LlRr5yYvixhPSgTgpQZuECMch4WV10c
dK0mh7fwNiq57mionqvLzMz15G/olyFhRKK5DtAOIyZwPVvAhCFSwZ+BM1YvmvsX
qtZz1VQJD4pdKcGzZZmUWEMq2bG6pZWhkQMYQxyQJJLKLl2oI2zaPWgANRcEyOA6
MxC2/VW12w5fEkjfLxU6TwiLZrM8zpPY2EpUaJzY2ZQgpUvi+Hrkzg==
=TUjr
-----END PGP SIGNATURE-----