Harald,
I see in the on-the-fly CNAME RR draft [page 4],
(http://search.ietf.org/internet-drafts/draft-vrang-idn-cname-00.txt)
"The method will cause confusion with HTTP/1.1 named virtual hosts and
other services where the server wishes to know which name the client is
trying to use for him; unless the server executes the mapping algorithm
himself, the name that the client hands to the server will not match
any name that the server knows for itself. "
To name the "other services" explicitly, including pure standalone client applications,
email/hostname search failures in local addressbook/ldap directory/legacy DB,
certificate verifications failures in HTTPS & SMIME from browser/mail clients,
Java applet security mechanism failure,
other hostname based security mechanisum failure
consistent browser cookie handling failure between sessions,
virtual mail hosting failures,
and many IDN-aware/nonaware in-house applications failure which do hostname comparisons
many of them may be noticeable or may *NOT* noticeable to operaters or end users!
Just fail, providing no clues!
Similar problems occur in treating unassigned code points.
Apporaches using DNAME RR or A RR (so popular "multiple registrations") and localizations
also share the same disadvantages. very costly tricks that make troubles.
These approaches cannot solve TSCONV problem and
Latin/Greek/Cyrillic/Cherokee lookalike problems, rather, make them more complicated.
IDN is not suitable for mission critical internet identifier system.
rather,i feel it is like a toy.
Soobok Lee
----- Original Message -----
From: "Harald Alvestrand"
To: "Stuart Cheshire" ;
Sent: Friday, January 18, 2002 3:52 PM
Subject: Re: [idn] Determining equivalence in Unicode DNS names
> Stuart,
>
> draft-vrang-idn-cname-00.txt describes such a scheme in some detail.
> It also tries to create a "canonical" collection of the problems you are
> likely to encounter with such a scheme.
>
> I'd like to see comments on disadvantages that were missed :-)
>
> Note: DNAME is, at the moment, not a popular record in the DNS.
> It creates MANY interesting problems; currently, most DNS people seem to be
> in favour of declaring it useless for standards-track protocols.
>
> Harald
>
>
> --On mandag, januar 14, 2002 11:57:16 -0800 Stuart Cheshire
> wrote:
>
> > 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. 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:
>
>
