Re: [idn] opting out of SC/TC equivalence

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

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

liana.ydisg@juno.com wrote:
> The first step of our solution is to open [nameprep]
> to let local standards in for easy code exchange.  This
> is an equal access issue.

What is the problem with converting local standards to Unicode
as a first step? There's nothing difficult in that; in fact it's
considerably simpler than what you seem to be proposing.

> The best place to demonstrate
> such a feature is the "cut and paste" of an IDN URL
> e-mail entry.  It shall be a universal treatment at the end.
> 
> The second step is to define the ranges of different
> user groups who need their primary script tag.  No
> mix scripts is allowed at this stage.  But we can take
> wish list.  For example, English may wish to include
> Greek, Korean may want Hanja on its wish list.

Why should there be any restrictions on mixing scripts (other
than mixing left-to-right and right-to-left scripts, possibly)?
What benefit does this give?

>  That way, we can identify conflicts of codepoints and
> possible confusion of codepoints, and start with a
> careful first step.  A survey on the existing registered
> names for possible conflict when Unicode is
> used for limited scripts is helpful to start a clean first
> deployment of [nameprep].
> 
> Someone wants to lunch an unmature version of
> [nameprep] are very smart.  They probally have put
> a lot of money behind this working group already , where
> we are just a decoration voices to lead people believing
> that this is an open discussion, democratic process.
...
> My feeling on this, there are more politics and money
> then technical issues hidden behind us.

Enough with the paranoid conspiracy theories. I'm certainly not
making any money out of contributing to this group, and I doubt
the other contributors are either. There are serious technical
problems with some of the things you're suggesting - that's what
people are concerned about.

> So your first step TC/SC simple mapping in [nameprep]
> which should be on the same footing with Latin case
> folding being pushed away by all kind of nonsense
> arguments.

TC/SC equivalence is not analogous to case folding, period. It's
closer to Cyrillic <-> Latin equivalence for Serbo-Croatian and
Azeri (except that it is more complicated in the general case).
If it was exactly the same as case folding, then we shouldn't
include it, because case folding is only in nameprep for consistency
with the folding of a-z and A-Z in RFC 1034/1035 (which is in turn
only there for compatibility with the original HOSTS.TXT specification).
If hostnames had originally been case-sensitive, that would not
cause any problem for users, who would in practice always type
lowercase.

If there is an argument for doing some subset of TC/SC folding, it
will have to stand on it own merits, not by analogy.

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

iQEVAwUBO48D6zkCAxeYt5gVAQHQjQgAyFhzfEuCiqezWFyJNadIQ8RAjEjEVChM
3HRaC72TGQllSjjhgyYjCWheitDCI5jWNePjXBN7LDBgeZyTVPjONd4HzzAKBXOy
GRWv/lIxn3ZSRbRxEQi+KaKlUYhFJG8S1dzUS73ShX2fXgF1Hfpb/J4KGd2+mbJ/
IT2LxerZ8D4hB2BcCiGtc7zA3stj7TthccL+mUTkixXXhqNWGjrymDVNNaEZ/USu
MXCx6iCIbuWEvc6zp24r5zVgmx09y7dJXeuVLrNoogdzUw4IWlo9BE3sryDqDo36
CjVwWstSEqi3PVmu6G5l/n0WC35HqNfIRCQTyxuTQzcoSxASU35c1g==
=8Iol
-----END PGP SIGNATURE-----