Re: [idn] Determining equivalence in Unicode DNS names

[Patrik Fältström <paf@cisco.com>]

--On 2002-01-26 00.41 -0800 Stuart Cheshire <cheshire@apple.com> wrote:

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

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.

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

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

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


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

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

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

  paf