RE: [jig] RE: Today's call

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

Hi Ram,

 

Yes, that is well understood.

 

The discussion I think is whether IDN Language Tables would/could be used
abusively to "create" variants for the applicant's sake in securing extra
TLDs (that does not have a sound linguistic basis).  And how / whether we
should explore any way to prevent that so as to avoid abusive IDN TLD
variants being requested based on abusive IDN Language Tables.

 

Edmon

 

 

 

 

From: Ram Mohan [mailto:rmohan@xxxxxxxxxxxx] 
Sent: Wednesday, April 21, 2010 7:59 PM
To: 'Edmon Chung'; jig@xxxxxxxxx
Subject: RE: [jig] RE: Today's call

 

Edmon,

I do not believe the IDN Fast Track requires either a well defined language
table, or validates it upon submission.  In addition, there seems to be a
perception in the cc community that referring to already submitted and
“approved” language tables (ccTLDs using submitted language tables) would
lead to a faster Fast Track, thereby potentially perpetuating problems that
might exist in the original language table submission(s).

 

I expect language tables submitted for the same language could vary
significantly based on individual geography in the case of ccTLDs and on
general needs in the case of gTLDs.  cc’s may not worry about the overlap
of language “A” with language “B” if language “B” is not prevalent in
their geography ?C a luxury not available to g’s, as you are well aware of.

 

-Ram

 

 

From: Edmon Chung [mailto:edmon@xxxxxxxxxxxxx] 
Sent: Tuesday, April 20, 2010 10:17 PM
To: jig@xxxxxxxxx
Subject: RE: [jig] RE: Today's call

 

Hi Sarmad,

 

You would not have missed much from the first 15 minutes. We recapped the
discussion from last time, and was hoping staff would be able to provide a
briefing on the 2 items (single char IDN TLD and IDN TLD Variants), which we
hope we would base our discussions on.  Since Tina was not able to join, we
did not further the discussion.

 

You made some very good points below.  I am interested to know what you
think about the following:

 

1. Are you comfortable with the definition of "character" based on the IDN
implementation working team final report: "The team suggests using the term
“grapheme cluster” where a combining sequence of a base character and
combining mark(s) appears to be a single character, using the definition of
an “extended grapheme cluster” from section 3 of Unicode Standard Annex
#29."

 

2. When you ask "what would be the bidding/application process for these
special one-char TLDs" does that mean you think the current DAG process
cannot be used?  If so, I am interested to know why?  What needs to be added
to the DAG?  (in the case for ccTLDs, the question would be whether the
current Fast Track process can be used? if not why? and whether/how should
it be incorporated into the ccPDP?)

 

 

 

With regards to "variants" how would your suggestions be reflected in an IDN
Language Table?  In the context of IDN, I think it is generally understood
that "IDN Variants" (whether "desired" or not) are based on a well defined
IDN Language Table.  I think both the Fast Track and the DAG requires a well
defined IDN Language Table, which should take into account local expertise
and linguistic considerations (i.e. variants are not just "desired" by an
applicant but compiled based on a well defined IDN Language Table).  Do you
think that is an appropriate approach?

 

 

Edmon

 

 

 

From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Sarmad
Hussain
Sent: Wednesday, April 21, 2010 2:54 AM
To: jig@xxxxxxxxx
Subject: [jig] RE: [jig] 转发: Today's call

 

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. 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.801 / Virus Database: 271.1.1/2815 - Release Date: 04/21/10
04:14:00

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.814 / Virus Database: 271.1.1/2824 - Release Date: 04/21/10
04:14:00