RE: [gnso-idng] Draft on String Similarity

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

Tim,

Meaning similarity just like visual or other similarity may be used to 
determine the probability.  Not sure what you are disagreeing with.

Chuck 

> -----Original Message-----
> From: Tim Ruiz [mailto:tim@xxxxxxxxxxx] 
> Sent: Saturday, December 12, 2009 9:43 AM
> To: Gomes, Chuck
> Cc: gnso-idng@xxxxxxxxx; Avri Doria
> Subject: RE: [gnso-idng] Draft on String Similarity
> 
> 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
> > > 
> > >
> > 
> > 
> >
> 
>