[idn] nameprep2 and the slash homograph issue

Erik van der Poel <erik@vanderpoel.org> Tue, 22 February 2005 19:18 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06231 for <idn-archive@lists.ietf.org>; Tue, 22 Feb 2005 14:18:41 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3fU7-000BjC-Oh for idn-data@psg.com; Tue, 22 Feb 2005 19:14:15 +0000
Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3fU6-000Biz-RH for idn@ops.ietf.org; Tue, 22 Feb 2005 19:14:15 +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 j1MJECHb179866; Tue, 22 Feb 2005 14:14:13 -0500
Message-ID: <421B8484.3070802@vanderpoel.org>
Date: Tue, 22 Feb 2005 11:14:12 -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: idn@ops.ietf.org
Subject: [idn] nameprep2 and the slash homograph issue
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

All,

In a way, it was pretty sensible for the IETF to decide to avoid 
subsetting Unicode too much so that national registries could make those 
decisions on their own. After all, those countries know more about their 
own characters than the IETF does, and it seems more fair to let them 
make such a decision.

One could see this as an instance of "Push the problem downstream, so 
that we cannot be blamed for being overly restrictive up here".

Now I'm wondering if we could make a similar argument in the slash 
homograph case. If nameprep2 bans the slash homograph, then there is no 
way for any community to use it in a domain name, even if that domain 
name appears in a context where slash means nothing. Consider the email 
case. There are no slashes in the vicinity of a domain name in an email 
app. The URI case is, of course, different. Here you often see slashes, 
so a slash homograph could easily spoof someone.

So, could nameprep2's position be, "Push the slash homograph problem 
downstream, to the app, so that we cannot be blamed for being overly 
restrictive up here"?

Or is the slash fundamentally different from national characters? And if 
so, who are we to make that statement? Shouldn't the countries be 
deciding that? (Not that TLDs can restrict names in 3LDs and up, only 
the apps can address those.)

Another argument against banning the slash homograph is that any new 
banning would require a new ACE prefix, which is a lot of work, and, as 
John said, there should be a high threshold for any demonstration that 
tries to show that a new prefix is necessary.

Instead of banning the slash homograph, nameprep2 could simply warn 
implementors of the spoofing problem, giving some vague advice (without 
overly restricting the apps).

Erik