IETF Logo Mail Archive

Re: [idn] Re: character tables

Erik van der Poel <erik@vanderpoel.org> Wed, 02 March 2005 19:08 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15064 for <idn-archive@lists.ietf.org>; Wed, 2 Mar 2005 14:08:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D6Z7x-000Ik5-Jc for idn-data@psg.com; Wed, 02 Mar 2005 19:03:21 +0000
Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D6Z7v-000Ijl-80 for idn@ops.ietf.org; Wed, 02 Mar 2005 19:03:19 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j22J2tVl134450; Wed, 2 Mar 2005 14:03:01 -0500
Message-ID: <42260DDF.5010007@vanderpoel.org>
Date: Wed, 02 Mar 2005 11:02:55 -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: Gervase Markham <gerv@mozilla.org>, Paul Hoffman <phoffman@imc.org>, idn@ops.ietf.org
Subject: Re: [idn] Re: character tables
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> <421FCBD7.8000805@vanderpoel.org> <42227EBF.9040703@vanderpoel.org> <45781B7428C6AA07C3B283BD@scan.jck.com> <42229BBC.8020608@vanderpoel.org> <p0621021ebe484f52c0c5@[10.20.30.249]> <4225ABAB.60002@mozilla.org> <p0621022dbe4ab4b8a3fa@[10.20.30.249]> <42251B80.5050503@vanderpoel.org> <4225455C.2030109@vanderpoel.org> <A32EEA4DEC04F4C4122A64F9@scan.jck.com>
In-Reply-To: <A32EEA4DEC04F4C4122A64F9@scan.jck.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=AWL,BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

John,

John C Klensin wrote:
> So my conclusion is that we need a mixed
> protocol-registry-browser strategy.  That strategy, IMO, should
> shifted the processing burdens as much as possible to the first
> two.  And I think that notions that the problem can or should be
> solved in any of those three places alone are probably misguided.

I strongly agree with everything you said. I am sorry if I gave the 
impression that the browser implementors are the *only* people that can 
and should address this IDN phishing problem. I don't think I said that, 
but maybe I'm just not very good at email and/or expressing myself. I 
also agree that the burden should be shifted as much as possible to the 
first two. It would be bad if the many implementations all did it 
differently.

I would only add one component to your strategy. It should be a 
Unicode-protocol-registry-browser strategy. Unicode has already started 
working on their part:

http://www.unicode.org/reports/tr36/

Erik

v2.23.0 | Report a Bug | By Email