[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] who should be doing IDN filtering
John C Klensin wrote:
None of these rules or conventions causes any interoperability
(or balkanization) issues at all: a resolver either finds the
name or doesn't, and is indifferent to whether a name that is
not found isn't there because no one wanted to register it or
because they were prohibited from doing so.
Yes, but as a browser developer, I *would* care about whether a user was
able to easily type in a domain name and go where s/he wanted to go. In
the presence of these homograph problems, a browser developer might even
want to retry DNS lookups with different character codes until it
succeeded. We can't just foist these solvable problems on the end-user.
We would have interoperability issues if someone tried to change
the resolution rules themselves: a local (and different) version
of the IDNA tables that would map a UTF-8-encoded Unicode string
to a different punycode string than is called for by the IDNA
and nameprep specs would be very bad news indeed.
You could use a prefix other than xn-- to migrate from the old to the
new. I jotted down a few quick ideas here:
http://lists.w3.org/Archives/Public/www-international/2005JanMar/0101.html
However, if I can't get support from the major organizations such as
Microsoft, VeriSign and the Unicode Consortium (either because too many
xn-- names have already been registered and the migration would not be
practical or for some other reason), then I might just give up on this
idea. But I'm willing to explore it some more.
Having individual applications
programs, such as browsers, guess what those rules are for a
given domain is, by contrast, a nightmare.
As a browser developer, I would not try to "guess" what those rules are.
I would read them and try to implement them correctly.
any sort of "bad name" restriction on a name that is
IDNA-conformant would be really bad news, going far beyond the
messes I tried to warn about in RFC 3696.
Gotta go right now. I'll read that later.
Erik