Valid/invalid Label

[JFC Morfin]

At 15:52 27/02/2009, Alireza Saleh wrote:
>Dear Jefsey,
>
>You are completely right, but I think this global idealistic solution
>cannot be achieved because IETF is trying to support almost all
>requirements for all languages as well as making it safe which looks
>impossible to me. It is possible if we forget the real support of
>cultures and languages in domain names and write very restricted
>documents such as IDNA2003 and keep reviewing it and hope no backward
>incompatible issues happen.

Dear Alireza,
the IETF tries to support an English internationalisation solution, 
which means to use an EnglishASCII basis (principle, case folding, 
etc.) to interface around 150 languages ICANN needs for their Fast 
Crack project.

This is in line with the whole Unicode proposition. Except that 
Unicode was not designed with IDNs and IRIs in mind, so some tuning 
is necessary. This "tuning" is mre complex if one demand too much.

This is why my initial position was either let IDNs be an Unicode 
application or let multilingualize the DNS. Then we came with the 
Internet PLUS concept that permits to unbundle innovation from 
legacy. This permits to progressively deploy and develop the Intersem 
(Semantic and Multilingual Internet I am mostly interested in) as an 
externet (i.e. an open "cloased walled garden") : those who want it 
can have it.

The elegance of the plan is that "internationalization is 
multilingualization localization, i.e. what a lingual system must at 
least offer in a multilingual context". This means that IDNA2008 can 
be considered as the "English to/from full English and to other 
languages" part of a multilingualized DNS. And therefore, as a 
transition from IDNA2003. This was the reason why we asked our 
initial questions to Vint Cerf about his IDNA plans. This is why we 
did not bother too much about the capacity of IDNA2008 to fully 
support our needs. As long as it does not prevent us to add their 
support in parallel. We just need early publication and simplicity.

The progressive implementation sequence by users (not network 
deployement) then becomes :
- DNS - existing basis. - everyone has it.
- IDNA2003 - ex. the Chinese Names - supported by browsers.
- IDNA2008 - the work of this WG - will be supported by browsers.
- IDNA2008+ - the additional "x.--" prefixes and algorithms (outside 
of the WG scope) - can be implemented on open source browsers 
(FireFox and Chrome).
- this ML-DNS global adminance (technical gouvernance) could then be 
organised as a test with sociocultural TLD projects.

> > Dear Alireza,
> > your are totally correct and I approve you 100%. However, we need to
> > find a solution which looks 100% the same to gTLD and ccTLD users. To
> > look the same we need a same enforced logic people can trust and the
> > same typography in each language.  This does not means the same
> > algorithm, nor the same tables.
> >
> > The IETF has an idealistic globalization point of view, based upon an
> > internationalization experience and an ancient deployment through ISO.
> > This has lead to the choice of Unicode as adapted to the computers.
> >
> > Our problem today is that the Unicode premises are more restrictive
> > than we want. So, the question is : (1) should we adapt Unicode (and
> > the machines ?) to the people diversity (what is not our charter), (2)
> > should we adapt the people's diversity to Unicode (what many oppose),
> > or could there be a middle solution permitting (2) without forcing (1).
> >
> > By essence that solution must be based upon the same architecture to
> > inspire trust. It must be diversified in order to support typographic
> > and linguistic usage diversity. It must include IDNA2003 support. It
> > must be TLD Manager driven, in using simple universal
> > tools/algorithm/procedures. It must not permit the risks at Zone
> > Management level that John Klensin documented. It must not imply any
> > responsibility of the Zone Manager in the users' applications
> > opérations. There

>I don't agree, cause the current IETF documents permit mapping within
>applications and it means it trusts the applications as well as the
>current documents relay on some sort of completion policy which are made
>by registries.

What I mean is that the Registries establish the rules the users are 
to deal with. They do not warrant users that their applications will 
work. what they do with their applications for it to work.

This means that the proper sequence should be:
- someone wants to support Unicode label in an application
- the application should tell him/her the A-Label and the prefix to register.
- the person applies for that domain name.
- the registry/zone manager accepts or not the domain name as per 
their namespace management policy.

This does not represent any procedural change nor additional cost for 
the Registry/Zone Manager.
What is to be done is to find the most compact formating solution set 
to support most of the punycode related policies to be adopted by TLD 
Managers. The question is the question of inheritance from level to 
level. I would favor that a TLD Mananager could impose a unique 
format within a single URL..

> > should be a simple way to associate an IDN to one or several others of
> > different format, typography, language, script (ex. Trade Marks).
> > There must be a "language ledger" level cooperation to insure similar
> > support rules among the equivalent linguistic zones of the different TLDs.
> >
> > Did I forget something?

Now, if you would prefer this to be included in IDNA2008, or as a 
complementary RFC by this working group, I would suggest you make the Chair
- consider that "x.--" are variations concerning extensions improving 
the "xn--" core, not changes.
- the issue should be discussed on a dedicated sub-list, as not to 
interfere with the regular IDNA2008 simplified (hence more robust) project.

jfc