Re: [idn] punctuation

John C Klensin <klensin@jck.com> Thu, 24 February 2005 19:02 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00509 for <idn-archive@lists.ietf.org>; Thu, 24 Feb 2005 14:02:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4OBS-00016l-Mr for idn-data@psg.com; Thu, 24 Feb 2005 18:57:58 +0000
Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4OBP-000169-OT for idn@ops.ietf.org; Thu, 24 Feb 2005 18:57:56 +0000
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D4OBE-000Laz-O2; Thu, 24 Feb 2005 13:57:44 -0500
Date: Thu, 24 Feb 2005 13:57:44 -0500
From: John C Klensin <klensin@jck.com>
To: tedd <tedd@sperling.com>, idn@ops.ietf.org
Subject: Re: [idn] punctuation
Message-ID: <E07CE813AD23B2D95DA0C740@scan.jck.com>
In-Reply-To: <p06210202be43c3888991@[192.168.0.101]>
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]>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.5 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

Tedd,

It seems to me that, if an application wanted to provide its
users a way to specify a list of expected characters that was
relatively short compared to the size of Unicode, and then to
warn the user in some way when an unexpected character appeared,
that would be reasonable and, for some users, helpful.   I think
the idea gets into trouble only when the application starts
making guesses as to what should (or should not) be on that
list.  

No, this wouldn't "solve" the problem.  I agree with Erik that,
if people had people had high expectations for it, they would be
badly disappointed.  

But I'm convinced that we aren't going to find a magic bullet
here.  Instead, we can do some large fraction of the "useful,
but not a solution" tools that have been suggested.  We can try
to restrict characters that are clearly dangerous, adopting, if
necessary, a view that the fact someone wants to register or use
a particular string doesn't mean that they are entitled to do
so.  We can adopt a variety of warning technologies --whether
they involve colors, displaying punycode, pop-up warnings, or
something else-- and let applications compete on which ones can
do a better job of that.   We can try some user education.   We
can use the UDRP and/or the legal system in various countries to
push back on those who register deceptive names and on the
registrars and registries that encourage the registration of
such names.  And other ideas may come along that should be
implemented.

Then we can hope that those things, in combination, reduce the
problem to some tolerable level, understanding that it will
never completely go away.

    john


--On Thursday, 24 February, 2005 13:22 -0500 tedd
<tedd@sperling.com> wrote:

>> tedd wrote:
>>> I believe that the "fruit-loop" solution would fall short of
>>> expectations.
>> 
>> I wasn't talking about many colors. A character is either in
>> the  user's set or not. So we only need 2 colors (if colors
>> are used at  all). The user's set is typically derived from
>> the browser  localization or HTTP Accept-Language preference
>> setting.
>> 
>> Erik
> 
> Erik:
> 
> I understand -- however:
> 
> First, I was addressing the idea of a colored url via a
> "tool-tip plug-in" type solution -- a multi-colored or two
> toned fruit loop -- it doesn't make any difference, it's the
> same idea.
> 
> Second, while the user's set is typically derived as you say,
> I imagine there will be users who will transcend those
> boundaries (i.e., multilingual). Considering such, whatever
> the solution, it will most likely "look" different for the
> same url and thus lose some of it's potency as an alert.
> 
> Third, I imagine there may even be concerns (i.e., companies,
> persons, organizations, sport groups, and even countries) who
> may want a fruit-loop domain with their specific colors. It
> might get that ridiculous or maybe this will be a new way to
> market domains. :-)
> 
> It's not a bad idea, just one that falls short of solving the
> problem. Sometimes adding partial solutions to a problem
> become part of the problem.