[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] nameprep2 and the slash homograph issue
- To: idn@ops.ietf.org
- Subject: [idn] nameprep2 and the slash homograph issue
- From: Erik van der Poel <erik@vanderpoel.org>
- Date: Tue, 22 Feb 2005 11:14:12 -0800
- User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
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