Re: [idn] nameprep2 and the slash homograph issue

Erik van der Poel <erik@vanderpoel.org> Wed, 23 February 2005 15:35 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28930 for <idn-archive@lists.ietf.org>; Wed, 23 Feb 2005 10:35:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3yR9-0007SW-Vb for idn-data@psg.com; Wed, 23 Feb 2005 15:28:27 +0000
Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3yR8-0007SI-RC for idn@ops.ietf.org; Wed, 23 Feb 2005 15:28:27 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NFSLHb155098; Wed, 23 Feb 2005 10:28:21 -0500
Message-ID: <421CA114.9090302@vanderpoel.org>
Date: Wed, 23 Feb 2005 07:28:20 -0800
From: Erik van der Poel <erik@vanderpoel.org>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] nameprep2 and the slash homograph issue
References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <D872CCF059514053ECF8A198@scan.jck.com> <20050223105244.GE21463~@nicemice.net>
In-Reply-To: <20050223105244.GE21463~@nicemice.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Adam,

The IETF generally only specifies the "wire" protocol, not UI behavior. 
The IETF does not specify how apps interface with users; it only 
specifies how apps interface with other apps, over the wire. Note that 
this does not even include APIs in many cases.

However, it *would* be very wise to *warn* implementors about any 
dangerous homographs in the new RFC (if we decide not to ban them outright).

Erik

Adam M. Costello wrote:
> But browser implementers want to protect their users today against
> malicious names that may exist in the DNS today.  I don't see how
> this proposal would help them do that.  Browser implementors are
> comtemplating banning characters in IDNs the browser (that is, failing
> to look up names containing blacklisted characters), and I was trying
> to think of a less drastic, less blatantly nonconformant, but equally
> protective measure that could be taken in the browser.