RE: [jig] RE: Today's call

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

1.        I agree that any two unique strings are equally rare (one instance
of each). But more character-length allows for more alternatives of same
length.  However, that may not be a significant difference.  

 

3.       IDN Language table is important for IDN TLDs.  It is also
significant for eventual user experience with IDNs as the domain name
registration and resolution process will also be using it.  Therefore it
should be looked at carefully.  It is not only about checking opportunistic
behaviour, but also about avoiding honest mistakes/omissions.  

 

Regards,
Sarmad

 

 

 

From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Edmon
Chung
Sent: Wednesday, April 21, 2010 12:13 PM
To: jig@xxxxxxxxx
Subject: RE: [jig] RE: Today's call

 

1. "Scarcity" is an interesting concept.  However, I am not sure I fully
appreciate the "scarcity" that you describe and how it is different for
single character IDN TLDs.  As an example, one can take the view and argue
that ".com" is as "scarce" as ".a" because they are both unique TLDs. I
wonder if the difference in "scarcity" is that substantial between TLDs with
more than 1 char and those with just 1 char.

 

3. So far, IDN Language Tables have been quite reasonably developed.  If I
understand you correctly then, you are concerned that opportunistic
behaviour may create problematic IDN Language Tables.  If that is the worry,
perhaps we could look into how best to update the IDN Guidelines to better
describe some requirements for how tables should be appropriately developed.

 

Thoughts?

 

Edmon

 

 

 

 

From: Sarmad Hussain [mailto:sarmad.hussain@xxxxxxxxx] 
Sent: Wednesday, April 21, 2010 2:53 PM
To: 'Edmon Chung'
Cc: jig@xxxxxxxxx
Subject: RE: [jig] RE: Today's call

 

1.        The basic question is whether the single character TLDs be treated
as same or different from other TLDs (earlier work has left it up to this
committee to decide). 

 

Other details, e.g. definition of the character and bidding/application
process , in turn only become relevant if the group decides to treat them
differently.  There may be reasons to treat them differently (e.g. scarcity)
and there may be reasons not to treat them differently (e.g. technically
they all represent an ASCII string).

 

If single character TLDs are to be treated differently then, based on the
reasons the distinction is made, the definition of single-character in the
context of TLDs may evolve differently (e.g. extended grapheme cluster in
Lao and Chinese may not be treated similarly, if the rationale is scarcity).


 

2.       Need to look into this further.  

 

3.       Contents of language table are decided by the applicant and are not
evaluated currently.  The submitted language table is accepted.  So if
variants are based on language tables, they arbitrarily depend on the
applicant. 

 

Regards,
Sarmad

 

 

 

 

From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Edmon
Chung
Sent: Wednesday, April 21, 2010 7:17 AM
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