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

[Keith Moore <moore@cs.utk.edu>]

> > I completely concur with you, perhaps you misunderstand my
> > statement.  What I am saying is that if CNNIC believes that
> > there is compelling user expectation within their registry to
> > have SC=TC, then they should absolutely implement it.
> 
> And they should somehow to contrive to be sure that no records
> are cached outside China, where other rules would apply as a
> query is applied to a cached record?   I continue to be afraid
> that the choices are between
> 
>         -- the whole DNS using the same procedures or
> 
>         -- fragmenting the network
> 

I don't think that's an accurate characterization.   As a practical
manner, any DNS zone can create multiple names within that zone that
resolve to equivalent RRs, and any DNS zone can establish procedures
for keeping those names consistent, without affecting the DNS protocol
or the applications that use it.  Similarly, if two zones are controlled
by the same party, that party can maintain those zones such that
label X in zone A and label X' in zone B resolve to an equivalent set of 
RRs, and the party controlling those zones can keep those two zones 
consistent with one another.

I don't see this as inherently undesirable.  True, caches will not recognize 
that these zones are equivalent, but this mainly serves to increase lookup 
delay for names in those zones and to increase load on the authoritative 
servers for those zones.  Each zone can decide for itself whether it's 
worth the additional delay and cost.

Nothing that IDN does is going to change the ability to create multiple
names that produce equivalent RRs.  Nor do I think that IDN can build a 
better way to solve this problem.  We certainly don't want to embed 
knowledge of SC/TC equivalence into applications, DNS libraries, or 
DNS servers.

Users can tell the difference between TC and SC.  So they will be able
to figure out that even if TC and SC names are equivalent within some
particular TLD, they are not necessarily equivalent elsewhere.

Bascially I think this issue is out of scope for IDN, because you can't 
expect a networking protocol to fix all naming equivalence problems in 
all languages.

Keith