[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Character Variant Deployment at VeriSign
as the co-Chair of the IETF WG-IDN your inputs are of high value.
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
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
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
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
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.