Message-Id: <6.1.2.0.2.20050221004531.03926eb0@mail.jefsey.com>
Date: Mon, 21 Feb 2005 00:59:26 +0100
To: IETF idn working group <idn@ops.ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense
In-Reply-To: <20050220232733.GA31308~@nicemice.net>
References: <20050219221719.GB5457~@nicemice.net>
 <4217D839.7040502@dready.org>
 <20050220100328.GA14603~@nicemice.net>
 <42189B19.2040403@vanderpoel.org>
 <20050220232733.GA31308~@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On 00:27 21/02/2005, Adam M. Costello said:
>I agree, but in this case, we have already missed the start.  If
>we introduce a whitelist now, after IDN deployment is already well
>underway, we are effectively punishing an unknown number of innocent
>early adopters, which seems like a betrayal.  If we had forseen this
>problem, we could have set up the whitelist in the beginning, and
>registries & registrars would have known to get themselves added to the
>whitelist before making any promises to their customers.

Dear Adam,
we known the problem, as we known the TLD problem, as we known the 
babel-name problem, as we known the IDN zone DNS management complexity, as 
we known the 3+LD problem, as we known the Verisign/ccTLD attitude, as we 
known the lack of layered analysis, etc. (I mean at least people who 
dialogued with me in private when the wg-correct was calling me a dumb 
debile).

Your punycode is a transcoding solution of interest. Tables are an attempt 
to fix part of the IDN problem, but it needs to be applied where it is 
useful and controlled by the user (in phishing: at printing and outbound 
nameprep).
Take care.
jfc

PS. I fail to see what Registrars are to do with this?