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

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

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

tsenglm@cc.ncu.edu.tw wrote:
> "ben" <ben@cc-www.com> wrote:
> > "Adam M. Costello" <amc@cs.berkeley.edu> wrote:
> > > This [top-level <.traditional> and <.simplified>] would limit people's
> > > choice of registration authority.

I agree. A TLD (regardless of what script it is in) should specify which
registration authority is responsible for allocations below that TLD.
If language script specifiers are needed then they should go to the left
of the TLD.

However, I don't see any need to require script specifiers; the following
algorithm (to be performed when typing a name into a browser location
field, for example), would seem to be sufficient:

 1. Find the rightmost character (i.e. last in logical order [*]) that is
    specific to TC or SC. Call its script the "rightmost script", and the
    other Chinese script the "opposite script". If there is no such
    character, use the name as-is.
 2. If the name contains any characters from the opposite script, convert
    them to the rightmost script and ask the user whether that's what he/she
    meant.

Support for this would be OPTIONAL; the fact that a name with mixed TC and
SC can be converted to a valid name would not mean that the mixed name is
valid.

[*] Labels that mix Chinese and right-to-left scripts are unlikely; this is
    specified just to make the algorithm unambiguous.

> > In my system, CDNs cannot be a mix of TC and SC.  If that is
> > considered "limit people's choices..." then I am afraid I am guilty.
> > However, can you come up with even one good reason why we should allow
> > a CDN to have mixed TC and SC?

I don't think Adam was suggesting that. The issue is who handles registrations
under <.traditional> and <.simplified> in your scheme.

>        In HongKong , Taiwan,  user use BIG5 code . This code set has no
> simpified chinese scripts. In China , GB code set has no traditional chinese
> scripts . So there are no mixed type of  GB and BIG5 .  But you know
> VeriSign/NSI  announced ML.com  with any UNICODE can be mixed.
> That is the key problems.

Verisign/NSI would be highly premature in announcing any policy about Unicode
names - they don't know what the protocol will support yet. Where did they
announce this?

>        Any suggestions must be considered  what to do for .COM in this WG.
> If english character is treated as case folding, Why  CJK can not treated as
> the same way to reduce the number of registrations for trade mark
> considerations?

Because this type of folding requires only two (or at least a small number
of) registrations if it is done at the server end, whereas case folding
would require on the order of 2^n registrations. Therefore, the trade-off
between client complexity (i.e. the complexity of nameprep) and any server-
side or registration difficulties is quite different.

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

iQEVAwUBO3oggTkCAxeYt5gVAQHUZAf/a8InwXiS6kBsSIulZ4xX/Vdq/CJLO26i
Hc0rDLUVf9BVGGk/5JlFLDXuqIaT6tM8pPWoaJyAe/EYdO4eVo/GqQdltj2iRCUd
b03mJe7Q0405bv8LZpRzQ4DuRsAP55dnNv4X4efP7o/ggbCHZ0NHTvNFyhsvivdI
TKY7oLjKb5YkTCYmjp7MmBKK6dFoeIRErd4nE6/NXTX0x284YOyoaK6qyLe97uTs
LU09FBFpYkvoZI1N226ZL2EM8biUpYOjbIH2en23QHLx9zAroYrmVEsuBTTUBiLq
z8XimX+VnTZS9FhEDI8gLwVHFN+zKj3GG35s4ZuYDAZibM53NnNxEA==
=NRtj
-----END PGP SIGNATURE-----