Thanks for this, Jeff.
My initial thought is that, yes, this, in my view, is creating new policy.
Ignoring that for a moment, I have to admit that creating a new review process and a new category of strings (homoglyphs and non-homoglyphs) at this late stage in the
process makes me a little nervous. Nevertheless, we will a closer look and get back to you.
While we ponder, and just for my benefit, would you explain again which strings in your proposal would go through that would NOT go through if the reserved names were
simply in the string similarity evaluation (and I agree with your .rodcross likely not being caught in string sim based on 2012). I am not 100% clear on that.
Thank you and best wishes. Lars
From:
"Jeffrey J. Neuman via SubPro-IRT" <subpro-irt@icann.org>
Reply to: "Jeffrey J. Neuman" <jeff@jjnsolutions.com>
Date: Tuesday, 16 September 2025 at 00:10
To: "subpro-irt@icann.org" <subpro-irt@icann.org>
Subject: [SubPro-IRT] A Compromise Proposal for String Similarity
Can we have a potential middle ground proposal for the treatment of the now "Reserved Names"?
1. I was doing some thinking and although we have been using .redcross and .rodcross, the reality is that in 2012 those would not have been considered "confusingly
similar" under the string similarity review. Why do I say this, because the "e" and the "o" are aurally distinct, and do not have the visual similarity that the evaluation was concerned with. They are not near each other on a keyboard, have different vowel
sounds and different meanings. As a result we should not be using that example because it skews the entire discussion.
2. What we are really concerned about are visual homoglyphs in the same script. And the big issue is with the latin script. We are not concerned with .redcross
with a cyrillic "d" because that would mix the scripts would not be allowed. We are concerned with things like:
a).rédcross (Latin small e with acute)
b) .reḋcross
(Latin small e with dot above or d with dot)
c) .redcròss
(o with grave)
d).redcrośs
(s with acute)
or:
a) .o1ympic (digit 1 for “l”)
b) .0lympic
(digit 0 for “o”)
c) . olymplc
(the letter “l” for the letter “i”)
3. Proposal: Treatment of Reserved Names and Similar Strings
4. I understand this could be considered New Policy, but it could align with the 2014 PDP's vision of "protecting" the exact matches, while at the same time ensuring
that we do not allow these homoglyphs get through because of the no string similarity reviews not being performed.
This seems to check the boxes of what we (and ICANN staff in my opinion) are really concerned with (I think) and finds a way that they can co-exist.
Thoughts?
![]()
![]()