[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Character Variant Deployment at VeriSign

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

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

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:

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).

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:

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".

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:

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.

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


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?


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.