Re: [idn] nameprep2 and the slash homograph issue

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

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19602 for <idn-archive@lists.ietf.org>; Wed, 23 Feb 2005 12:57:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D40hI-00024I-Iv for idn-data@psg.com; Wed, 23 Feb 2005 17:53:16 +0000
Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D40h6-00021Y-3S for idn@ops.ietf.org; Wed, 23 Feb 2005 17:53:04 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NHqaSJ188854; Wed, 23 Feb 2005 12:52:45 -0500
Message-ID: <421CC2E4.5000908@vanderpoel.org>
Date: Wed, 23 Feb 2005 09:52:36 -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: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
CC: 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> <421CA114.9090302@vanderpoel.org> <6.1.2.0.2.20050223180502.031d5730@mail.jefsey.com>
In-Reply-To: <6.1.2.0.2.20050223180502.031d5730@mail.jefsey.com>
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=BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

JFC (Jefsey) Morfin wrote:
> At 16:28 23/02/2005, Erik van der Poel wrote:
>> 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).
> 
> Yes. But this does not prevent to warn in proposing solutions to the 
> system conceptual problems, like for tables. The same for TLD Managers.

I agree. Specs often have normative and informative sections, 
appendices, etc. We could easily insert some *advice* in an informative 
part.

Erik