[jig] RE: [jig] 转发: Today's call

["Sarmad Hussain" <sarmad.hussain@xxxxxxxxx>]

Dear All,

 

I joined the call late today due to some technical difficulties, so missed
the first 15 minutes of the discussion.

 

Based on the comments in the email circulated below, and some discussion
during this and previous call, here are a couple of comments for everybody’
s consideration.

 

1.        Regarding the single character TLDs, and given that:

 

a.       The non-ASCII TLDs get converted to a longer ASCII string, but are
still logically a single character TLD in the source language (if we look at
it from a user’s perspective, not a technical ACE conversion perspective)

b.      One non-ASCII character may even be realized by more than one
Unicode (a base character plus 1-2 combining marks)

 

What makes one LOGICAL character TLD (which may be 1+ ACE and possibly even
1+ Unicode length) special is the fact that it is a very limited set for any
language/script (e.g. for English, consider only 26 possibilities for
one-char label (a..z) vs. 676 possibilities for two-char, 17k possibilities
for three-char labels, and similarly for other languages).  

 

Thus, the question is not whether they are technically possible, or even
whether they can be represented by one or more ASCII characters, but that
the one-char TLDs are a VERY scarce resource, so:

 

                                             i.            What is the
definition of a character in TLD context?

                                           ii.            Should these be
allowed?

                                          iii.            Should these be
treated differently from longer TLDs, in the context of application process?

                                         iv.            If yes, then what
would be the bidding/application process for these special one-char TLDs?  

                                           v.            Are there any other
considerations in one-char case, e.g. 

                                                                    I.
there are cases where scripts are shared by multiple languages in multiple
countries/territories, while there are scripts which are used by a single
community within a single territory/country; 

                                                                  II.
there are scripts where one character represents a character while in others
a character represents a syllable, and yet in some others a character
represents an entire word;

                                                                III.
Some scripts have as few characters (less than 100; very scarce), while in
some other scripts, there may be thousands of basic characters (not so
scarce anymore).  Should they be treated similarly?

 

2.       Desired and undesired variants are VERY hard to determine.  Easier
perhaps for ccTLDs, but much more difficult for gTLDs as there is no context
(ccTLDs have a national context).  

a.       There will be issues, e.g. is “us” variant or “usa” or “üs”?


b.      A conservative definition may cause user confusion with similar TLDs
delegated separately, while a liberal definition may result in
TLD-squatting, where one applicant gets many other TLDs for free and
preventing competition (is “.shop” different from “.shopping” or
“.shopper” or “.shops” or “shp”?).  Similar issues for other scripts.


c.       Variants will cross over cc- and g-TLD boundaries.  Will there be a
joint group looking at this or will there be separate processes for cc- and
g- TLD applications, as is the current design?

 

Regards,

Sarmad

 

 

 

From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
zhangjian
Sent: Tuesday, April 20, 2010 4:18 PM
To: jig@xxxxxxxxx
Subject: [jig] 转发: Today's call

 

 

FYI

 

发件人: Bart Boswinkel [mailto:bart.boswinkel@xxxxxxxxx] 
发送时间: 2010年4月20日 18:33
收件人: zhangjian; Edmon Chung
抄送: Tina Dam; Chris Disspain; Gomes, Chuck
主题: Today's call

 

Dear Jian and Edmon,
As I have indicated to Jian, I have been in touch with Tina. However I do
not know whether or not she’ll be able to attend the call today.  
Included overview of what is current status regarding One Character IDNs and
Variant management to my understanding.
Kind regards,
Bart

One character IDN String
Basic Document:
IDN-Implementation Working Team ?C Final Report

My understanding is that with regards to one-letter IDN string the following
has been recommended by the The IDN Implementation Working Team.

Recommendation 3
3.1 The team does not recommend the banning of one-character gTLDs.
3.2 The team recommends that further ramifications of this issue be
addressed by
policy bodies such as the ccNSO and GNSO.

To my knowledge ther has been no further documents or reports published with
regard to this topic
If no other documents have been produced, this could serve as a starting
point.


Variant management
Basic Documents:
IDN-Implementation Working Team ?C Final Report
Proposed Implementation Plan for Synchronized IDN ccTLDs

Please Note: Proposed Implementation Plan is according to its title land
content limited to IDN ccTLD under the Fast Track.

Presentation: Webinar. This includes reference to ongoing work on Variants (
presentation included).

>From the IDN-Implementation Working Team ?C Final Report.
 Recommendation 1
1.1 Desired Variant Labels must be indicated by the applicant;
1.2 Desired Variant Labels will be allocated, and may also be delegated, to
the
applicant;
1.3 The delegation of Desired Variant Labels, where otherwise appropriate,
is
contingent upon the applicant agreeing to conform to the Rules outlined in
Section
3.3;
1.4 Undesired Variant Labels will be neither allocated nor delegated, and
will be
blocked. 

Recommendation 4
The team cannot make a recommendation about the adoption of DNAME at the
toplevel.
Further technical study is needed, and ICANN should fund this if necessary.

Recommendation 5
A process is needed for managing the delegation of desired variants, and the
allocation and delegation of additional desired variants that may be
identified and
requested at a later time. The team regards this work as external to its own
mandate.