Re: [idn] Re: stability

James Seng <james@seng.cc> Wed, 16 March 2005 17:23 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12511 for <idn-archive@lists.ietf.org>; Wed, 16 Mar 2005 12:23:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DBc8P-0002Es-Rg for idn-data@psg.com; Wed, 16 Mar 2005 17:16:41 +0000
Received: from [203.117.75.21] (helo=red-aura.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DBc8O-0002Ee-Et for idn@ops.ietf.org; Wed, 16 Mar 2005 17:16:40 +0000
Received: (qmail 10147 invoked from network); 16 Mar 2005 17:19:54 -0000
Received: from ip2.globalevents.iinet.com (HELO ?10.10.10.185?) (jseng@70.97.79.2) by red-aura.com with RC4-SHA encrypted SMTP; 16 Mar 2005 17:19:54 -0000
In-Reply-To: <6.1.2.0.2.20050316131141.03590c50@mail.jefsey.com>
References: <421B8484.3070802@vanderpoel.org> <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> <42322CE2.4040509@vanderpoel.org> <4232B2FD.1080104@vanderpoel.org> <4232BA56.5090001@vanderpoel.org> <iluk6odazwb.fsf@latte.josefsson.org> <00e801c528a8$99ad37d0$72703009@sanjose.ibm.com> <ilull8qb5n5.fsf@latte.josefsson.org> <42367B63.6080300@vanderpoel.org> <4237450A.9010901@v.loewis.de> <423754F3.50405@vanderpoel.org> <ilumzt47ezc.fsf@latte.josefsson.org> <6.1.2.0.2.20050316131141.03590c50@mail.jefsey.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <b188a9233091d865362598359fe6851c@seng.cc>
Content-Transfer-Encoding: 7bit
Cc: idn@ops.ietf.org, Simon Josefsson <jas@extundo.com>
From: James Seng <james@seng.cc>
Subject: Re: [idn] Re: stability
Date: Thu, 17 Mar 2005 01:16:20 +0800
To: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
X-Mailer: Apple Mail (2.619.2)
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-1.3 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

Sorry, I wasn't able to decipher what JFC is trying to say with all the 
strange terminologies.

It is an important topic and I better don't pretend to know what he is 
talking about. Can someone help to translate this to English to me?

-James Seng

On 16-Mar-05, at PM 08:28, JFC (Jefsey) Morfin wrote:

> On 22:53 15/03/2005, Simon Josefsson said:
>> I believe it would be useful to start thinking of the problem in terms
>> of a transition plan from what we have today and what we would like to
>> have tomorrow.  It is not clear to me exactly what we would like to
>> have tomorrow, so settling that would have to be part of the plan as
>> well.
>
> That part seems quite easy to address. We want to be PAD compatible, 
> so the users have a single system. This means that we may have three 
> systems:
>
> Unicode to IP   tables
> Unicode to DN tables
> Unicode to lingual SLD to display as a lingual TLD tables
>
> using NameScript tables listing the Unicode codes permitted throught 
> out the FQMLDN to prevent homograph problems. Every label being an ACE 
> label in an MLDN, ASCII in an ascii label.
>
> The general construct being labels.table-indicator.tld. The table 
> indicator being by default the table indicator of the TLD. This way 
> existing ascii TLDs are label.ascii-indicator.tld (the ascii indicator 
> is not necessary). The same for a Chinese TLD, 
> chinese.chinese-indicator.tld: the chinese indicator is not necessary. 
> Every label part of a MLDN is subject to a punycode translation and a 
> nameprep removing the codes not compatible with its indicator.
>
> This fully permits atypical domain names to be registered in using a 
> no-filtered indicator, easy to underline in an application display.
>
> This also permits table-indicator.TLD to be converted in the proper 
> MLTLD display or from the MLTLD entry.
>
> This is obvsiously fully compatible with the DNS and ask no complex 
> special program, procedures, contract by Registries.  No need for 
> lingual users to switch to Handles. It can even support phonetic, menu 
> server, icon based vernacular names. This is also what is already in 
> use.
>
> This is what the initial demand was for.
> jfc
>
>
>