Re: [idn] Re: stringprep and unassigned code points

["Soobok Lee" <lsb@postel.co.kr>]

----- Original Message ----- 
From: "David Hopwood" <david.hopwood@zetnet.co.uk>
To: "Yves Arrouye" <yves@realnames.com>; <idn@ops.ietf.org>
Sent: Tuesday, October 30, 2001 10:35 AM
Subject: Re: [idn] Re: stringprep and unassigned code points


> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Yves Arrouye wrote:
> > Honestly, I do not see any other way than to upgrade everybody to a newer
> > Nameprep when the mapping tables change for new code points.
> 
> New unicameral scripts (without case distinctions), that have no NFC/NFKC
> mappings can be supported without any changes to nameprep. That leaves
> bicameral scripts, and scripts that have NFC mappings, i.e. they have
> both precomposed and decomposed characters (compatibility mappings for
> new scripts are extremely unlikely). In order for those scripts to
> be used at all, 

  An old nameprep browser suggests a (newly added) TAGALOG web link in a web page
    <a href=http://<native tagalog>.com/>Hello, world!</a>
  and the end user clicks the links.

  In that case, the old platform does not need  TAGALOG IME and font sets to make
  a query. Should old nameprep webbrowsers encode unassigned code points 
  (to be tagalog) to ACE labels without tagalog-related nameprep mappings ?

  There will be many offline/non-interactive/in-house nameprep applications that 
   fall into the same category as this webpage input mode of webbrowser.

  Soobok Lee

> the client's operating system will need to be updated to
> support a new version of Unicode. If the OS provides case folding and
> normalisation functions [*], then old applications calling the new
> functions will work fine. Even if the OS doesn't provide all of the
> needed functionality, it could do in new versions, and an IDN library
> could use the OS whereever possible, falling back to its own
> implementation otherwise.
> 
> Of course this requires that nameprep is defined strictly in terms of
> standard Unicode mappings and properties. That is possible if we use NFC,
> and define the disallowed characters in terms of Unicode character
> properties (note that no "additional mappings" are needed to make
> casefold o NFC idempotent, I think; I've recently asked on the Unicode
> mailing list to confirm that).
> 
> [*] Win32 does for NFC normalisation, I'm not sure about case folding.
> 
> - -- 
> 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
> 
> iQEVAwUBO94D0TkCAxeYt5gVAQF6ygf/TAc63TwyAyNFZIv3kPS/m2Y+2+k8qhwf
> aZz1uzodGofF6kXamHOMT4h/JzwH8luKm3mJP7dJ8dPlMoN+ZFVQqSmNULYDknND
> Cy7f0H/W6usAKNOBCu+MqNKkD+S7sCdUz8kWFVftykmyM/aaKyK4y0ahvtvMjLq1
> EQMpkCOZe2q2q/OW7x9dprvV1JxsxL31NP7LysYdOzpg0S6jY9uehBWH5TM1+Zko
> 3SD0GC4vjiH9XHYDp+JQ0bBY8dMLR3Y8EKxCZUTnrRpM6Ygjn6X3xi5q95UWFiic
> gvl97efDZ1EZWz03Ns1T7oRwEYBfMD3oaLuhsqz+4G5c9YAHNMIExQ==
> =PDXw
> -----END PGP SIGNATURE-----
>