I tried sending the attached message on Monday, but it mysteriously
vanished.  Let's see if it gets through this time.

AMC
--- Begin Message ---
Stuart Cheshire <[EMAIL PROTECTED]> wrote:

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

You're right that we have no hope of defining a single global set of
rules for equivalence of *strings*.  But we don't need that for IDN.
We merely need a single global set of rules for equivalence of domain
labels.  IDNA defines those rules.

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

Indeed, because p�psi and pepsi are two distinct labels.  This is like
today, if a client asks for colour.com, then it will ignore a response
telling the address of color.com.  The server needs to answer the
question that was asked, not some other question that it considers
"close enough".

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

Assuming DNAME is understood by the caches and clients, you could indeed
do that.  But this does not necessarily yield full equivalence between
pepsi.com and p�psi.com.  In the existing (pre-IDN) model, comparison
of two names for equivalence has never required a DNS lookup.  If
someone has visited pepsi.com and then visits a page containing links to
p�psi.com, will those links be colored correctly?  Probably not.  If an
SSL connection is used, and the certificate uses the name pepsi.com, but
the client used p�psi.com, will the SSL library believe that the server
is authentic?  I doubt it.

AMC
--- End Message ---

Reply via email to