Subject: [idn] Determining equivalence in Unicode DNS names

From: Stuart Cheshire <[email-masked]>
Date: Mon, 14 Jan 2002 11:57:16 -0800

I am new to this, so please forgive me if the suggestion I am about to 
make has been discussed before.

Some introduction: I work on networking at Apple. Apple cares a lot about 
international text, and consequently international domain names, and 
consequently my management looks to me to give them input about what is 
going on in this area. Hence my need to educate myself about the current 
state of the world in IDN.

It seems to me that one of the great problems of IDN is one that is 
fundamentally unsolvable: an attempt to determine, once and for all time, 
a single global set of rules for deciding if two strings are "equal" or 
"equivalent".

For US ASCII, equivalence is easy: For good or bad, we have decided that 
upper case and lower case letters are equivalent, and that is the end of 
the debate. Resolvers know that upper case and lower case are equivalent, 
servers know it, and caches know it, so they all agree on whether any two 
given names are equivalent. If a resolver asks for "APPLE.COM" and the 
server gives an answer for "apple.com", then the client (and any cache) 
understands that this is an acceptable answer to the question.

The problem as I see it, right now, is that if a client asks for the 
address record for "www.pépsi.com." (with an accent), and it gets back a 
DNS reply with an answer giving the address for "www.pepsi.com." (without 
an accent), then the client will ignore the answer. Even if the client 
does know that "pépsi" is equivalent to "pepsi", a caching resolver in 
between the client and the server may not, and may ignore the answer.

There are two problems here. The first is that I don't think we ever be 
able to agree on a single set of equivalence rules for the whole world. 
The second is that even if we did, we'd have to have a global flag day 
where every client, server and caching resolver was simultaneously 
upgraded to know the new rules.

It seems to me that the solution is to give up on the idea of a single 
global set of rules, and instead let each name server be authoritative 
for the equivalence rules for the zones for which it is authoritative. If 
a client tries to look up "www.pépsi.com.", and the "com" name servers 
have been configured to treat "pépsi" as equivalent to "pepsi", then they 
return the answer for "pepsi.com.", and in the reply they also include a 
(programatically generated) DNAME record which *tells* the client and any 
intervening caching resolvers that these two names are equivalent:

pépsi.com.              IN	     DNAME	  pepsi.com.
pepsi.com.              IN      NS      dnsauth1.sys.gtei.net.
dnsauth1.sys.gtei.net.  IN      A       4.2.49.2

This way we don't need to have a global flag day, because as servers are 
updated to support international domain names, they can "educate" old 
clients as they go, using DNAME. If we find that text equivalence rules 
evolve over time to meet changing needs that's fine too, because the 
servers can be upgraded one at a time as the user's needs demand that. 
Clients and caches don't need to know any of the equivalence rules at 
all; they just need to obey the DNAME mappings that they are told.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: "Edmon" <[email-masked]>
Date: Mon, 14 Jan 2002 16:02:31 -0500

Hi Stuart,

I think the current argument is "buyer beware" and pepsi will have to make
sure they get all the variances.  You are right that individual
authoritative servers will have to make their own equivalence rules if they
want to.  But your example is even not as extreme as when I mentioned
earlier that <capitalALPHA>.com will look exactly like A.com but currently
they are different domains.  So a zone operator will have to implement some
equivlance rules themselves.

Further to your suggestion, I think the use of DNAME is quite interesting.
In fact it could be used in the future for migration towards a UCS system
perhaps based on EDNS.  The server will have

pépsi.com.                 IN      DNAME   xx--aceofpépsi.com.
xx--aceofpépsi.com.  IN      NS      dnsauth1.sys.gtei.net.
dnsauth1.sys.gtei.net.  IN      A       4.2.49.2

Is this not also a possible way to move toward a UCS system?  with this,
future clients dont need to deploy ACE at all, but will obtain the
information from the server.
Edmon

----- Original Message -----
From: "Stuart Cheshire" <[email-masked]>

---

From: "Kenny Huang" <[email-masked]>
Date: Tue, 15 Jan 2002 10:02:30 +0800

We have encountered with many equivalence rule discussions.
As you mentioned, if the equivalence rule is simple enough (A=a)
thus the logic can be applied anywhere (service, client, cache, fw..).
If the wg tried to extend rule to a broader domain, that would be difficult
to identify a specific boundary.

Designing a simple equivalence rule in client application is a 
compromise of LDH DNS server.  There is no much technical margin
for designing advanced equivalence rules. Middleware, DNS server 
(UNAME, DNAME) or other naming systems would probably be the remaining 
space for these advanced computations. However, only simple equivalece 
rule got across all demands in application services.

Kenny Huang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Stuart Cheshire
> Sent: Tuesday, January 15, 2002 3:57 AM
> To: [email-masked]
> Subject: [idn] Determining equivalence in Unicode DNS names
> 
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 18 Jan 2002 07:52:08 +0100

Stuart,

draft-vrang-idn-cname-00.txt describes such a scheme in some detail.
It also tries to create a "canonical" collection of the problems you are 
likely to encounter with such a scheme.

I'd like to see comments on disadvantages that were missed :-)

Note: DNAME is, at the moment, not a popular record in the DNS.
It creates MANY interesting problems; currently, most DNS people seem to be 
in favour of declaring it useless for standards-track protocols.

                         Harald

---

From: David Conrad <[email-masked]>
Date: Thu, 17 Jan 2002 23:11:08 -0800

> in favour of declaring it useless for standards-track protocols.

Oh?  Where have these discussions been occuring?

Tnx,
-drc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 18 Jan 2002 10:28:22 +0100

--On 17. januar 2002 23:11 -0800 David Conrad <[email-masked]> 
wrote:

>> It creates MANY interesting problems; currently, most DNS people seem to
>> be in favour of declaring it useless for standards-track protocols.
>

that is what I have understood from DNSEXT and the NGTRANS WG.
The NGTRANS/DNSEXT discussions in London concluded that DNAME was not 
needed for introducing IPv6, but that DNAME might have other uses, so 
NGTRANS should not speak about whether it should be on standards track or 
not - just that v6 does not need it.

DNAME has been mentioned in a total of 15 messages (out of 1005) on DNSEXT 
since I changed mailers this summer; it hasn't been a very active topic 
recently.

But you are probably better able to speak authoritatively about its status 
than I am.....

                  Harald

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 18 Jan 2002 19:57:44 +0900

Harald,

I see in the on-the-fly CNAME RR draft [page 4],
(http://search.ietf.org/internet-drafts/draft-vrang-idn-cname-00.txt)

"The method will cause confusion with HTTP/1.1 named virtual hosts and
other services where the server wishes to know which name the client is
trying to use for him; unless the server executes the mapping algorithm
himself, the name that the client hands to the server will not match
any name that the server knows for itself. "

To name the "other services" explicitly, including pure standalone client applications,
email/hostname search failures in local addressbook/ldap directory/legacy DB,
certificate verifications failures in HTTPS & SMIME from browser/mail clients,
Java applet security mechanism failure,
other hostname based security mechanisum failure
consistent browser cookie handling failure between sessions,
virtual mail hosting failures,
and many IDN-aware/nonaware in-house applications failure which do hostname comparisons

many of them may be noticeable or may *NOT* noticeable to operaters or end users!
Just fail, providing no clues!
Similar problems occur in treating unassigned code points.

Apporaches using DNAME RR or A RR (so popular "multiple registrations") and localizations
also share the same disadvantages. very costly tricks that make troubles.

These approaches cannot solve TSCONV problem and
Latin/Greek/Cyrillic/Cherokee lookalike problems, rather, make them more complicated.

IDN is not suitable for mission critical internet identifier system.
rather,i feel it is like a toy.

Soobok Lee