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

From: Stuart Cheshire <[email-masked]>
Date: Sat, 26 Jan 2002 23:40:19 -0800

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

Then I'm afraid I don't see your objection to my original proposal, which 
was *precisely* what you just said, namely: the DNS protocol doesn't 
determine if two names are equal; let the domain name holder decide.

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

I wish. I have to sit through the meetings where the file system guys 
debate how to handle each rule change, and its impact on forward and 
backward interoperability.

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 27 Jan 2002 11:13:59 +0100

That was not what you said. You said:

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

That is a completely different thing, and that was what I objected to.

The servers need to have exactly the same rules.

> backward interoperability.

Give one example after Unicode 3.0. (There is one change, and you might
catch that one, but that change was deliberate, and made in cooperation
with IETF....i.e. it was decided to make that change to 3.1 just because
IDN had not taken off yet.)

Before 3.0, sure.

And, yes, your filesystem guys have digged a very deep hole in the ground
where they are currently, trying to get up. I am thinking of the ability of
use of UFS or HFS(+) for MacOSX, where things like case insensitivity in
HFS+ is biting them. I have had some problems with Perl CPAN install
mechanisms which rely's on the fact that "Makefile" and "makefile" actually
should be two different files in "normal" UFS....so there are some problems
with some install scripts from CPAN.

So, I understand the discussions you have inhouse...I don't want to be
there.

  paf -- Very happy MacOSX user!!!

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 28 Jan 2002 21:23:43 +0000

> The servers need to have exactly the same rules.

Do you not agree that an authoritative server can use whatever
method/rules it likes to decide authoritative answers to queries?  For
example, the server could compute the answer as a function of the
requestor's IP address and the time of day and the dynamic load on
various machines.  The server can do this because it is the *authority*
over that part of the namespace--whatever it says it the correct answer
by definition.  Given that authoritative servers have so much freedom,
isn't it absurd to imagine imposing restrictions on how they can process
the queries?

There is no need to discuss this here because it has no impact on IDN.
Authoritative servers have always had this ability, and will continue to
have it regardless of what sort of IDN gets adopted.

AMC

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 29 Jan 2002 08:25:47 +0100

--On 2002-01-28 21.23 +0000 "Adam M. Costello"
<[email-masked]> wrote:

> method/rules it likes to decide authoritative answers to queries?

We talked about the rules which define "equivalence", and they need to be
the same.

If the content of a RR-Set is changing over time, that is fine. But, as
soon as the RR-Set is changing, it needs to be resigned.

The important thing is that if a server sends out an RR-Set, that set needs
to stay complete when it sits in a caching server.

   paf