Hi all, instead of writing multiple mails, I'll try to answer the most important points from the recent e-mails in a single e-mail. @Bill You say that the Latin GP was looking for "visual confusable similarity". That's misleading, as they were not merely looking for similarity, but they were looking for "same" and "nearly identical" cases. This is far more strict than what is going to happen in the String Similarity Review of the application process. In that, also cases that are "just" similar will be caught. The String Similarity Review Guidelines may explain what is going to happen, in more detail. They can be found at: https://itp.cdn.icann.org/en/files/internationalized-domain-names-idn/string... In particular, Section 11 page 37 shows a list of classifications: 1. Identical or Near Identical Labels (homograph) 2. Highly Confusable Labels (strongly similar, or near homograph) 3. Similar Labels 4. Distantly Similar Labels (weakly similar) 5. Distinct, not similar The String Similarity Process will (mostly) look up to Level 3 (Similar Labels). So, what the Latin GP considered to be similar or not may be very different from what the String Similarity Review Panel will consider to be similar. @Sergio What is happening at the DNS level is out of scope for us. We certainly won't be changing the DNS to allow more characters than those currently allowed. With the punycode algorithm, there is already the possibility to express even more than your suggested 256 characters. We can express all characters from the RZ-LGR in the DNS using punycode. Also, whether labels are directly available in DNS or via some encoding does not change what people see in browsers and elsewhere. @All * The RZ LGR and its variant definitions is a fact. We cannot change anything there as part of this PDP. There are other processes for this. * Also, the way String Similarity Review is going to work in next round is nothing, we are going to change in this PDP. We also have to take this as a fact (even if it's not pre-determined, what exact cases will be considered as similar and which don't, but that's also out of scope for us). Our goal is very limited. It's an exceptions process. These exceptions are very narrowly defined to find a solution for cases in which an *ASCII* label is going to be considered confusingly similar with a *Latin Diacritic* version of that label (and vice versa) by the String Similarity Review Panel. We will talk more about, what exactly is a diacritic in today's meeting. I'm sure there are many more unfair and incorrect things in the world, many of which I would also like to see solved, but this is the wrong place for it. ;-) Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp Certified according DIN ISO/IEC 27001:2017