Re: [idn] process

Erik van der Poel <erik@vanderpoel.org> Sat, 26 February 2005 01:13 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21650 for <idn-archive@lists.ietf.org>; Fri, 25 Feb 2005 20:13:33 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4qQu-000CYC-A7 for idn-data@psg.com; Sat, 26 Feb 2005 01:07:48 +0000
Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4qQr-000CXr-Rd for idn@ops.ietf.org; Sat, 26 Feb 2005 01:07:46 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1Q17auq070134; Fri, 25 Feb 2005 20:07:40 -0500
Message-ID: <421FCBD7.8000805@vanderpoel.org>
Date: Fri, 25 Feb 2005 17:07:35 -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: John C Klensin <klensin@jck.com>
CC: idn@ops.ietf.org
Subject: Re: [idn] process
References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <D872CCF059514053ECF8A198@scan.jck.com> <421D8411.9030006@vanderpoel.org> <p06210208be4390618c81@[192.168.0.101]> <421E0D0C.2000309@vanderpoel.org> <p06210202be43c3888991@[192.168.0.101]> <E07CE813AD23B2D95DA0C740@scan.jck.com> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <A574CA1BE87BFDA3C2A1AC0E@scan.jck.com> <421FA55B.9000308@vanderpoel.org>
In-Reply-To: <421FA55B.9000308@vanderpoel.org>
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

> If we do *not* allow these special local characters that function in the 
> same way as the hyphen in the West, then people in other parts of the 
> world would not only claim that our spec is unfair, they might even 
> ignore it. If we *do* allow this Japanese example, then we have started 
> sliding down a slippery slope that ends with a rather large extension of 
> the LDH rule (for the rest of the world), and then the phishing problem 
> would not be alleviated as much as we might have hoped when we started 
> with just LDH. This would be a lot of work for little gain.
> 
> So it's a lose-lose situation.

Sorry, I said that wrong. What I meant was, "Damned if you do, damned if 
you don't."

However, one avenue that might be worth exploring some more is to check 
each registry's character table (for those that have one) and see what 
the Unicode category is for each character. The Japanese Katakana middle 
dot U+30FB has the category "Pc" which means "punctuation, connector" 
and LDH's hyphen U+002D has the category "Pd" which means "punctuation, 
dash".

http://www.unicode.org/Public/UNIDATA/UnicodeData.txt
http://www.unicode.org/Public/UNIDATA/UCD.html#General_Category_Values
http://vanderpoel.org/networking/i/idn.html (see bottom)

If it turns out that all or most of the registries that have tables are 
using characters with only a small number of Unicode categories, then we 
may wish to consider moving IDNA to that set of categories (disallowing 
all others). This would keep the registries happy while keeping *some* 
of the phishy characters out of DNS.

Erik