Hi Mark, Claude, Tapani and all.

Instead of trying to complete my ultra-long email on this topic, which has been in the works for over a wek, I will try to make some quick and specific points here:

1. No, it is not true that levaing this to the discretion of the Registry makes any sense. More than that: this would be completely contradictory with a basic legal principle present in all legal systems (all I know, at least). which can be summarized (in Lating, indeed!) as

Venire contra actum propriium non valet.

This is the so-called “doctrine des actes propres” in French, or “estoppel in Common-law countries. It means that a party CANNOT pretend that someting is different from what that same party has previously represented itself in the same process/context. Most notably when such previous representation has created expectatives of sme kind on third parties.

In short, and non legal: there isno such thing to a right to be contradictory. It is not acceptable to apply for a TLD. expxressing that quebec and ´québec or example and exàmple are the same and immediately after, for the same TLD set, claim that quebec and québec or exàmple are not the same at second level. Being the same, being equivalent, being managed under the same-entity principle. Indeed, you may stll claim that from an ortographic pooint of view, in a novel, email or any other text, quebec should be written with an acute accent over the first e, but here we are in different processes/contexts. But a TLD is a TLD, and an application for a Latin Diacrtici bundle is jsut one given process/context.

2. The operational difficulties are, to a good extent, a red herring. Let’s not dig deeper here. Suffice to say that .cat has been doing this since 206, .quebec since its Launch and some other dozens TLDs as well. OK, jsut within one TLD, but this would apply to the bundle the same way. The issue here is that some Registries/rSPs, a very limited number, simply would not accept to do it if this implies keeping the “flll data set” for Registrtion Data. But a) this is not a valid argument and b) no need to discuss a), as we will have very soon an EPP extension that solves this problem. No excuses, really.

3. Indeed existing TLDs such as .quebec should granfather the existing registrations into new TLDs in the bundle. Pls see my point about “venire contra actum proprioum non alet” above.

4. The supposed contradiction with what the IDN PDP has established also lacks any value. Tot start with, the IDN PDP was NOT dealing with Latin Diactic tLD sets. In fct, was not even dealing with Latin script in particular, but with basically variants, and that for ALL scripts. It is in the nature of thngs that a mroe specialized rule complements the general one with, well, more specific rules.

But note that here we would not be overturning the IDN PDP, we would be supplementing it with, s said a specific rule that establishes specific conditions in order to grant an exception to a different rule, the String Similarity Evaluation procedure.

And note that, precisely, estalsighing additional constraints is the very nature of an exception. ID we say “the rule says A, but don’t worry, jsut do B” we ar not granting an exception, we are overturning the rule. An exception has the required structure of “The rule says A, but if you fulfill condtions 1, 2 and 3, then, and only then, you are allowed to do B”. So it is in the nature of the exception that we ask the same-entity principle to apply all the way (allthe way in hand s of the Registry).

5. Saying the .com behaves differently is irrelevant, and not a completely valid situation. To start with, this sounds like saying that a community TLD should not enforce the community-specfici restrictions because .com does not it. Again, check my points above with regard to the prohibition of conradictory behavoour and the nature of an exception Nobody is forced to apply as a community tLD or for a Latin Diacritic bundle. But when this happens, the specfic rules should be applied, and yes, they should make sense.

And here it does make sense. Yes, we will have a corss-TLD contradiction in example.com and exàmple.com not subject to the same-registrant entity, and on the contrary being subject for, say .example/.exàmple. But But wll, .com is the 3-letter code for Comoros and nobody can apply now for .ind, .and or.eth. Precedent is not all in life.

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. If we simly say “we refrain from tking measure in that direction because you know, confusion exists in the world out there” we are failing our mandate. But I submit that the confusion here is not the same, it is cearly bigger. The very same Registry that is telling the Internet users that quebec and quebec is equivalent and tied, says the contrary in the same domain, one dot to the left. We should bear in mind that TLDs are not ued as. such. No dotless domains are allowed, now. The TLDs are only seen in real world use as part of a domain. At very least secondlevel.tld Often even more compex UrLs or URIs. Being contradictory in the SAME DOMASIN is much more impactfull, and confusing, that noting that there may be diffeerent uses/cses across all TLDs. Not only would we failing to reduce confusion, we would in fact be INCREASING it.

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. If we leave it at the same point, we are failing to our goal, and raison d’être. If we increase user confusion, we are being in a totally irresponsilbe way, and this PDP should go nowhere.

OK, that’s all for now. Let’s see how it goes today in the call, and how much more detail we will need to disucss ,-)

Missatge enviat per Mark W. Datysgeld via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> el dia 27 maig 2026 a les 2:29:

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:

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 to gnso-latin-diacritics-leave@icann.org

--
Mark W. Datysgeld
Director at Governance Primer [governanceprimer.com]
Project Lead Developer at ICANNWiki [icannwiki.org]

_______________________________________________
Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org
To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org