Valid/invalid Label

Alireza Saleh saleh at nic.ir
Fri Feb 27 15:52:25 CET 2009


Dear Jefsey,

You are completely right, but I think this global idealistic solution 
cannot be archived 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.

JFC Morfin wrote:
> 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.
> 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?
> jfc
>
> 2009/2/27 Alireza Saleh <saleh at nic.ir <mailto:saleh at nic.ir>>
>
>     Hi,
>
>     For the past few days, I tried to answer a fundamental question to
>     myself which was, "in what basis a label should be considered
>     invalid or
>     valid under IDNA documents ?".
>     What I currently think as the reason for valid/invalid categorizing is
>     having confusion free international _domain names_ . However, I
>     think it
>     is not possible to have extra-required restrictions only on labels and
>     then expect to have confusion free URI/IRI.
>
>     Another thing which passed in my mind was that, why IDNA has been
>     introduced ?  (1) This is just because of having  fancy domain
>     names or
>     (2) enabling  communities  to benefit from their languages in
>     Internet.
>     If (1), then mixing different script labels is possible and then the
>     global regulation to have confusion free IDNA is required. but  if we
>     consider (2) (which I think was the main reason of IDNA ), then it
>     cannot be regulated globally because languages are based on
>     scripts and
>     the scripts are demonstrated by a part of the UNICODE table which I
>     think it doesn't  have global considerations and its divided to
>     different sections to demonstrate different scripts.
>
>     I think that a possible solution would be considering virtual links
>     between one or some sections of Unicode and one or some TLDs.
>      Then the
>     TLD operators based on those sections  which are linked to his TLD can
>     make proper decisions. In other word,  TLDs would be responsible for
>     their domain names.
>
>     Another inappropriate solution might be having two different policies
>     one for gTLDs and the other for ccTLDs, and of course different
>     prefixes
>     for each policy.
>
>
>     I'm sure taking a proper policy by all  TLDs that currently registered
>     backward incompatible names between IDNA2003 and IDNA2008 both in
>     character definitions or policy changes  ( such as final
>     Sigma,Esszett,ZWNJ) can solve the transition problem and at least be
>     sure the future incompatibilities are their responsibilities and will
>     not cause any global impacts.
>
>     Best
>     Alireza
>
>
>     _______________________________________________
>     Idna-update mailing list
>     Idna-update at alvestrand.no <mailto:Idna-update at alvestrand.no>
>     http://www.alvestrand.no/mailman/listinfo/idna-update
>
>



More information about the Idna-update mailing list