Re: [idn] nameprep2 and the slash homograph issue

Erik van der Poel <erik@vanderpoel.org> Fri, 25 February 2005 01:22 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16941 for <idn-archive@lists.ietf.org>; Thu, 24 Feb 2005 20:22:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4U7j-000NRo-SC for idn-data@psg.com; Fri, 25 Feb 2005 01:18:31 +0000
Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4U7i-000NRc-MM for idn@ops.ietf.org; Fri, 25 Feb 2005 01:18:30 +0000
Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1P1IGSJ290836; Thu, 24 Feb 2005 20:18:22 -0500
Message-ID: <421E7CD8.50904@vanderpoel.org>
Date: Thu, 24 Feb 2005 17:18:16 -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: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
CC: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] nameprep2 and the slash homograph issue
References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <D872CCF059514053ECF8A198@scan.jck.com> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> <20050224081721.GB12336~@nicemice.net> <421DEDFF.2000300@vanderpoel.org> <6.1.2.0.2.20050224224107.027ee9d0@mail.jefsey.com>
In-Reply-To: <6.1.2.0.2.20050224224107.027ee9d0@mail.jefsey.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=BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jefsey,

Thanks for the support. Your idea about giving each level of the domain 
name a standard color is very interesting. I am reworking nameprep.org 
right now, and I'll probably include a section near the end about this. 
Note that just because this section is in the doc at nameprep.org does 
not mean that it would necessarily find its way into any Internet Draft, 
let alone a new RFC. If this section tries to mandate colors, it 
probably would not be in a normative (or MUST) part of an IETF RFC. It 
would end up in an informative appendix (or a MAY).

No, I don't think W3C is the right organization for this. IDNA has 
already been produced by the IETF, and domain name issues don't really 
belong at W3C, even though URIs are covered by some of their docs.

Mozilla has very different plans in this space. I have been unable to 
convince them of the need for tools/extensions. So far. :-)

Erik

JFC (Jefsey) Morfin wrote:
> Very, very good idea.
> 
> This could be a _standard_ way to print the domain name in the browser 
> bar. A very simple way could just be to print every URL in the bar with 
> a different color for each level. This does not change anything in any 
> procedure and can be very easily tought and understood. If one 
> standardizes the colors it may help customer support, advertizing, 
> discussing, etc? permitting to speak of the "blue", "red", "green" part 
> of a discussed URI. This would be far easier for lay people than to talk 
> of first, second, etc. level - whatever the language.
> 
> I suggest you write a private Draft of this asap. Probably a single page 
> enough. Mozilla could make it an immediate update if it would be an RFC 
> on the standard track. This is would stop the developing campaign of 
> concerns, with something which would be considered as positive.
> 
> Or, would this be for the W3C?
> jfc
> 
> At 16:08 24/02/2005, Erik van der Poel wrote:
> 
>> Here I agree with you. I'm not going to try to come up with the 
>> wording for that, but this morning I started to think that the 
>> right-to-left DNS and IDN spoofing problems *could* be addressed at 
>> the UI level by providing a *tool* that security-conscious users could 
>> *choose* to use.