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