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
