Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
Ce contenu est uniquement disponible en
Choice 3: Other, please provide detail.
It’s not reasonable to uniformly allocate mixed-case ASCII homoglyphs to Category 1 because high-level confusion is only likely to happen in a limited scenario. Using your example above, the high similarity issue only occurs when an uppercase i (U+0069 LATIN SMALL LETTER I) is compared to a lowercase l (U+006C LATIN SMALL LETTER L). Practically speaking, that scenario is only likely to occur when an uppercase i is used as the first character in a label, i.e. only where someone has capitalized the first letter of the word/label. Therefore, it’s not reasonable to deem these two characters as highly similar in every instance as set out in choice 1. Instead we would suggest an alternative choice 3 that says: Included in the similarity set with visual similarity Category 1 when lowercase character in the set is the first character of the labels. If the lowercase character of the set is not the first character of the labels then include in the similarity set with visual similarity Category 3.
The RySG urges ICANN to make the SSE tool available for applicants to utilize ahead of the application period opening. While we acknowledge the SSE tool output is not definitive as to whether two TLD strings will be deemed confusingly similar, it is an important indicative tool that would help applicants in making their own assessments prior to applying.
Also, it would be very helpful to add more examples (in different scripts) showing how the mapping category (at the label level, as shown in one example in page 11) would determine the preliminary contention sets.