Re: [idn] Re: dichotomies

Erik van der Poel <erik@vanderpoel.org> Mon, 28 February 2005 00:12 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17327 for <idn-archive@lists.ietf.org>; Sun, 27 Feb 2005 19:12:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5YQj-000I2M-Li for idn-data@psg.com; Mon, 28 Feb 2005 00:06:33 +0000
Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5YQg-000I1x-7B for idn@ops.ietf.org; Mon, 28 Feb 2005 00:06:30 +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 j1S06JpY413290; Sun, 27 Feb 2005 19:06:23 -0500
Message-ID: <4222607A.80804@vanderpoel.org>
Date: Sun, 27 Feb 2005 16:06:18 -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] Re: dichotomies
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> <6.1.2.0.2.20050227203118.02f22eb0@mail.jefsey.com>
In-Reply-To: <6.1.2.0.2.20050227203118.02f22eb0@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

JFC (Jefsey) Morfin wrote:
> (I will correct Erik's "xn--s" proposed notation into "xs--" not to 
> create havoc in punycode)

You are right, of course. What was I thinking? Duh. Well, how about 
"xs--n", to differentiate it from "xn--", and to still have the 
advantage of a non-delimiter-like character before the rest of the string?

> 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.

I'm afraid I don't understand this.

> 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".

I think your proposal makes some sense. It is similar to my proposal in 
a way -- recall my .jp example, with the rule that *all* labels would 
have to use the same ACE prefix or pure ASCII.

There isn't really any way to force the TLDs or zone administrators to 
follow any rules that we might come up with. The best we can do is write 
down some guidelines that are well thought out. And write them clearly.

If registries and zone administrators fail to follow the guidelines, the 
applications may have to display their domain names differently, to 
indicate some level of risk.

Also, we can't just suddenly switch a TLD from one encoding to another 
and then expect all the subdomains to follow suit the same night. 
Instead, we might have a rule specifying that all labels under the first 
new ACE prefix must use the same prefix. For example, suppose we have a 
new domain with the new prefix, called "xs--nfoo-abc.jp". Since the 2LD 
uses the new prefix, any 3LDs, 4LDs and so on would also have to use the 
new prefix. Does this make sense?

Finally, regarding displaying ".com" in Chinese, there is currently no 
reason to display ".com" in ASCII. This could easily be displayed in 
Chinese if the application developers were only willing to modify their 
programs to be more user-friendly. Of course, this brings up all sorts 
of issues like what to do with copy and paste, educating users about the 
new kind of display, being able to type ".com" in Chinese in one 
application while being required to type it in ASCII in another, and so 
on. There are some issues, but theoretically, you *can* already display 
".com" in Chinese.

This is not so different from Punycode itself, which you wouldn't 
normally display as is. You first decode it and then show the Unicode to 
the user.

Erik