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

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

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

I wrote:
> tsenglm@cc.ncu.edu.tw wrote:
> > Patrik Fältström wrote:
> > > When the matching algorithm you envision encounters a character where the
> > > tables do not tell what to do about it, what will the algorithm do to it?
> > > Pass it through unmodified? Reject it? Does something else which you have
> > > not defined yet?
> >
> > [pass it through unmodified]
> >
> > > If you tell us this, and claim that this is acceptable treatment of the
> > > 20-40.000 characters not in the tables, we can at least discuss this
> > > proposal (whether such a partial TC/SC mapping is acceptable), instead of
> > > asking again and again what to do about them.
> >
> >            As Patrik Fältström described, if it is a mechanism in
> > UNICODE consortium, then they have the version update procedures and IDNA
> > also treat the version update in UNICODE, why it can not be updated step
> > by step to increase it?
> 
> Because that could cause existing domain names to break (i.e. fail to resolve
> when processed by a new version of nameprep). This would happen when a
> name contains a source character for one of the new mappings. In order to
> avoid that problem, all authoritative servers with names in the affected
> scripts would have to be upgraded before any resolvers or applications.

In fact it's worse than that, as Patrick Fältström pointed out: the source
and destination names may already be owned by different people/organizations.
So adding new mappings for already-assigned Unicode characters must be
prohibited.

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

iQEVAwUBO46mtzkCAxeYt5gVAQExGQf9GPIns+whxvrl9pkERCvDwWKPH08rNXnB
4+5+So7/o0yPj1ownIJhDNlSc0o6TguBIEOvbDGZbnfivZZwc6KPpa9tSYmClLFS
AgXlORj26FT26ALfPRE+xbPNbEltwp5BM1fscE9RouoKZiunQ32MX4rq64g7R1xL
+IRaBjS8YCX/Ojrk0JbccH96syaFIlIFsH78fbLZ8Wrm6AailOpkW4/tYqoxvtNh
WsRHPH3Gw7YlPCL39RboVUk+ULGca8yq5eCAFlk4g3nXj88OblACQY8dhgtdFPYj
LN9jsCsIcgbn6qgx8rD4u0hypK9qzET+yt8x7f/JVLPU1rfxGqTWaw==
=rh4B
-----END PGP SIGNATURE-----