RE: [gnso-idng] Draft on String Similarity

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

Eric,

One problem with restricting to visual similarity is that user confusion
is possible for other types of similarity besides visual.  The objective
was to minimize user confusion in general, not just visual user
confusion.

Chuck 

> -----Original Message-----
> From: Eric Brunner-Williams [mailto:ebw@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Saturday, December 12, 2009 1:51 PM
> To: Gomes, Chuck
> Cc: Tim Ruiz; Avri Doria; gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] Draft on String Similarity
> 
> Gomes, Chuck wrote:
> > The GNSO new gTLD recommendations approved by the Board and 
> hence the implementation in the DAG already include meaning 
> so it would require a policy change to exclude meaning.  
> 
> 
> I wonder if this was mentioned to the rep from the Arab 
> League at the IGF, who presumably was thinking of both 
> "arab-in-latin-script" and "arab-in-arabic-script".
> 
> Maybe they'll consider going back to the iso3166-MA route.
> 
> A problem with attempting to determine the "probability of 
> user confusion" is that we don't, at present, other than the 
> evaluator(s) not being arbitrarily stupid (and I spent an 
> hour with the KPMG guy designing the process and I think it 
> is not only possible, but probable), have a way of knowing 
> that it is the Arab League which is applying for 
> "arab-in-latin-script" and "arab-in-arabic-script".
> 
> It is just plain weird, cracked even, to think that Egypt 
> will eventually have .eg, .egypt (in latin) and .egypt (in 
> arabic), and maybe even .egg, and the city of Cairo will have 
> to settle for one of latin, or arabic, but not both.
> 
> This whole problem goes away if we stick with visual 
> similarity, as then we're just talking about character 
> variants, which is purely an IDN problem, in which case we 
> don't need the evaluation process to "discover" that 
> applications A and B are brought by the same applicant.
> 
> The .bz vs .biz caper was good clean fun in comparison to 
> what we may be looking at, and people I used to think were 
> rational beings are now trying to sell 
> a-label-kills-an-entire-taxonomy theories of 
> non-confusability and/or necessary-diversity-utility tests 
> for new gTLDs.
> 
> Seriously, what problem are we trying to solve? Fat fingers 
> and typos, the retail cops-and-robbers problem or business 
> plans that are so thin that actual competition will kill 
> them? We know after 10 years that "com" was not harmed by 
> "biz", which presumably "mean" the same damn thing -- six 
> bucks. Could "kom" or "comm" or ... actually harm "com"?
> Other than in the three independent markets, the China root 
> market, and the Israel and Korea browser hack markets, "com" 
> is in a greenfield. If, after Verisign expresses its 
> preference for "com" in a script, aren't we really done?
> 
> Do we particularly care if some idiots want to go 
> head-to-head with Verisign with some script equivalent to 
> "kom" or "comm"? If Google sprinkles monitary pixie dust on 
> them, as they do for this-name-is-in-com.co (Columbia, 
> NeuStar's turnabout on the bz/biz exploit), they may have a 
> business, but even so, the immediate harm they present is 
> waste of a unit of evaluation (argued by some to be infinite, 
> though whether it is ment delay or capacity may be an 
> interpretation question), a unit of root zone delegation 
> (also argued by some, NOT me, to be infinite), and the very 
> thin set of claims that it will harm users more than they are 
> harmed by not recalling if NANOG is in .com or in .net, harm 
> Verisign's brand, or harm ICANN's reputation.
> 
> And to be off-topic and informational, today a non-binding 
> referendum is taking place in Catalonia, on the question of 
> independence. At some point in the distant future we (the 
> GNSO) may need a means to transition a g to a cc.
> 
> Eric
>