Subject: Re: [idn] Determining equivalence in Unicode DNS names

From: Stuart Cheshire <[email-masked]>
Date: Sat, 26 Jan 2002 00:41:16 -0800

Patrik Fältström wrote:
>Example: If a.com and b.com is considered equal,
>why should not a.se and b.se be equal?

a.com. IN A     1.2.3.4
b.com. IN CNAME a.com.

a.se.  IN A     1.2.3.5
b.se.  IN A     1.2.3.6

In this (very simplified) example, "b.com." is declared to be no more 
than an alias for "a.com." Any lookup for any DNS record type for 
"b.com." will return the same answer as a lookup for that DNS record type 
for "a.com."

In contrast, "a.se." and "b.se." are different.

Why is this a problem?

>So, this wg decided that we will use one and only one matching rule,
>just like we decided to use only one character set. Both of these
>(the rule and the charset) are created in the Unicode Consortium.
>
>You also talk about "evolving matching rules over time". That
>is a very bad thing.

Unfortunately, the rules as created by the Unicode Consortium do change 
over time. Apple's HFS+ file system uses Unicode file names, with the 
restriction (as you would expect) that two files in a directory cannot 
have the same name.

Unfortunately, when the Unicode Consortium rules change (we're currently 
in the process of moving to Unicode 3.2 rules), this can result in two 
files that were previously considered different names, to now be 
considered the same name, hence resulting in an apparently invalid file 
system.

This is a mess. It would be much better if the file system on the volume 
could assert the version of the Unicode Consortium rules by which it 
abides, instead of being judged by the version of the Unicode Consortium 
rules in effect at the time it is read.

Hence my suggestion that IDN avoid the same mistake, and let the 
authoritative server for a domain assert the Unicode Consortium rules by 
which it abides.

>Let's say that we have registered apple.com and äpple.com. They
>are considered different. One day the equivalence rule change,
>and they are considered being the same. Who is calling Steve
>Jobs saying that apple.com have to give back it's domain name
>and pick something else? You? ICANN? The registry for .com?

Again, an argument supporting my suggestion that the authoritative server 
for the "com" domain should be allowed to assert the Unicode Consortium 
rules by which it abides, instead of having to change every time the 
Unicode Consortium rules change.

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 26 Jan 2002 11:51:56 +0100

> In contrast, "a.se." and "b.se." are different.

My point was that when talking about "equal", in DNS we compare labels one
by one, without looking at context, i.e. neighboring labels. So, if "a" and
"b" are the same, then both a.se and b.se are same and a.com and b.com are
the same.

You show an example where "a" and "b" are different (from DNS matching
point of view) but the domain name holder of a.com and b.com want them to
resolve to the same IP-address.

Which of course is ok.

> considered the same name, hence resulting in an apparently invalid file 

The changes are very controlled, and no changes are made which have the
impact you tell.

> authoritative server for a domain assert the Unicode Consortium rules by 

See section 6 of the draft-hoffman-stringprep-00.txt document about
versioning.

> Unicode Consortium rules change.

See the stringprep document and think about the impact on RR-Sets if the
matching rules are different.

  paf