ICANN ICANN Email List Archives

[4gtld-evaluation]


<<< Chronological Index >>>    <<< Thread Index >>>

The minimum string length in U-label (Section 3.2 in Module 2)

  • To: <4gtld-evaluation@xxxxxxxxx>
  • Subject: The minimum string length in U-label (Section 3.2 in Module 2)
  • From: "Seo, June" <jseo@xxxxxxxxxxxx>
  • Date: Wed, 21 Jul 2010 12:35:37 -0400

By: June Seo (jseo@xxxxxxxxxxxx)

Company: VeriSign Naming Services

Date: July 21, 2010

 

The minimum string length in U-label  (Section 3.2 in Module 2)

 

Section 3.2 in Module 2 of the Draft Applicant Guidebook Version 4
states that applied-for IDN scripts must be composed of two or more
visually distinctive characters.  While this minimum length restriction
may effectively limit the possibility of some confusingly similar
strings, and, therefore, possible user confusions among ASCII-based top
level domains (TLDs) and Latin, Greek and Cyrillic-based TLD strings, it
puts potential applicants and their target users of TLD strings in the
non-Latin, non-Greek, and non-Cyrillic-based scripts into a great
disadvantage for the following reasons:

 

-    The shapes of glyphs in many of the non-Latin, non-Greek, and
non-Cyrillic-based scripts are distinctively and intrinsically different
from and not confusingly similar to those of the Latin, Greek and
Cyrillic-based scripts.  Therefore, the base and the intention of this
restriction to avoid confusability are not applicable to IDN TLD strings
in non-Latin, non-Greek, and non-Cyrillic-based scripts.

 

-     Unlike the Latin, Greek and Cyrillic-based scripts in which one
semantic word or one syllable consists of at least 2 or more letters,
many of the non-Latin, non-Greek, and non-Cyrillic-based scripts are
ideographs.  One single ideogram character, for example in Chinese
script, carries a full semantic meaning without ever being combined or
followed by additional character(s). There are tens of thousands of
single Chinese characters as ideograms, and each of those characters can
be a potential choice as an IDN TLD string because each ideogram carries
its full individual semantic meaning as well as a unique phonetic sound.
Therefore, by having this restriction in minimum string length of two or
more, the current version of the Draft Applicant Guidebook significantly
limits the choices of IDN TLD strings for users of the non-Latin,
non-Greek, and non-Cyrillic-based scripts.

 

Because of the 2 reasons described above, IDN TLD strings in the
non-Latin, non-Greek, and non-Cyrillic-based scripts should not be
subject to this minimum length restriction, and each applied-for gTLD
string in these IDN scripts must be evaluated on a case-by-case basis
with no pre-determined minimum string length restriction in place as
proposed in 3.2.  The current restriction that is blindly applicable to
all IDN scripts not only fails to serve the primary intention of
minimizing confusingly similar strings to the Latin, Greek and
Cyrillic-based TLD strings, but also significantly limits the user
choices in the non-Latin, non-Greek, and non-Cyrillic-based scripts in a
disadvantageous and discriminatory manner.  This is especially true for
Chinese, Japanese and Korean scripts. 

 

In order to not to put certain IDN scripts into a disadvantage by
limiting the choices of IDN TLD strings when the confusability is not a
concern, I recommend creations of an exclusion list of scripts that
should not have the restriction of two or more characters, and possibly
an inclusion list of scripts that would always have the two character
restriction. The exclusion and the inclusion lists must contain at least
the following scripts respectively:

 

-          Exclusion list of IDN scripts exempt from the restriction of
two or more Characters:

    Chinese (Simplified and Traditional), Japanese and Korean

 

-          Inclusion list of IDN scripts subject to the restriction of
two or more characters:

    Latin, Greek and Cyrillic

 

Sincerely,

June Seo

jseo@xxxxxxxxxxxx <mailto:jseo@xxxxxxxxxxxx> 

VeriSign Naming Services

 



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy