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