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