Same entity on 2nd level
Thinking of the test.domain vs tést.domain scenario, I find myself concluding that enforcing the same entity principle on 2nd level domains is not viable. Confusion potential is real, but as it already exists for extant TLDs, ASCII as well as IDN ones, and we cannot do anything about those, can or should we enforce stricter rules for our case? Same entity requirement on 2nd level could also have some undesirable side-effects. What would happen if cafe.quebec and café.quebec were already extant with different registrants when .québec is applied for? Should that block .québec application? Or should the policy have some kind of grandfather clause? I don't see why café.quebec and cafe.quebec would be less likely to cause confusion than cafe.québec and café.québec. If anything the latter should be safer simply because people using .québec are more likely to pay attention to accents. Likewise, sakki.fi, säkki.fi and šakki.fi (all extant domains with different registrants) are unlikely to confuse Finnish speakers, and others are less likely to use .fi domains. I guess we could require applicants to document their policy in this regard, perhaps including that they must alert registrants to the issue, but I would not insist on strict same entity principle on 2nd level. I remain, however, open to persuasion. :-) -- Tapani Tarvainen
Dear Tapani, In Canada both .ca and .quebec are enforcing the same entity principle at the second level. There are some minor difference in the policy between .ca and .quebec, but essentially the result is the same. Here is the .ca (CIRA) policy : How does .CA manage IDNs? In 2012, CIRA introduced support for the full range of French characters in .CA domain names: é, ë, ê, è, â, à, æ, ô, œ, ù, û, ü, ç, î, ï, ÿ. When a .CA is registered, all variations of a domain name with these accented characters (what we call the “administrative bundle”) are reserved for the registrant and cannot be registered by anyone else. Although these domain names are reserved for the registrant, they are not active – that is they do not automatically resolve. The registrant must register them with a registrar that offers this service. Each domain name you wish to use must be registered individually, with the same registrar. Each of these registered names will have its own lifecycle. To use an example, there are 18 variants in the administrative bundle for www.cira.ca : www.cira.ca cirâ.ca cirà.ca cîra.ca cîrà.ca cïra.ca cïrâ.ca cïrà.ca çira.ca çirâ.ca çîra.ca çîrâ.ca çîrà.ca çïra.ca çïrâ.ca çïrà.ca çirà.ca For .QUEBEC, when a registrant seeks a second level domain name with a diacritic (IDN), he will get it's ASCII fallback second level domain name at the same time. And over and above a same .CA bundle policy gets in place, enforcing the same entity policy. I cannot speak for .ca or CIRA, but for .QUEBEC, when the .QUÉBEC will be delegated, the same entity bundgling policy will be extended at the second level for all, including for the already delegated .quebec. with or without diacritic. This is very conservative, one could say, but it gives a security space for the Brand, the registrants and the users. This was done, at the Registry level, and the Registry Operator level. We understand that the registries want to keep an upper hand of what policy should be put in place in their own turf at the second level. We respect that, and we did not propose that the way it is manage here in Canada is a ones fits all. I remember during the IDN PDP 2, that this was discussed for variants and the decision regarding the restriction at the second level was left to the registry, and not a policy in the PDP. I hopes it helps to understand that café.quebec, cafe.quebec, café.québec, cafe.quebec and all the others câfé, cäfé, càfé, cafe, cafê, cafè, cafë, càfë, etc etc would be all be part of one bundle, one registrant, one registrar, one Registry operator, : or the same entity So no confusion here. Similarity yes but for the same entity. Best Claude Le 22 mai 2026 à 2 h 32, Tapani Tarvainen via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> a écrit : Thinking of the test.domain vs tést.domain scenario, I find myself concluding that enforcing the same entity principle on 2nd level domains is not viable. Confusion potential is real, but as it already exists for extant TLDs, ASCII as well as IDN ones, and we cannot do anything about those, can or should we enforce stricter rules for our case? Same entity requirement on 2nd level could also have some undesirable side-effects. What would happen if cafe.quebec and café.quebec were already extant with different registrants when .québec is applied for? Should that block .québec application? Or should the policy have some kind of grandfather clause? I don't see why café.quebec and cafe.quebec would be less likely to cause confusion than cafe.québec and café.québec. If anything the latter should be safer simply because people using .québec are more likely to pay attention to accents. Likewise, sakki.fi, säkki.fi and šakki.fi (all extant domains with different registrants) are unlikely to confuse Finnish speakers, and others are less likely to use .fi domains. I guess we could require applicants to document their policy in this regard, perhaps including that they must alert registrants to the issue, but I would not insist on strict same entity principle on 2nd level. I remain, however, open to persuasion. :-) -- Tapani Tarvainen _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org
Thank you for your thoughts, Tapani and Claude. They help me shape my own view on the matter. I have also been thinking a lot about this subject since Mumbai. I have come to frame the question as follows: "should same-entity treatment at the second level be our default policy in order to improve user safety, despite the additional operational burden it creates?" I am leaning toward the view that our case is somewhat different from ordinary second-level diacritic handling. If at the top level these TLDs are being treated as a coordinated set, there is a real policy argument that the related second-level space should also be coordinated enough to preserve predictability. I've come to think that the strongest argument for a same-entity approach comes from a market perspective, in that this would actually promote a less predatory model, since we would not be pushing registrants into buying defensive bundles of domain names. The strings would depend on each other as a matter of policy, not of whether you registered the N permutations of Latin Diacritics contained there. If you own "café.sãopaulo", the corresponding "cafe.sãopaulo/saopaulo" forms should not simply be available for a different party to register because you did not defensively buy every version. The registrant should pay for what they actually want to use, without creating a separate market for defensive registrations. It's sustainable market formation via policy. That said, the operational burden is real. Same-entity at both levels would affect registry systems, registrar behavior, availability checks, lifecycle operations, transfers, dispute outcomes, and possibly existing registrations. It's way messier than the alternative, and creates all sorts of issues that Tapani highlighted. Does this discourage gTLD applicants from thinking that supporting LDs is a viable business? Or are the applicants so niche anyway that they will understand the limitations? I don't know. As usual, my views shouldn't determine any position. This is just where I have arrived so far. Best, On 26/05/2026 19:46, Claude Menard via Gnso-latin-diacritics wrote:
Dear Tapani,
In Canada both .ca and .quebec are enforcing the same entity principle at the second level. There are some minor difference in the policy between .ca and .quebec, but essentially the result is the same.
Here is the .ca (CIRA) policy :
How does .CA manage IDNs?
In 2012, CIRA introduced support for the full range of French characters in .CA domain names: é, ë, ê, è, â, à, æ, ô, œ, ù, û, ü, ç, î, ï, ÿ. When a .CA is registered, all variations of a domain name with these accented characters (what we call the “administrative bundle”) are reserved for the registrant and cannot be registered by anyone else.
Although these domain names are /reserved /for the registrant, they are not active – that is they do not automatically resolve. The registrant must register them with a registrar that offers this service. Each domain name you wish to use must be registered individually, with the same registrar. Each of these registered names will have its own lifecycle.
To use an example, there are 18 variants in the administrative bundle for /www.cira.ca <http://www.cira.ca>/:
* www.cira.ca <http://www.cira.ca> * cirâ.ca * cirà.ca * cîra.ca * cîrà.ca * cïra.ca * cïrâ.ca * cïrà.ca * çira.ca
* çirâ.ca * çîra.ca * çîrâ.ca * çîrà.ca * çïra.ca * çïrâ.ca * çïrà.ca * çirà.ca
For .QUEBEC, when a registrant seeks a second level domain name with a diacritic (IDN), he will get it's ASCII fallback second level domain name at the same time. And over and above a same .CA bundle policy gets in place, enforcing the same entity policy.
I cannot speak for .ca or CIRA, but for .QUEBEC, when the .QUÉBEC will be delegated, the same entity bundgling policy will be extended at the second level for all, including for the already delegated .quebec. with or without diacritic.
This is very conservative, one could say, but it gives a security space for the Brand, the registrants and the users.
This was done, at the Registry level, and the Registry Operator level.
We understand that the registries want to keep an upper hand of what policy should be put in place in their own turf at the second level. We respect that, and we did not propose that the way it is manage here in Canada is a ones fits all. I remember during the IDN PDP 2, that this was discussed for variants and the decision regarding the restriction at the second level was left to the registry, and not a policy in the PDP.
I hopes it helps to understand that café.quebec, cafe.quebec, café.québec, cafe.quebec and all the others câfé, cäfé, càfé, cafe, cafê, cafè, cafë, càfë, etc etc would be all be part of one bundle, one registrant, one registrar, one Registry operator, : or the same entity So no confusion here. Similarity yes but for the same entity.
Best
Claude
Le 22 mai 2026 à 2 h 32, Tapani Tarvainen via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> a écrit :
Thinking of the test.domain vs tést.domain scenario, I find myself concluding that enforcing the same entity principle on 2nd level domains is not viable.
Confusion potential is real, but as it already exists for extant TLDs, ASCII as well as IDN ones, and we cannot do anything about those, can or should we enforce stricter rules for our case?
Same entity requirement on 2nd level could also have some undesirable side-effects. What would happen if cafe.quebec and café.quebec were already extant with different registrants when .québec is applied for?
Should that block .québec application? Or should the policy have some kind of grandfather clause?
I don't see why café.quebec and cafe.quebec would be less likely to cause confusion than cafe.québec and café.québec. If anything the latter should be safer simply because people using .québec are more likely to pay attention to accents.
Likewise, sakki.fi, säkki.fi and šakki.fi (all extant domains with different registrants) are unlikely to confuse Finnish speakers, and others are less likely to use .fi domains.
I guess we could require applicants to document their policy in this regard, perhaps including that they must alert registrants to the issue, but I would not insist on strict same entity principle on 2nd level.
I remain, however, open to persuasion. :-)
-- Tapani Tarvainen _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org
_______________________________________________ Gnso-latin-diacritics mailing list --gnso-latin-diacritics@icann.org To unsubscribe send an email tognso-latin-diacritics-leave@icann.org -- Mark W. Datysgeld Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] Project Lead Developer at ICANNWiki [icannwiki.org <https://icannwiki.org/>]
[Picking selected points and replying inline below.] On Wed, May 27, 2026 at 08:02:46AM +0200, Amadeu Abril i Abril (CORE) (amadeu.abril@corenic.org) wrote:
1. No, it is not true that levaing this to the discretion of the Registry makes any sense.
I certaily agree that a registry should not be able to change rules at whim whenever they choose. I don't see as big a problem in allowing different rules for different TLDs, however, as long as the rules are fixed for each. We could require that 2nd level same entity principle or lack thereof is documented in the registry agreement, and perhaps ask for a special justification if some applicant doesn't want it.
2. The operational difficulties are, to a good extent, a red herring.
Perhaps. Or at least they're not insuperable. As noted some domains force the same entity principle on the 2nd domain already, while some don't.
3. Indeed existing TLDs such as .quebec should granfather the existing registrations into new TLDs in the bundle.
How about the case of extant 2nd level domains with different registrants? Like, if cafe.example and café.example already belong to different registrants when .éxample is applied for?
5. Saying the .com behaves differently is irrelevant, and not a completely valid situation.
Perhaps .com is not a good example, I don't think anyone would apply for .cöm or .cóm or get them if they did, but there are other TLDs that allow IDNs on 2nd level without enforcing same entity principle and some of them might realistically want a diacritic version, too. While not decisive, that certainly has some value as a precedent when we consider how much confusion could arise in each case. Incidentally, does anyone know which TLDs allow diacritics on 2nd level and how many enforce the same entity principle there?
More relevant, much more releavant, is that our mandate, our ONLY mandate is to allow these TLD bundles if, and only if, we can mitigate, ir not fuly eliminate. user confusion.
Eliminating it would be impossible. Mitigation is certainly necessary, but where exactly the line should be drawn isn't obvious.
Last point: we are here with the goal to allow ASCI/Latin Diacritic bundles IF AND ONLY IF we are able to reduce user confusion to a marginal, or at least acceptable level.
Yes. But exactly what level is acceptable? Missatge enviat per Mark W. Datysgeld via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> el dia 27 maig 2026 a les 2:29:
I've come to think that the strongest argument for a same-entity approach comes from a market perspective, in that this would actually promote a less predatory model, since we would not be pushing registrants into buying defensive bundles of domain names.
True. But that already happens with ASCII TLDs. But despite or indeed because of it, I am sympathetic to this argument. Obviously enlarging the space of available TLDs would make the problem worse, so there's a case to be made that we should try to mitigate it in the special case we're dealing with, even if it would appear inconsistent with precedent. After all neither precedents nor consistency are overriding considerations, even though they do carry significant weight. "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson -- Tapani Tarvainen
Hi all, thanks for all the comments and discussions. I would like to clarify one important point to avoid confusion during the discussions: We are not talking about whether we need the same entity principle at the second level. That is a given. Without that, the whole PDP becomes moot. All Recs in some way or another rely on this requirement. For example, if we don't require the same entity at the second level, there is also no need at the top level and there's no need for bundling the TLDs in the first place. User confusion for the TLD only materialises in SLDs. You won't see a stand-alone TLD in the wild, neither in web domains nor in e-mail addresses. All domains in use are at least SLDs (or deeper levels). So, what we are discussing right now is the definition of the ASCII/Latin Diacritic Domain Set (as defined in Rec 39). The question is, what should be included in that set and what not. And in particular the question whether diacritics need to be included or not. Whatever will be included in the end, will have the same entity requirement (Rec 40). Talk to you later today. 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
Hi Michael, all, I guess I misunderstood the point of the tést.domain example. Anyway, while I don't quite follow your reasoning below, I'm content to leave the 2nd level same entity principle in place. Tapani On Wed, May 27, 2026 at 09:37:07AM +0200, Michael Bauland via Gnso-latin-diacritics (gnso-latin-diacritics@icann.org) wrote:
Hi all,
thanks for all the comments and discussions.
I would like to clarify one important point to avoid confusion during the discussions:
We are not talking about whether we need the same entity principle at the second level. That is a given. Without that, the whole PDP becomes moot. All Recs in some way or another rely on this requirement. For example, if we don't require the same entity at the second level, there is also no need at the top level and there's no need for bundling the TLDs in the first place. User confusion for the TLD only materialises in SLDs. You won't see a stand-alone TLD in the wild, neither in web domains nor in e-mail addresses. All domains in use are at least SLDs (or deeper levels).
So, what we are discussing right now is the definition of the ASCII/Latin Diacritic Domain Set (as defined in Rec 39). The question is, what should be included in that set and what not. And in particular the question whether diacritics need to be included or not. Whatever will be included in the end, will have the same entity requirement (Rec 40).
Talk to you later today.
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 _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org
-- Tapani Tarvainen
Dear all, I'm not going to object hard to the 2nd level same entity principle, but I wanted to give an example where it might not be ideal. There are languages where some words have the same meaning with or without diacritics while others do not. In Finnish "sekki" and "šekki" are the same word, just two different pronunciations of it, both considered acceptable today. On the other hand "sakki", "šakki" and "säkki" are three completely distinct words with very different meanings, and sakki.fi, šakki.fi and säkki.fi actually belong to different registrants. There are also lots of cases where some name's correct spelling has diacritics but where omitting them doesn't cause confusion and has been common just because they've not been available in domain names, just like in Québec and .quebec. For example, my home town is Jyväskylä. Omitting the diacritics results in something unpronounceable which means nothing but everybody knows it should be Jyväskylä, and both jyvaskyla.fi and jyväskylä.fi work (and lead to the same place). If the town were to get .jyvaskyla and .jyväskylä, it would make sense to allow sakki.jyvaskyla, šakki.jyvaskyla and säkki.jyvaskyla to belong to different registrants, while insisting that šakki.jyvaskyla and šakki.jyväskylä belong to the same registrant, ditto with säkki and sakki. I concede that this is a rather marginal case, but I would like to have at least some kind of exception process to make it possible. -- Tapani Tarvainen
Dear all, I take Tapani's points. Both that these are edge cases (although probably not exclusive to Finnish) and the desirability of finding a way to address them. It seems that we could provide an exception process. One requiring that the applicant show that the specific case (necessarily words, not acronyms) involves distinct words in a specific language. That way, we maintain the same entity principle in general, while acknowledging that there may be cases where specific considerations make it undesirable. Bill Jouris Yahoo Mail: Search, Organize, Conquer On Wed, May 27, 2026 at 9:11 AM, Tapani Tarvainen via Gnso-latin-diacritics<gnso-latin-diacritics@icann.org> wrote: Dear all, I'm not going to object hard to the 2nd level same entity principle, but I wanted to give an example where it might not be ideal. There are languages where some words have the same meaning with or without diacritics while others do not. In Finnish "sekki" and "šekki" are the same word, just two different pronunciations of it, both considered acceptable today. On the other hand "sakki", "šakki" and "säkki" are three completely distinct words with very different meanings, and sakki.fi, šakki.fi and säkki.fi actually belong to different registrants. There are also lots of cases where some name's correct spelling has diacritics but where omitting them doesn't cause confusion and has been common just because they've not been available in domain names, just like in Québec and .quebec. For example, my home town is Jyväskylä. Omitting the diacritics results in something unpronounceable which means nothing but everybody knows it should be Jyväskylä, and both jyvaskyla.fi and jyväskylä.fi work (and lead to the same place). If the town were to get .jyvaskyla and .jyväskylä, it would make sense to allow sakki.jyvaskyla, šakki.jyvaskyla and säkki.jyvaskyla to belong to different registrants, while insisting that šakki.jyvaskyla and šakki.jyväskylä belong to the same registrant, ditto with säkki and sakki. I concede that this is a rather marginal case, but I would like to have at least some kind of exception process to make it possible. -- Tapani Tarvainen _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org
Hi Tapani. Well, I see what you mean, but I really don’t get the point here. Or rahter, I disagree with your solution even in tht concrete case. Sure, in most, if not all, languages diacritics have the functin to affect pronoounciation, meaning or jsut, sometimes, to distinguish 2 or more otherwise idential words with tidfferent meaning. In my language, Catalan, “net” means “clean” and “nét” means “granchild”. And I could provide some hundreds of other eamples, as most people in this lsit. But this does not mean that .net and .nñet could or should coexist as TLDs. Because one thing is grammatical and orthographical rules, another one, linguistic knoledge and a third one perceptions of ngneral user confusion for those things. OK, you might argue that Toop level and second-level are not exactly the same. I would partially agree and partially disagree. And you can provide as many examples as the .fi ones: yes, in many tLDs, certainly (IMHO: thankfully, but that’s me) not all, second level registrations of ascii and ascii + diacritics are allowed. And wait, even of variants, in certain cctLDs. But this does not invalidate the purpsoe of our WG which is rather limited. Taking your suggested examples, and hoping I got the spelling for some of them correct: The point we are discussing is not whehter sakki.tld and säkki.tld may coexist with different Registrants. Our point is specifcally if, say, an applicant for BOTH .sakki and .säkki could then allow sakki.sakki and säkki.sakki to be registred by different Regitrants, and pleas. add the 2 options I have ommitted to make my point here complete. We cannot simply provide a grammar as the Registration rules. We cannot not say that the policy will depend on the meaning in. a given language, or the prononciation, of a given word. We need to address the issue from the DNS perspective and deal with characters, with codepoints NOT words, not meaning, not prononciation. And above all, we need to bear in mind that the goal is to avoid user, general user, confusion. Not to have some marginal cases addressed at all cost. But even with a possible exception process, how could any such Registry make a sound, general policy, defining in which cases such concurrent uses could be allowed and in whcih should not? Would it be acceptable to jsut say “1. I will apply different, contradictory rules for same labels and codepoints at the top and second level and 2. I will make a decision at the second level for each individual domain”? OK, let’s not rule this out, but let’s not make this the rule, please. As I’ve said, the same way a TLD may change from Brand to ordinary, or from Exclusiive-USe to Brand, or from Community to anything else, at least in principle, even if some of these changes would be easy and some near-impossible depending on what the TLD has been doing in the past, we can, and should, accept that a Registry could ask for such a special deal in their IDn tables and Registry services in Exhibit A of the Agreement…. but I strongly oppose that this is sent as a registry choice directly to the String evaluation Panel during String Evaluation. Best regards. A
Missatge enviat per Tapani Tarvainen via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> el dia 27 maig 2026 a les 18:11:
Dear all,
I'm not going to object hard to the 2nd level same entity principle, but I wanted to give an example where it might not be ideal.
There are languages where some words have the same meaning with or without diacritics while others do not.
In Finnish "sekki" and "šekki" are the same word, just two different pronunciations of it, both considered acceptable today. On the other hand "sakki", "šakki" and "säkki" are three completely distinct words with very different meanings, and sakki.fi, šakki.fi and säkki.fi actually belong to different registrants.
There are also lots of cases where some name's correct spelling has diacritics but where omitting them doesn't cause confusion and has been common just because they've not been available in domain names, just like in Québec and .quebec.
For example, my home town is Jyväskylä. Omitting the diacritics results in something unpronounceable which means nothing but everybody knows it should be Jyväskylä, and both jyvaskyla.fi and jyväskylä.fi work (and lead to the same place).
If the town were to get .jyvaskyla and .jyväskylä, it would make sense to allow sakki.jyvaskyla, šakki.jyvaskyla and säkki.jyvaskyla to belong to different registrants, while insisting that šakki.jyvaskyla and šakki.jyväskylä belong to the same registrant, ditto with säkki and sakki.
I concede that this is a rather marginal case, but I would like to have at least some kind of exception process to make it possible.
-- Tapani Tarvainen _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org
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
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
participants (7)
-
Amadeu Abril i Abril (CORE) -
Bill Jouris -
Claude Menard -
Mark W. Datysgeld -
Michael Bauland -
Tapani Tarvainen -
Tarvainen Tapani