Hi Michael, I'm enough of a programmer to appreciate your approach. I am reminded of an old programmers' joke: What's the difference between a bug and a feature? Documentation! The point being, I think it's useful to try to think of all kinds of edge cases: even if you ultimately decide not to handle them, it is useful to document why. In the present case I'm not sure what would be best. I think it's reasonably clear that there are scenarios where strict enforcement of the same entity on 2nd level would not be necessary and would even be counterproductive. In my hypothetical .jyväskylä case it would make the TLD less appealing to the registry, as having both versions of the domain would mean there'd be less sellable 2nd level domains, some people and some companies would be unable to get domains with their own name under it. How big an effect that would be, I'm not sure. On the other hand, in general the same entity principle is good, and it would be difficult to come up with a good rule for allowing exceptions. It would have to be a high bar to ensure applicants wouldn't go for it just in case, but still an easily understandable and objective rule. I realize I'm actually just rephrasing your two questions. :-) For the first, I don't as of now see any easy fix. I'm not quite convinced yet there isn't one though, so I'll think about it a bit more. For the second, I guess we could live with it, even acknowledging the downsides. No security issues I can see. So, unless an acceptably easy fix can be found, maybe a note in the final report about it would be the best we can do. Best, Tapani On Thu, May 28, 2026 at 08:40:55AM +0200, Michael Bauland via Gnso-latin-diacritics (gnso-latin-diacritics@icann.org) wrote:
Hi Tapani, hi Bill, hi Amadeu,
thanks for your comments and discussion.
I agree that there are (almost) always some examples that will not work well with some rules. There are similar cases for variants. For example, the German ß and ss are variants of each other. And yes, generally it's ok to replace an ß with ss in German (as a fallback if a typewriter doesn't have an ß). People will understand. However, there are words, where it's not ok. Take "maßen" and "massen", they even have opposite meanings. If I say: "essen in maßen" and "essen in massen" The first means "eating in moderation", while the second means "eating in large quantaties". ;-)
The question is, do we need to make special rules for such special cases? And if so, how complex will those rules be (both in defining them as well as communicating the exception cases to all parties).
Another thing to consider is that these exceptional cases could be different and even contradictory in two languages.
While I love looking at corner cases (it's part of my job when writing software), there are different ways to deal with them depending on what the consequences are and how easy they are to fix. If it's a trivial fix: sure, I always fix them. If it's a complicated fix: it depends. In case they are a security issue, they need to be fixed. If it's just a nuisance for some corner case, it's probably not worth fixing it. It would take a lot of time/effort and would make the whole code more complex and difficult to maintain.
I would suggest a similar approach here. I think we all agree, the suggested rule may be problematic for some corner cases (as explained by Tapani). The questions to ask ourselves are:
1. Is there an easy fix? Can we change the policies easily to cover those? Or would it be complicated and make the whole set of policies more difficult to understand and process? Could these changes even cause a new set of corner cases that would need to be dealt with?
2. Can we live with those corner cases? Are they a security issue?
Cheers,
Michael
-- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland
Dipl.-Informatiker Tel: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software-Entwicklung E-Mail: Michael.Bauland@knipp.de
Registereintrag: Amtsgericht Dortmund, HRB 13728
Geschäftsführer: Dietmar Knipp, Elmar Knipp
Zertifiziert nach DIN ISO/IEC 27001:2017