Re: Character Variant Deployment at VeriSign

["JFC (Jefsey) Morfin" <jefsey@xxxxxxxxxx>]

Dear James
as the co-Chair of the IETF WG-IDN your inputs are of high value.
You said

<quote>
As engineers, we love to find a working solution to a problem which broad 
and all encompassing but I was told some mathematician have prove that such 
solution don't exist for any system involving human
</quote>

This is something I fully agree with. But, by essence internationalizing 
(instead of vernacularizing) has made the problem broad and all 
encompassing. So there can only be two solutions: dropping the solution or 
changing the problem. Otherwise everyone will have his own compromise and 
this will be a cacophony.

The approach you advise is documented in the JET draft. You comment that 
approach as follows:

<quote>
If we were to divide the IDN space into two sides:
(a) resolution involving end-users, IDNA-clients, apps developers, etc.
(b) IDN registration & administration involving registrants, Registries, 
Registrars, NICs etc.
The goal for the JET document is really for (b), not (a).
</quote>

I fully accept that your efforts are registrars meant and that it makes 
sense: one cannot have a service delivered if the operators are not 
organized first.

Yet in real world registrars are services to users and live from the users' 
money. So the real decision makers are the users. The users are represented 
by language organizations like us, by their lawyers as we see a growing 
number of competent ones being  interested, and by international 
organizations like WIPO we know for a long and WTO we have to learn about.

You do not avoid that aspect and address this key aspect in saying:

<quote>
This is not to say that the we totally ignore the end-users. If the 
deployment of registration policy helps the end-users, that would be nice 
but our priority is on (b).
That is why there is a focus on reducing dispute and less on "reducing 
confusing to end-users". We understand that such method is incomplete and 
we clearly stated that "the issues for CJK variants are complex and the 
guideline only forms part of the solutions".
</quote>

This is very correct of you to tell that. And you always warned others not 
to directly copy a document built for the CJK language. This underlines 
that you are not addressing a "broad and all encompassing" subject. After 
having underlined that it does not even address an all encompassing local 
problem, you say:

<quote>
On a more personal note, I would advise that you dont go near the slippery 
slope of "reducing confusion for all end-users". This would more likely 
going to re-open the questions of how variants (particularly TC-SC) in in 
IDNA/Nameprep.
</quote>

And this is certainly the core of the problem you face for 4 years. And 
that you/we will not escape.

Why?

Because the problem is "broad and all encompassing" as specified by ICANN.
Because any solution unilaterally devised in the interest of a few will not 
fly and will cost a lot in disputes and in redesign.

You have not - neither at the WG-IDN nor now writing JET - started in 
listing the concerns, needs, demands of ccTLDs, language organizations 
(there is a ccTLD WG for that), WIPO, WTO. You even think that the 
fundamental economical aspect is not in the scope. You had well identified 
that need in writing the WG-IDN charter: you met the same problem. Any 
market study would probably show that the demand, the needs are opposed to 
the specifications of ICANN.

Is there a way out? I see an alternative:
- the "probably" is wrong and there is actually a way not to oppose ICANN 
and users' demand.
- a contingency solution must be devised that ICANN might accept - or any 
other International network
Community consensus.

The first possibility makes it premature to build on the variants concept. 
It should be used as a basis for discussions, after having been documented 
by tons of examples of what it does address and what it does not address, 
which constraints it implies, how they can be described, and lists of 
precise cases of permitted/not permitted registrations and user confusions. 
If - from that discussions - there will be a consensual acceptance under 
conditions, it will _then_ be to "engineers" to see how to match these real 
world's conditions.

The contingency must be worked the same. For two reasons. One) to provide 
the international internet community with a solution in any case. Two) to 
use it in presenting the current proposition and prevent people from saying 
"one could devise a better solution".

You all know the contingency plan I propose (you criticized it enough :-). 
We all know what objections there can be to it. I do not think we are to 
dispute each other on them. We are here to find a solution to the users. To 
look into what is good in each approach the other could benefit from. So 
they do not oppose but possibly converge. I do not think your solution 
address some real problems of your (a) side and I am ready to accept that 
my solution does not address all the problems of the (b) side.

IMHO we should try first to formalize a global modelization of our (a) and 
(b) propositions and closely try to see how to get an (ab) response to the 
real needs of the Users, Developers, Registries, Registrars, Govs, WIPO/WTC...

Such a matrix would certainly help a better understanding of both 
propositions by many. And may be help (ab++) alternatives to be thought off?

jfc

PS. I copy internally this mail to my own Eurolinc WG Group. With your 
permission I would like to copy it to the ccTLD WG-IDN.