RE: [gnso-idng] Draft on String Similarity

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

No disagreement with your assessment Avri.

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> Sent: Saturday, December 12, 2009 5:47 PM
> To: gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] Draft on String Similarity
> 
> 
> 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
> >>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >> 
> >> 
> >> 
> 
> 
>