[jig] Follow-up regarding string similarity review

[Olof Nordling <olof.nordling@xxxxxxxxx>]

Edmon and all,
As promised during our call on Tuesday, just a few words about what is checked 
during  the String Similarity Review in Initial Evaluation (for details see 
2.2.1.1 String Similarity Review and the ensuing sections in the Applicant 
Guidebook, http://icann.org/en/topics/new-gtlds/draft-rfp-clean-12nov10-en.pdf 
):

The review is limited to comparison of the visual appearance of each 
applied-for string against existing TLD labels, reserved words and all other 
applied-for strings. The comparisons are "script-agnostic" and occur across all 
strings. Special checks are also made against single and two-character ASCII 
strings.  The review also takes into account case-folding and declared variants 
(as currently defined in the AG, see section 1.3.3). The comparisons are 
performed by a String Similarity Panel The outcomes of a finding of confusing 
similarity is either a refusal of an applied-for string or its placement in a 
contention set for later resolution.

Now, to get to the key aspect discussed at the call - there is NO comparison of 
potential key-stroke errors that a human may make in entering a string. For 
example, an experienced typist may have placed his left hand one step too far 
to the left on the (QWERTY or AZERTY) keyboard and typed DE in place of FR  - 
such aspects are not considered. In analogy with the example, an applied-for 
string  UBR could hypothetically be considered as a 
"hand-displaced-on-keyboard-permutation" of INT and even more hypothetically be 
refused on such grounds, but such considerations would be completely outside 
the remit of the String Similarity Review, which addresses the visual 
appearance of the strings as such.

Hope this is helpful as a background.

Very best regards
Olof