ICANN ICANN Email List Archives

[soac-newgtldapsup-wg]


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

RE: Section 3.6 Work in Progress Re: [soac-newgtldapsup-wg] Section still wanting words

  • To: <soac-newgtldapsup-wg@xxxxxxxxx>
  • Subject: RE: Section 3.6 Work in Progress Re: [soac-newgtldapsup-wg] Section still wanting words
  • From: "Tijani BEN JEMAA" <tijani.benjemaa@xxxxxxxx>
  • Date: Tue, 5 Oct 2010 18:15:32 +0100

Eric and Andrew,

 

Thank you for your efforts and your time.

 

My preference goes to: 

(b) the initial applicant for a language community must be a party which is
associated with or arises organically from that community, and is restricted
to needs and location qualified parties.

 

Thanks again

 

------------------------------------------------------------------

Tijani BEN JEMAA

Executive Director 

Mediterranean Federation of Internet Associations

Phone : + 216 70 825 231

Mobile : + 216 98 330 114

Fax     : + 216 70 825 231

------------------------------------------------------------------

-----Message d'origine-----
De : owner-soac-newgtldapsup-wg@xxxxxxxxx
[mailto:owner-soac-newgtldapsup-wg@xxxxxxxxx] De la part de Eric
Brunner-Williams
Envoyé : mardi 5 octobre 2010 17:06
À : soac-newgtldapsup-wg@xxxxxxxxx
Objet : Section 3.6 Work in Progress Re: [soac-newgtldapsup-wg] Section
still wanting words

 

 

All,

 

Andrew and I spoke for about 90 minutes yesterday morning, and we've 

exchanged email this morning. This is simply my impression at this 

point in time:

 

First, there are several examples of bundling, examples where the 

simple "one application, one string" statement has been overtaken by 

events. These are:

 

      o multiple strings for China, to solve the SC/TC equivalence problem

 

      o multiple strings for Saudi Arabia, to solve Arabic Script variant 

character problem

 

      o multiple strings for Greece, to solve the Greek Tonos problem

 

Second, we are in agreement on everything except whether an acceptable 

outcome is:

 

      (a) the initial applicant for a language community may be any party 

which seeks to offer registry services using the associated script and 

language, and is not restricted to needs and location qualified parties,

 

or

 

      (b) the initial applicant for a language community must be a party 

which is associated with or arises organically from that community, 

and is restricted to needs and location qualified parties.

 

My impression is that Andrew, and possibly Richard, consider that one 

registry in a Script and language will encourage subsequent, and 

competitive, applications for the same Script and language. Hence the 

discount, tied to the size of the language community in nominal 

percentages, made available to non-qualified applicants.

 

My concern is the case where the community is capable of supporting a 

registry, and the relationship of the eligibility policy to the 

community is at risk if the eligibility policy arises externally. As a 

hypothetical, the .cat trajectory may have been less satisfactory if 

the policy for .cat were made by the .es (Spain) registry operator, or 

by Verisign, rather than by Fundatio PuntCat.

 

Perhaps this is a "growth will cure error" position and a "error may 

prevent growth" position.

 

My view is that if the benefit is limited to qualified applications, 

each qualified applicant will use it completely for the advancement of 

their community, and not attempt to "assist", or capture, some other 

language community, prior to the development of "ICANN awareness" and 

the capital accumulation necessary for an application by the second or 

subsequent communities.

 

Everything else I'm confident that either Andrew or I could hold the 

pen to the satisfaction of the other, there is only this one issue to 

address, and his view may be the better one.

 

I suggest people think a bit about these two alternatives and let 

Andrew or I know.

 

Eric



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

Privacy Policy | Terms of Service | Cookies Policy