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

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

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

Soobok Lee wrote:
> David Hopwood wrote:
> > 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

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>
>   and the end user clicks the links.

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

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

iQEVAwUBO94xzzkCAxeYt5gVAQEtkQf/eT02v1Z+ht6bNJge3+LyHWj4sf8lIAeu
s8bAkwH1NksOBIy6HSYLgaxJOiJFoIAGNyKLsH/ZW5eyOmCdWl0xWGm3+WSz2gW8
OCgLiiGl0T9BuNl+UiXnodcXy27dE5A9leeH2wFHh1EMF0riCGeQPLWaJMDALt5R
TUKsNLbktRguJEep7Dun/2dJ3DSDCSJPs4gYmUtYJQzReB0XvYkImyJxneU9L5U7
waQnnWToSC/j/6kM8GX7ZlZy/7eldVZPqalr74PxlCgBZvGIze5Lnt9FE09CuiMr
69qVJYvyJ53buyRp54MFMKvaoHYDqUbfblYyLCYLi8F4BU1ekyOxoA==
=6dgG
-----END PGP SIGNATURE-----