JFC, it is always a struggle for me to understand anything you
say. Perhaps it's because I tend not to be familiar with the terms,
documents, organizations, abstractions, and metaphors that you refer to.

Dear Adam.
This is probably true.

However this case shows your problem here is that you want me to
support a position we both disagree with.

For me, the DNS is (in a way) right to left hierarchical. ACE introduces
a left to right cross hierarchy (English/International) which conflicts with
the right-to-left DNS hierarchy.

I know you never understood I call this a violation. I also know that you
have difficulties understanding that punnycode you wrote is not for me
intrinsic to the ACE label system.

So I understand that you have every difficulty in understanding what I
oppose and what I propose. I thank you to detail your opposition
because it helps understanding why you totally misread me. IMHO
we say the same thing, once removed the ACE label errors.

I think others may have the same problem understanding. You might want
to try to speak more plainly and simply, with more concrete explanation
of your main points, and fewer digressions.

My point is simple. But please accept them. Don't jump to point 2 after
disregarding point 1.

1. the IDNA solution is inappropriate and violates the DNS architecture.
2. it also create side effects such as babelsquatting.
3. IDNA real life rules will not be taken by IETF, ICANN, etc. but
by WIPO, WTO, Judges and law makers.
4. IDNA real life implementation decided by TLD Managers will cost
money and changes required by WIPO, WTO, Judges and law makers
will cost them a lot more.

TLD Manager may have three attitudes:

1. to wait and see. This may lead them to complex and uncoordinated
situations. With delays, costs out of their control, and possible Gov
reactions if there is a real deployment.

2. to try to technically patch the problems, as in the variant proposition.
This means relying further on "engineers" to address a complex
human life problem. This may lead to a situation where a NIC will be
unable to write a naming charter a Judge might understand. This will
not please the users, add complexity and confusion to confusion and
complexity. And to endless costs.

3. to try to understand what they eventually want and to do for the best
until they can obtain it. This is what I advocate.

> virtual language zones managed outside of the DNS
>
> The day eventually ICANN understands the reality of the world, you
> will just transfer the registrants from your Arabic and from your
> Persian virtual zones into the DNS zones of your now permitted Arabic
> and Persian TLDs - example: ".cn--fre" for French registered DNs by
> CNNIC.

I don't see the purpose of the virtual French zone. If someone wants
a name under .cn--fre, they're going to have to pay CNNIC; if someone
wants a name under .jp--fre, they're going to have to pay JPNIC.

True. Where did you read that I might suggest otherwise?

There is no reason to require that beaucoup.cn--fre and beaucoup.jp--fre
belong to the same person. We don't need a common virtual French zone
to prevent the reuse of "beaucoup" under distinct French TLDs.

Only you suggest such a thing (we both consider as absurd). Would
this not come from your own scheme (two global zones [DN/IDN]) I
totally oppose but you try to adapt in reading me. Please accept
that I do not think IDNA is any solution. For me it is only an
additional problem to live with. So do not try to adapt your scheme
to mine. Just try to understand my scheme and how I try to adapt
it to yours. Or we will go nowhere.

What I say is:

1. there are today 260 TLDs. Either global, either geographic, or
specialized. As par of the whole Internet each of these TLDs
only support today the English language.

Now we want to them to support the RFC 3066 defined languages.
RFC 3066 specifying 368 3 letters language codes, each TLD is
therefore to support 368 linguistic zones, ie 95.680 TLD-language
zones. (Actually much more since there are SLD.TLD zones).

2. IDNA does not propose domain Managers any tool for that. So
they have to be built outside of the DNS but in full consistence
with the DNS and its management.

Registrations tools and rules must be internationalized.

3. the problems of IDNA come (IMHO) of an ICANN policy which
will adapt to the real world. One therefore must identify and
prepare an expected consistent IDNS evolution to reduce the
transition possible conflicts.

I suppose that registrations in the virtual French zone could be tagged
with an intended TLD, but in that case the virtual French zone is
nothing more than a bunch of pre-registrations for French TLDs (like
.cn--fre and .jp--fre) before those TLDs are actually created.

I do not understand why.
1. The French language DNs are in a French language zone
2. we are talking of existing (yet virtual) zones of existing TLDs.
These registration as normal DN registrations on the DNS.

Or may be your confusion comes from not being familiar with the
related RFCs? I will detail this below.

But I don't see why CNNIC and JPNIC should accept those pre-registrations,
since the registrants have not paid CNNIC or JPNIC.

I don't see either why would anyone would dream such a thing (I am
not even sure I understand it).

I could imagine CNNIC or JPNIC voluntarily contracting out the registry
operations of .cn--fre or .jp--fre to an operator that specializes in
French zones.

That would economically make sense. ccTLDs could also mutually
help each others. Or use students. I am sure that AFNIC would be
glad providing every TLD user FAQs in French. That Spanish speaking
lawyers could propose some screens to the wwTLD alliance. Actually
this could be what ICANN should help organizing.

IMHO this should be discussed and added to the ccTLD BPs.

Those two zones might use the same operator, or competing
operators. Either way, there still wouldn't be any virtual French zone.

If you refer yourself to ICP-1 and RFC 1591 you will see that every
TLD has a TLD Manager who freely decides of his TLD Registry
management and of its zone allocation and management.

I suggest you stop seeing the world in an unilateral way as
"English/punnycode". There are 260 real life TLD Managers
having to eventually support registrations in real life 5000 languages.
Each of them having to decide if he is to support a French, a
Chinese, a Creak, etc. zone in his TLD namespace and to
consider what will be his costs, how can he do it, how can he
support it, what are the risks if he does not do it, or if he does
not do it the same way as others, etc.

I question the introduction of new TLDs of the form .cn--fre and

.jp--fre. If we're going to use the Latin country code, and the TLD is
going to belong to the same entities as .cn and .jp, then we might as
well just let CNNIC and JPNIC create subdomains, like franšais.cn and
franšais.jp (or abbreviated forms if they prefer). On the other hand,
if new TLDs are going to be created, then they might as well be more
friendly to the intended French audience, like .chine and .japon. The
friendly-TLDs approach would be more compelling in the other direction,
when creating new TLDs owned by France to contain Chinese names, because
"fr" might be completely unhelpful to typical Chinese speakers (whereas
"cn" is still intuitive to French speakers).

You are confusing DNS and IDNA. IDNA has not addressed the
ITLD issue but replaced it in part wit the ACE label. When I quote in
here "cn--fre", I only respect RFC 1920, 1591 and 3066 as they are
today. These RFCs say:

1. local community TLDs are using ISO 3166 2 letters code list to
determine geographical areas where registrants are from.
2. languages are identified in using ISO 369 3 letters code list
whenever this is necessary.

An intrinsic French language Chinese ccTLD zone will therefore be:
- either: ".fre.cn" as an SLD
- or "cn-fre" using a sub-TLD scripting similar to sub-scheme.

I use "cn--fre" with a double dash like in "xn--" because IANA took
care to remove all the ccTLD from the "xx--" candidates before
randomly choosing "xn--". This therefore seem to be in line with
every semantic best practice. But this is only notation.

The real life transcoding of "jp--fr" into ".japon" as you propose
(a good proposition) is a matter of transcoding standard. Punnycode
is to be used from SLD on. John Klensin proposed tables for TLDs.
My position is to use whatever the TLD Manager decides which is
not conflicting. Anyway this is up to discussion and should first be
approved by users.

Of course, the introduction of new single-language zones is not the only
possibility. It avoids the difficulties of combining variant tables for
multiple languages, but another approach is to face those difficulties
and solve them.

True. As far as I understand you, I do not support this either.
Neither the variants, neither a universal French zone.

Different registries could choose to take different approaches.

The solutions must scale. Neither variants, not a single
zone per language scale. For 7000 years we have a real life
solution which do scales in every other area. I tend to favor it.

Or a middle approach: Create separate zones for groups of
related languages.

Since you developed punnycode: the solution I propose is that
current legacy is retained in English, that ITLD are punnycode
and further on UTLDs (Universal TLDs) are UTF8. Also that you
modify punnycode to make it babelsquatting proof (embeding
some significationless sign(s)) ?