RE: [gnso-idng] rethinking IDN gTLDs

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Here's what I think is a simpler way to make my point: If the problems
anticipated by offering confusingly similar strings are avoided, then
the restriction of offering the strings is unneccessary.

Chuck 

> -----Original Message-----
> From: Gomes, Chuck 
> Sent: Monday, November 30, 2009 8:37 AM
> To: Avri Doria; gnso-idng@xxxxxxxxx
> Subject: RE: [gnso-idng] rethinking IDN gTLDs
> 
> It might be helpful if we think about what the problems of 
> confusingly similar strings are.  I think one of the main 
> problems is that users may associate X and Y with one another 
> and hence have similar expectations for both. Here are some 
> of the things that they may expect for both TLDs: 1) the 
> registry operator is the same: 2) dispute resolution 
> mechanisms are the same; 3) registration processes are the 
> same; 4) Whois policy is the same (e.g., both thick or both 
> thin); 5) variant tables are the same; etc.
> 
> For discussion sake, let's assume that strings X and Y are 
> deemed to be confusingly similar. Let's also assume that X is 
> an ASCII string and Y is an IDN version of X.  If X and Y are 
> provided by the same registry operator as variations of one 
> another with the purpose of providing a ubiquitous 
> experience, then it seems to me that most, if not all, of the 
> problems pertaining to the problem of associating X and Y are 
> mitigated.  If that is correct, then the problems of their 
> confusing similarity disappear.  On the other hand, if X and 
> Y are offered by different registry operators, then the 
> customer experiences diverge and expectations are not met in 
> various aspects of the TLDs.
> 
> So what is my conclusion?  It is not sufficient to just 
> identify whether two strings are confusingly similar to one 
> another if we do not also determine whether use of the two 
> strings would actually result in the problems for which the 
> new gTLD confusingly similar recommendation were meant to 
> avoid.  In other words, if two confusingly similar strings do 
> not cause the problems we are trying to avoid, then 
> disallowing them would be unneccesary.
> 
> There are at least a couple ways of dealing with this: 1) 
> allow an exception for applicants to offer IDN variations of 
> their strings, which I believe is Edmon's approach; 2) 
> provide guidelines to evaluators to determine whether the 
> problems of offering confusingly similar strings are 
> mitigated by the uses proposed.
> 
> Does this make sense?
> 
> Chuck 
>  
> 
> > -----Original Message-----
> > From: owner-gnso-idng@xxxxxxxxx
> > [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> > Sent: Monday, November 30, 2009 7:15 AM
> > To: gnso-idng@xxxxxxxxx
> > Subject: Re: [gnso-idng] rethinking IDN gTLDs
> > 
> > 
> > 
> > On 30 Nov 2009, at 02:14, Edmon Chung wrote:
> > 
> > > I think I disagree with that interpretation.  The 
> discussion in the 
> > > IDN WG was whether existing gTLDs should be given
> > presumptive priority
> > > or not, and that discussion led to them not given presumptive 
> > > priority.  Whether a mechanism to allow for the 
> processing of such 
> > > application WITHOUT presumptive priority could be
> > implemented is left open.
> > 
> > I think the committee of the whole the presumption was that 
> of course 
> > they could apply, just without any particular priority 
> given to their 
> > application.
> > 
> > > The policies also talk about confusingly similar strings.  
> > But what is
> > > not included is whether a registry (whether existing or
> > future) could
> > > thereupon apply for a confusingly similar string to its own
> > TLD.  That
> > > is the part which I think requires some implementation
> > attention for IDN gTLDs.
> > 
> > 
> > I agree that this is a valid point for discussion.
> > 
> > How does someone apply for a string that is confusingly 
> similar to a 
> > string they already have.
> > 
> > Of course this is only a problem if the meaning of 
> confusingly taken 
> > time mean something more then visibly and becomes a real 
> issue when we 
> > are talking about similarity in meaning.  I have never 
> accepted that 
> > this was a valid interpretation of confusingly similar - 
> though I know 
> > others do accept that broader definition.
> > 
> > > The problem is not whether they are considered separate
> > applications,
> > > but whether there should be a different way to process it
> > given that
> > > the string applied for is in fact confusingly similar to a
> > particular TLD.
> > 
> > You are right about this - is there exemption for the 
> similar TLD to 
> > the entity who holds the TLD it is similar to?
> > 
> > Have thee been comments on this paticular topic that have been 
> > ignored?  I have not paid close enough attention to al the 
> comments to 
> > know.
> > 
> > 
> > a.
> > 
> > 
> >