RE: [gnso-idng] Draft on String Similarity

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

Objective criteria was also part of the GNSO recommendations.  Of course we 
recognized that, whereas as the goal is to be as objective as possible, it is 
impossible to eliminate all areas of subjectivity.  Otherwise we would probably 
not even need to have review panels.

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Tim Ruiz
> Sent: Monday, December 14, 2009 9:03 AM
> To: gnso-idng@xxxxxxxxx
> Subject: RE: [gnso-idng] Draft on String Similarity
> 
> 
> I agree with Avri's assesment. But as I said, meaning is not 
> mentioned in the DAG nor should it be. The test is 
> "probability of user confusion."
> 
> Another recommendation of the GNSO had something to do with 
> the process being transparent and predictable. If the 
> similarity test involves subjective criteria, it will be 
> neither. I think the evaluation should stick to objective 
> criteria and leave everything else for if/when an objection is raised.
> 
>  
> Tim 
>  
>  
> -------- Original Message --------
> Subject: Re: [gnso-idng] Draft on String Similarity
> From: Avri Doria <avri@xxxxxxx>
> Date: Sat, December 12, 2009 4:47 pm
> To: gnso-idng@xxxxxxxxx
> 
> 
> Hi,
> 
> Good quote.
> 
> Which say to me that it is a complex issue, but that visual 
> similarity is the predominant factor i determining confusion. 
> And only in cases where you can expect the a person to know 
> both languages would meaning enter into the issue as a 
> complicating factor. Likewise for phonetic comparisons.
> 
> So yes, confusion is the key.
> 
> Most can be eliminated based on visual confusion.
> 
> And for the others where there really is a complicating 
> factor that may cause confusion, then and only then does 
> phonetics and meaning come in - and it comes in at the 
> challenge level.
> 
> At least that is how I read it. In no way can I read as 
> saying that phonetics or meaning may be predominant or 
> primary factors in confusion.
> 
> But yes, meaning is mentioned.
> 
> a.
> 
> 
> 
> On 12 Dec 2009, at 23:18, Gomes, Chuck wrote:
> 
> > 
> > Here's a quote from the GNSO recommendations regarding 
> Recommendation 2:
> > 
> > "x) A number of different trademark offices provide 
> guidance on how to interpret confusion. For example, the 
> European Union Trade Mark Office provides guidance on how to 
> interpret confusion. "...confusion may be visual, phonetic or 
> conceptual. A mere aural similarity may create a likelihood 
> of confusion. A mere visual similarity may create a 
> likelihood of confusion. Confusion is based on the fact that 
> the relevant public does not tend to analyse a word in detail 
> but pays more attention to the distinctive and dominant 
> components. Similarities are more significant than 
> dissimilarities. The visual comparison is based on an 
> analysis of the number and sequence of the letters, the 
> number of words and the structure of the signs. Further 
> particularities may be of relevance, such as the existence of 
> special letters or accents that may be perceived as an 
> indication of a specific language. For words, the visual 
> comparison coincides with the phonetic comparison unless in 
> the relevant !
> la!
> > nguage the word is not pronounced as it is written. It 
> should be assumed that the relevant public is either 
> unfamiliar with that foreign language, or even if it 
> understands the meaning in that foreign language, will still 
> tend to pronounce it in accordance with the phonetic rules of 
> their native language. The length of a name may influence the 
> effect of differences. The shorter a name, the more easily 
> the public is able to perceive all its single elements. Thus, 
> small differences may frequently lead in short words to a 
> different overall impression. In contrast, the public is less 
> aware of differences between long names. The overall phonetic 
> impression is particularly influenced by the number and 
> sequence of syllables." (found at 
> http://oami.europa.eu/en/mark/marque/direc.htm)." 
> > 
> > Chuck
> > 
> >> -----Original Message-----
> >> From: owner-gnso-idng@xxxxxxxxx
> >> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Tim Ruiz
> >> Sent: Saturday, December 12, 2009 10:31 AM
> >> To: gnso-idng@xxxxxxxxx
> >> Subject: RE: [gnso-idng] Draft on String Similarity
> >> 
> >> 
> >> Just one other note/correction, in reality the DAG doesn't 
> meantion 
> >> meaning at all in conjunction with the similarity test. The 
> >> overarching issue with similarity is the "probability of user 
> >> confusion." Could meaning be a part of that? Possibly, but 
> that is a 
> >> difficult test, especially when considering various languages/IDNs.
> >> 
> >> Tim
> >> 
> >> -------- Original Message --------
> >> Subject: RE: [gnso-idng] Draft on String Similarity
> >> From: "Tim Ruiz" <tim@xxxxxxxxxxx>
> >> Date: Sat, December 12, 2009 9:22 am
> >> To: "Gomes,Chuck" <cgomes@xxxxxxxxxxxx>
> >> Cc: gnso-idng@xxxxxxxxx, "Avri Doria" <avri@xxxxxxx>
> >> 
> >> 
> >>> Not sure what you are disagreeing with.
> >> 
> >> As I said below regarding the draft statement, I agree 
> with Avri that 
> >> there not be any solution offered, but only a problem statement.
> >> 
> >> My other comments are in regards to what I perceived as intent to 
> >> apply a more broad application of meaning within the 
> similarity test. 
> >> Whether intended or not, the solutions offered in 1. and 2. in the 
> >> draft statement do just that.
> >> 
> >> Tim
> >> 
> >> -------- Original Message --------
> >> Subject: RE: [gnso-idng] Draft on String Similarity
> >> From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
> >> Date: Sat, December 12, 2009 9:00 am
> >> To: "Tim Ruiz" <tim@xxxxxxxxxxx>
> >> Cc: <gnso-idng@xxxxxxxxx>, "Avri Doria" <avri@xxxxxxx>
> >> 
> >> 
> >> 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
> >>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >> 
> >> 
> >>
> 
> 
>