Re: governance vs intergovernance

Dear John,
I am afraid your answer is out of the scope of my question.
My question does not relate in any way to the specificity of the
case, nor to the management of the case by ICANN, nor why
the WG-IDN took that options and why. It is related to the
very existance of the case and of its technical reasons.

This is IETF. So the point is technical. The way the ideas are
expressed are of no interest. What is of interest is the technical
roots of each of the protests. To which extent these technical
objections only relate to RHS or may also concern the LHS. And
what could we do to avoid the related problem in specifying an
LHS solution.

I personnaly (but I may be wrong) read most of them as objecting
to the IETF/ICANN adopted technical strategy. You describe that
strategy as follows:

At 16:51 07/06/04, John C Klensin wrote:
>IETF, made a quite explicit decision to specify mappings and
>codings but to become as little involved as possible with the
>specification of usage, which characters and character
>combinations should actually be used, etc.  The IESG reinforced
>the nature of this decision by issuing a "statement" along with
>the standards that might be described as "this is what we have
>done, but you don't have a complete picture until you do some
>other things, and you should be careful about them".
>
>Following that extremely broad guideline, ICANN adopted a
>guideline/ recommendation that strongly suggested that IDN
>registrations occur only "by language".  This was consistent
>with extended discussions on the IDN list (while the standards
>were under development) about the advantages of "one label / one
>language" (or "one script") strategies in eliminating a number
>of opportunities for problems, but the IDN WG did not make a
>recommendation on that subject (for or against).  ICANN also
>created, as a convenience, a registry for the tables of
>characters permitted by given DNS registries.

The question is: can the above strategy, together with the
IETF disclaimer below, be copied for LHS for average registrants,
when RHS (ie. ccTLD) leads to situation inflaming international
highly representative organizations?

> >From the standpoint of this list, or any other IETF-related
>list, there is one important message from the above: with one
>very small exception, none of the about involves the IETF in any
>way.  It is up to the registries what characters they support
>and what to call them.  The registry of tables is an ICANN-IANA
>registry, not an IETF-IANA registry.  Even if the IETF were
>involved in it (which it is not, in any way) the registry is a
>"pure" registry, with no decision-making processes: any TLD
>administrator can submit any list of character they want, under
>any name, to be registered.

The rest of your reponse concerns ICANN and is not an
IETF issue. Except that I indicate that IETF/IESG specified
a solution which calls for "bodies able to decide for everyone else
in the world, what characters are or are not in a given script and
for what purpose they may be used." And you add:

>And ICANN isn't nearly that stupid, nor is any other
>rational international organization I know of, governmental,
>treaty, NGO, or completely private.

So, you sound perfectly right when you write:

>And, in my opinion, none of it suggests any reason for an
>IETF-related discussion on this subject,

If "this subject" is any LHS specification which may lead to
a similar comment by a group representing the wide
majority of the Internet users. Please abstain and IETF
publish it is not able to address ML.ML.ML


My personnal technical position is simple. As a user
organization I read a mail asking to review the WG-IDN
proposition. I came and saw the proposed technical options
will lead to the kind of conflict and dead-end documented
today by the MINC. I was the objected the most vocal - but
not by everyone by far. So I tried to help - after all I could
have been wrong.

Now, when this happens, I do not say you should have
objected what you state as obvious today. I just ask "is it
reasonable now that we have the proof that these options
lead to this kind of conflict on the Right side, to keep
them for the Left side"?

And I ask if saying "this is not my cup of tea, because
I have said I am not involved in the decisions you will take
to make work the impossible system I designed" will be
enough to give crediblity and momentum to any LHS
replication of the RHS solution?

>nor does it justify your conclusions below.  One thing it
>certainly does do is to illustrate the fact that people get
>extremely sensitive about their languages and how they
>are used.  But we all know that already, and it was one of
>the things that drove IETF to stay very far away from those
>issues.

Then IETF should have declined to propose a solution.
You cannot stay far away from a standard you propose
or you lose credibility.

Knowing the above, what technical alternative do we have
to help users not to be confronted to that kind of situation?
Here is the point. IETF's role is to publish RFC and
standards to be used, not to be disputed.


IMHO this is feasible, but with a totally different perspective,
and probably in a totaly different working way, associating
concerned cultural organizations to get the necessary
usage and foreign technical culture. In making them share
into the requirement definitions, in the specifications work.
Also in forgeting external politically originated constraints
(ICANN).

I certainly accept that this might change IETF. But what
if the result is an Arabic non compatible root?

I fully share the idea that cultures need self-determination.
All the cultures, not only one.

The role of IETF is to make it technically possible without
hurting the global stability. Not to make this the top IETF
priority is IMO a _technical_ and lethal fault. We had the
opportunity to address the problem at length, we have been
warned by several ITU assemblies and Gov consensuses.
We have been warned by the WSIS resolutions. We did
not listen to them.

Now the problem is with us.
jfc



PS. I apologize for having kept Dongxialoi's question attached
by mistake. Quite confusing. Just used a reply to the list
and did not cut it.