The proposed String Similarity Evaluation Guidelines fail to take into account that the objective is to deal with the similarity of entire strings as perceived by a large numbers of users inasmuch as is relevant for the use of the string as a TLD.

In this respect, the proposed Guidelines have a mistaken focus on a narrow interpretation of "visual" similarity like the similarity of "com" (as in COM) and "corn" (as in CORN).

String similarity as perceived by users has to take in to account learned equivalence of characters in the context of a string. In this respect, the strings "paraná" and "parana" are similar, as large numbers of users have accepted that in online addresses, the latter "a" commonly replaces the letter "á". This is quite analogous to the similarity of the strings "strasse" and "straße", or of the strings "yıldırım" and "yildirim", which are already taken into account by ICANN's current root-zone label generation rules. There is no reason why the ".quebec"/".québec" set should be treated in any other way than "strasse"/"straße" or indeed the (currently existing) ".中囯" /".中國" variant set. The characters 國 and 囯 are not strictly visually similar; their equivalence is has been learned by speakers of Chinese and Japanese. As users take two strings to be equivalent, they will not distinguish between them, hence the two strings are confusingly similar.

By the same token, plurals or other word inflections should be taken into account as string similarity.

The string similarity determination should not only determine whether strings are similar as perceived by users inasmuch as is relevant for the use of the string as a TLD. The determination should also indicate

- whether the string can be allocated to different unrelated parties,

- whether the strings can be allocated only to the same party, or

- whether only one the strings can be allocated as a TLD.

Unfortunately the process still mostly conflates these fundamentally different situatio