Re: Re: stability

James Seng <[email protected]> Thu, 17 Mar 2005 01:16:20 +0800
Newsgroups gmane.ietf.idn
Message-ID <[email protected]>
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
>
>
>