ICANN ICANN Email List Archives

[2gtld-evaluation]


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

Comments for module 2

  • To: <2gtld-evaluation@xxxxxxxxx>
  • Subject: Comments for module 2
  • From: "Yoav Keren" <yoav@xxxxxxxx>
  • Date: Mon, 13 Apr 2009 00:26:49 +0300

The following are my comments for module 2 of the New gTLD Applicant
Guidebook Version 2:

 

Section 2.1.1.1:

This section states that confusion based on visual, aural and similarity
of meaning may be used by an objector. 

The meaning of this statement is that in the case of IDNs an incumbent
ASCII registry will be practically entitled to have or block all TLDs
equivalent in meaning or sound to the current ASCII TLD, and in all
languages. 

The first ICANN IDN committee - the Katho IDN committee, concluded
against automatically delegating IDN TLDs equivalent to current gTLDs to
the incumbent registries. 

The GNSO IDN WG that published its conclusions two years ago discussed
this issue and have conclude in a consensus that only visual similarity
will lead to actual user confusion, and recommended to limit similarity
to visual. This was in order to abstain from granting current registries
an unjustifiable right to have equivalent TLDs in all languages, and by
that either prevent the introduction of many IDN gTLDs or concentrate
important IDN gTLDs in the hands of mainly western non-IDN community
based companies. 

These views have been supported by many members of the community and by
ICANN officials in different cases.

If phonetic and meaning similarities are to be considered this would
mean that a current gTLD registry that is based on a GENERIC word, is
granted the right for that word and concept in all languages and all
scripts. This is not only unjustifiable from a cultural and a social
point of view, it is not clear whether this is even legal - having a
party get the rights for the equivalents of a generic word and all its
equivalents in meaning or sound - in all languages and all countries.

Moreover, since hundreds of new ASCII gTLDs are expected to be applied
for, this will mean that many additional gTLD concepts will be blocked
from the IDN community once granted as a new ASCII gTLD.

Thus, the similarity should be limited to 'visual'. 'Aural and meaning
similarity' should be removed. 

 

Section 2.1.1.3.2:

In many languages one or two letter strings can have a significant
meaning. According to ICANN staff the current statement in this section
that limits IDN TLDs to only 3 or more characters (in the non-ASCII
script presentation) is intended to prevent visual confusion with
existing and future-possible ISO 3166 strings. 

There is no technical reasoning for the limit of IDN TLDs to 3 or more
characters  - since the punycode is much longer in any case. 

Solving the collision with ISO 3166 future strings can be solved in a
simple way - since the ISO 3166 two characters namespace is a finite
space, the provision for IDNs should be changed so that 2 letter IDN
strings that are visually similar with a string included in the ISO 3166
namespace, will not be allowed - but any other strings will be allowed.
Visual similarity should be resolved in the same way other similarities
are assessed (as specified in section 2.1.1.1) by evaluating the IDN
TLD's similarity with all the still available ISO 3166 strings.

 

Section 2.2.1:

Limiting the exchange of information to only a one time occurrence is
questionable in its general effectiveness. Yet, in the case of
applicants whose mother-tongue is not English, especially in cases of
IDN applicants, this provision will clearly create a great unfair
obstacle to these applicants. 

In case of IDN applicants/non-English speaking applicants additional
exchanges should be allowed. 

 

 

Regards,

 

 

Yoav Keren

CEO

 

Domain The Net Technologies Ltd.

81 Sokolov st.      Tel:  +972-3-7600500

Ramat Hasharon   Fax: +972-3-7600505

Israel 47238

 

 

 







************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.
************************************************************************************


JPEG image



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

Privacy Policy | Terms of Service | Cookies Policy