RE: [gnso-idng] Draft on String Similarity

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

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
> > 
> >
> 
> 
>