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

From: David Hopwood <[email-masked]>
Date: Tue, 30 Oct 2001 01:35:34 +0000

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

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 30 Oct 2001 12:43:17 +0900

----- Original Message ----- 
From: "David Hopwood" <[email-masked]>
To: "Yves Arrouye" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 30, 2001 10:35 AM
Subject: Re: [idn] Re: stringprep and unassigned code points

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

---

From: David Hopwood <[email-masked]>
Date: Tue, 30 Oct 2001 04:52:41 +0000

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

Soobok Lee wrote:
> David Hopwood wrote:
>   An old nameprep browser suggests a (newly added) TAGALOG

Tagalog is a unicameral script with no NFC/NFKC mappings, so there's no
point in using it as an example. That also applies to the other 3 scripts
added in Unicode 3.2.

>   web link in a
>   web page <a href=http://<native tagalog>.com/>Hello, world!</a>

(BTW, strictly speaking neither RFC 2396 nor HTML 4.x allow non-ASCII here.
There wouldn't be any problem with relaxing this restriction, but I just
thought I'd point it out.)

>   In that case, the old platform does not need TAGALOG IME and font sets
>   to make a query.

However, the platform on which the HTML file is created does. Therefore
whatever process creates the file can apply nameprep to the hostname, and
the rest of the argument in my previous post applies to that.

Of course, the HTML file might be created by a general-purpose text editor,
or by an old HTML generator that doesn't conform to the IDN specifications.
However, that doesn't present any great problem: HTML files are already
required to be NFC-normalised, and compatibility mappings are not an issue
for new scripts, so all that remains is to make sure that the hostname is
case folded. In practice, that just means not typing it in uppercase.

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

In all cases, the process that encodes the hostname is responsible for
applying nameprep, not the process that makes the query.

- --