[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Character Variant Deployment at VeriSign
Just one correct: I am not the co-chair of the IDN WG anymore. The group
has already disband.
Otherwise then this clarification, I dont see a need to discuss
non-technical issues with you nor interested to do so.
JFC (Jefsey) Morfin wrote:
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 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
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,
Such a matrix would certainly help a better understanding of both
propositions by many. And may be help (ab++) alternatives to be thought
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.