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