Message-Id: <6.1.2.0.2.20050316131141.03590c50@mail.jefsey.com>
Date: Wed, 16 Mar 2005 13:28:22 +0100
To: Simon Josefsson <jas@extundo.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [idn] Re: stability
Cc: idn@ops.ietf.org
In-Reply-To: <ilumzt47ezc.fsf@latte.josefsson.org>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

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