Valid/invalid Label

JFC Morfin jefsey at jefsey.com
Fri Feb 27 13:36:10 CET 2009


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

> 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
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090227/1c9c2f4d/attachment.htm 


More information about the Idna-update mailing list