ICANN ICANN Email List Archives

[gnso-rn-wg]


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

[gnso-rn-wg] IDN WG Recommendations for Single/2-Character Subgroup

  • To: <gnso-rn-wg@xxxxxxxxx>
  • Subject: [gnso-rn-wg] IDN WG Recommendations for Single/2-Character Subgroup
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Wed, 25 Apr 2007 19:06:26 -0400

Here are the IDN-WG recommendations that I promised to send in todays
meeting for reference by the Single/2-Character Subgroup.  Note the last
one I included below does not relate to the point I made in our call
today but does relate to symbols so I included it as well.
 
These recommendations, with the exception of the last one, could also be
useful for consideration by other subgroups as you consider ASCII and
IDN recommendations for reserved names.  Any recommendations that would
give an advantage to ASCII gTLD applicants over IDN gTLD applicants
might relate to the recommendations below.
 
Areas of Agreement by the IDN-WG (Strong Support)
 
4.1.1 Avoidance of ASCII-Squatting: 

Agreement to avoid "ASCII-squatting" situations where applications for
new non-IDN gTLD strings, if accepted for insertion in the root at an
earlier stage than IDN gTLDs, could pre-empt later applications for IDN
gTLDs. 

E.g. a new non-IDN gTLD ".caxap", if accepted, would prohibit the
acceptance of a later application for an IDN gTLD ".caxap" (in Cyrillic
script and meaning "sugar" in Russian). 

 

4.1.6. Limit Confusingly Similar Strings: 

Agreement that measures be taken to ensure that an IDN gTLD string with
variants (see 4.1.4 and 4.1.5 above) be treated in analogy with current
practice for IDN SLD labels, i.e. strings that only differ from an IDN
gTLD string by variants (see above) are not available for registration
by others. 

Note: This is equivalent in effect to the provisions against
"confusingly similar" strings foreseen in the New gTLD recommendations.

 

Areas of Support by the IDN-WG (Some Support)

 

4.2.1

Support for a first application round open to both non-IDN gTLDs and IDN
gTLDs, if possible. 

 

4.2.2

Support for avoiding "hostage" situations in planning a new non-IDN gTLD
application round; neither non-IDN gTLDs nor IDN gTLDs should be delayed
due to the other. 

 

4.2.6

Support for resolving IDN policy issues before launch of application
round. 

Alternative view; prioritize launch of IDN gTLD over non-IDN gTLDs. 

Alternative view; provide opportunities to reserve IDN gTLD strings in
case the first application round can only address non-IDN gTLD
applications fully. 

Note: Whether there will be a timing issue or not depends on the
progress of the new gTLD policy, including IDN policy aspects, as well
as on the progress of the protocol revisions and technical tests
regarding IDN at the top-level. They all need to have advanced
sufficiently before a decision can be made to go ahead with IDN TLD
deployment.

 

 

4.2.21  (Note: this one does not relate to the point I made in today's
call but is relevant to symbols.)

Support for elimination of non-language characters, as foreseen in the
IDN protocol revision. 

            Alternative view: to signal concerns about symbols that may
be 

            eliminated but would potentially be needed for human
communications.

 

 

 
Chuck Gomes
 
"This message is intended for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. Any
unauthorized use, distribution, or disclosure is strictly prohibited. If
you have received this message in error, please notify sender
immediately and destroy/delete the original transmission." 
 


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

Privacy Policy | Terms of Service | Cookies Policy