RE: [gnso-idng] Draft on String Similarity

["Tim Ruiz" <tim@xxxxxxxxxxx>]

That's not true Chuck, at least not in the broad sense as you state it
and as implied at various times by some on this list.

In the current version of the DAG meaning is only considered in a very
limited sense - to determine if there is a probability (not just the
possibility) of user confusion. What I am concerned about is any attempt
to take it beyond that. In other words, .business should not be found
confusingly similar to .biz, and .athletics should not be found
confusingly similar to .sports. Those may not be the best examples, but
you get the idea.

Otherwise, the door is open for gTLD operators or others to use the
similarity test to attempt to limit competition.


Tim
 
-------- Original Message --------
Subject: RE: [gnso-idng] Draft on String Similarity
From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
Date: Sat, December 12, 2009 8:05 am
To: "Tim Ruiz" <tim@xxxxxxxxxxx>, "Avri Doria" <avri@xxxxxxx>
Cc: <gnso-idng@xxxxxxxxx>

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. 

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Tim Ruiz
> Sent: Friday, December 11, 2009 5:45 PM
> To: Avri Doria
> Cc: gnso-idng@xxxxxxxxx
> Subject: RE: [gnso-idng] Draft on String Similarity
> 
> 
> I don't believe that the definition of similar should include meaning.
> In fact, including it opens up even more serious problems 
> than those you are trying to solve. So I agree with Avri that 
> there not be any solution offered, but only a problem statement.
> 
> 
> Tim
> 
> -------- Original Message --------
> Subject: Re: [gnso-idng] Draft on String Similarity
> From: Avri Doria <avri@xxxxxxx>
> Date: Fri, December 11, 2009 8:41 am
> To: gnso-idng@xxxxxxxxx
> 
> 
> Hi,
> 
> On first reading a few things:
> 
> - to prevent inflaming tensions, I recommend you not use a 
> strong that many would think a ccTLD as an example. yes I 
> totally understand it is just an example, but I think we 
> would be better off, and the argument simpler, with a string 
> like .duck and it translations.
> 
> - while I know some of you think that the battle over 
> similarly including meaning is a completed discussion, I for 
> one, do not agree.
> Not because I think it isn't relevant to the discussion of 
> some challenges, but because the determination of 
> similarity/identity in meaning in trasnlation and ideas of 
> demarkation in those cases are not cut and dried. I therefore 
> think it more appropriate to say:
> 
> > First, for some the current meaning of "similar" is now 
> broader than "visual similarity", and appears to include "meaning".
> 
> I ask does the extended definition of similar include 
> transliteration and homonyms for some as well as translation?
> 
> - i believe that we should just be stating the problem and 
> not a solution. We do not have a consensus on the solution - 
> nor is continuing with discussion to find a compromise 
> solution something i think in the design teams charge unless 
> the council suggest it is. I still think the process as it 
> stands may be adequate, but I think it needs more study in 
> terms of these questions. Hence, I think it is important that 
> the issue be flagged. I recommend cutting out the solution 
> section completely. If we don't it, then we need to expand it 
> to all include all the possible solution we can think of and 
> that would be time consuming.
> 
> - I did not understand your point about the restriction to UN 
> languages in the root.
> 
> Otherwise, I think it is close and rather good.
> 
> thanks for taking the first cut and subjecting it to my comments.
> 
> a.
> 
> 
> On 11 Dec 2009, at 15:11, Eric Brunner-Williams wrote:
> 
> > 
> > Councilors,
> > 
> > During the past weeks the participants in the 
> gnso-idng@xxxxxxxxx mailing list (IDNG) have discussed, on 
> the mailing list and in conference calls, aspects of the 
> situation which exists following the Board's vote at Seoul.
> > 
> > One area of discussion which raises a policy issue is 
> confusingly similar strings. Because this seems an area where 
> the obvious right thing has already been done we need to draw 
> attention to two aspects which have been overlooked.
> > 
> > First, the current meaning of "similar" is now broader than 
> "visual similarity", and appears to include "meaning".
> > 
> > Second, the underlying assumption in the evaluation process 
> is that each evaluation is independent of all other evaluations.
> > 
> > These, a rule (about a string in an application) and a 
> meta-rule (about all applications), have a consequence which 
> we suggest is not desirable.
> > 
> > In the following example we use "china" and "中国" (chung 
> guo), simply as a well-known example of two strings. We 
> ignore that both are part of the universe of strings more 
> likely to pertain to ccTLD and their policy body than the 
> GNSO, for the purpose of illustrating the policy problem.
> > 
> > The string "china" and "中国" (chung guo) are "similar" in 
> meaning, therefor they form a contention set. Under the 
> current rules in DAGv3, only one application who's string is 
> a member of a contention set may proceed towards delegation. 
> Whether the choice is by order of creation, or amongst 
> contemporaries, by community evaluation and/or auction, the 
> result is the same. One member of an (extended, in the sense 
> of including existing registries) contention set thrives. All 
> others fail.
> > 
> > This is the proper and correct end, except for one case 
> which is more likely to exist for applications for IDN 
> strings than for restricted ASCII (letters, digits, hyphen) 
> strings. That case is where two, or more, applications for 
> similar strings are advanced by a single applicant, or two or 
> more cooperating applicants.
> > 
> > Returning to our "china" and "中国" (chung guo) example, if XYZ Co. 
> > applied for both "china" (application #1) and "中国" 
> (application #2), the current rules can not allow both 
> strings to exist in the root, though both are brought by the 
> same applicant.
> > 
> > The fundamental rational is that confusion is harmful. This 
> rational is not universally correct. There are instances 
> where confusion results in no harm, and more importantly, 
> where "confusion" creates benefit.
> > 
> > Because "beneficial confusion" is not obvious to users of 
> Latin Script, an example, we offer the original example of 
> cooperation among "applicants" to benefit their registrants 
> and users, through "similarity".
> > 
> > In 2001, the registries for China, Taiwan, Hong Kong and 
> Macao discussed cooperation so that mixing of Simplified 
> Chinese, prevalent in China, and Traditional Chinese, 
> prevalent in Taiwan, but interchangeable without loss of 
> meaning, would not result in user confusion. These 
> "applicants" cooperated to create "beneficial confusion", so 
> that "similar strings" actually had similar meaning, that is, 
> resolved as expected by their user community.
> > 
> > No user "confusion" resulted from this multi-applicant 
> cooperation, except perhaps in Marina del Rey.
> > 
> > Coordination to create "beneficial confusion" may exist 
> where one applicant submits two or more applications, as in 
> the "china" and "中 国" (chung guo) example, or where two or 
> more applicants submit two or more applications, as the four 
> cooperating Chinese registries did, almost a decade ago.
> > 
> > It is possible that applicants for two or more similar 
> strings could, upon failure, resort to extended evaluation, 
> where the cause of the failure is similarity with an existing 
> TLD. Present registries seeking similar IDN delegations could 
> simply cost in the extended evaluation cost as part of the 
> application cost. This is inelegant, but not fatally so.
> > 
> > Unfortunately, for applicants simply seeking two or more 
> delegations with similar meaning, independent of script, as 
> in the "china" and "中 国" (chung guo) example, initial 
> evaluation failure and extended evaluation are not available. 
> The contention set consisting of two strings and one actual 
> applicant go to auction, with absurd outcome from the 
> business perspective, and tragic outcome from the language 
> perspective, as one script choice eliminates all others, for 
> some meaning defined construction of "similarity".
> > 
> > We suggest the Council consider the following to cure this defect.
> > 
> > 1. that the meta-rule that all applications are 
> independently evaluated be modified so that cooperating 
> applications may, if the contention set they form contains no 
> non-cooperating applications, proceed in the evaluation process.
> > 
> > 2. that the rule that applications for strings which are 
> "confusingly similar" to existing registries, where the 
> application is brought by the existing registry to which 
> "confusing similarity" exists, be modified so that these 
> applications do not fail the initial evaluation and require 
> extended evaluation, or some other heroic measure.
> > 
> > Both of these recommendations have generalizations.
> > 
> > The independent applications presumption overlooks the 
> certainty that the legacy operator and application authors of 
> 2000 and 2003-2006, and new authors, will each author 
> multiple 2010 applications, some of which have common 
> characteristics, such as "similarity" and "cooperation", and 
> absent a mechanism to "signal" the similarity to the 
> evaluation process, adverse outcomes and process 
> inefficiencies are certain.
> > 
> > A property common to two or more applications should be 
> discoverable by the evaluation process, especially when the 
> applicants desire this common property to be known to the 
> evaluation process.
> > 
> > The presumption of user confusion and harm where similarity 
> exists overlooks the utility of similarity, and more 
> profoundly, substitutes a Marina del Rey centric meaning and 
> utility test for the meanings and uses that exist at large.
> > 
> > Correct use by two or more applications, that is, a 
> property common to only the strings sought by two or more 
> applications, can, and should be discoverable by the 
> evaluation process.
> > 
> > The Council need not necessarily look to the 
> generalizations of the modifications of rule and meta-rule we 
> suggest to cure the anticipated problem of similar strings in 
> IDN applications, but should it do so, the IDNG participants 
> are prepared to further inform the Council.
> > 
> > As it stands, the IDNG participants now understand the 
> unintended effect of the "similarity" rule, and the 
> "independent application" meta-rule, to be that only one of 
> the six UN languages may be used for any identifier in the 
> root, with adverse consequences for cooperation and 
> harmonization of operational practice and user expectations.
> > 
> > The IDNG participants thank the Council for its time and 
> attention considering the its initial work product.
> > 
> > 
> > This ends the draft. Chuck, Edmond, Avri, edit to your 
> heart's content.
> > 
> > Eric
> > 
> >
> 
> 
>