Message-Id: <6.1.2.0.2.20050227203118.02f22eb0@mail.jefsey.com>
Date: Sun, 27 Feb 2005 23:55:47 +0100
To: Erik van der Poel <erik@vanderpoel.org>,
	IETF idn working group <idn@ops.ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [idn] Re: dichotomies
In-Reply-To: <42221C34.2060505@vanderpoel.org>
References: <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>
 <20050226081913.GD14956~@nicemice.net>
 <42221AB7.9070000@vanderpoel.org>
 <42221C34.2060505@vanderpoel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

(I will correct Erik's "xn--s" proposed notation into "xs--" not to create 
havoc in punycode)

One of the reason why I disagreed with IDNA is it creates a possibly 
conflicting left-to-right hierarchy while the DNS hierarchy is 
right-to-left. Erik's proposition makes a lot of sense. But it means that a 
label at the same time:
- belongs to a DNS zone
- belongs to a zone of encoding (ascii, punycode, his punysecure, new 
versions, tables, other transcoding, etc. )
- may belong to a zone of encoding different from the zone of encoding of 
other labels (ex.: "xn--abc.xs-def.tld").

This does not simplify understanding, management, security. Why not to just 
use DNS zones? I have not yet understood why it was opposed. IMHO the 
future of ML.ML names are in the form "name2.name.xx--chicom.com" where 
"xx-nn.com" will print as ".com" in Chinese and name, name2 etc. will all 
have to use codes from the Chinese Table of ".com".

jfc

At 20:15 27/02/2005, Erik van der Poel wrote:
>Erik van der Poel wrote:
>>Another bifurcation that could be considered somewhat analogous is that 
>>of http vs https. We might even want to consider bringing the topic of 
>>security into the ACE prefix discussion. One could imagine a world where 
>>two different ACE prefixes co-exist, one new prefix for "secure" domain 
>>labels, the other (old) prefix for less secure labels.
>
>Sorry, I forgot to say that a Web site would choose the new secure ACE 
>prefix when they use https. In fact, they would make that choice for 
>similar reasons, i.e. to allow the user agent to distinguish this site 
>from a less secure one, similar to Mozilla's current choice of using the 
>padlock icon and a different color near the URI at the top for https.
>
>Erik