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

["ben" <ben@cc-www.com>]

Hi Keith,

As unpleasant as the bath water may be, we cannot throw out the baby-
it will come back and haunt each and everyone of us.

Thanks
Ben Chan


----- Original Message -----
From: "Keith Moore" <moore@cs.utk.edu>
To: "John C Klensin" <klensin@research.att.com>
Cc: "Edmon" <edmon@neteka.com>; <idn@ops.ietf.org>
Sent: Thursday, August 09, 2001 1:04 PM
Subject: Re: [idn] opting out of SC/TC equivalence


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