IDNA2003/2008 transition

Maxime Brottier dr.brottier at
Wed Dec 9 02:16:44 CET 2009


I am new on the workon at debate and IUCG. I am told that the
IDNA2003/2008 transition is actually not fully addressed. So, I also joined
the IDNA list. I do not know if I can help. I am specializing in life as a

I have explained some of the basic of the IDNA problem. Life is an
incremental set of adaptations until it comes to a  conflicting situation.
It then resolves it through a "catastrophe" (cf. René Thom's theory) or/and
in a disruptive way (clean sheet) before it resume a new fractal equilibrium
if it did not found it directly.

- a catastrophic situation arises from a double scale constraints/layer
violation: life must chose which scale is going to be the reference (in here
is it IDNA2003 or IDNA2008) or explodes because it must do two opposed
- transition is when there is a possibility "to scale" (without conflict).

The first remark is that the cinetic of your case makes that the more you
wait the more you have a triple scaling problem:

a) from IDNA2003 namespace with its set of rules, to IDNA2008 with its own
set of rules (this is not a same "Minkowsky" space. There is curb: this is
your problem).
- from a low number or users to a larger number (problem of size, but also
problem of possibilities - the more there are the less a double domain name
will be possible).
- in everything one must consider :
--- the element aspect (domain names in one zone),
--- the networked or system issue (the root: all the TLDs),
--- and the global context (in your case the IRI and inter technology
semantic addressing: all the usages, languages, international constraints).

This is why the first reaction is to advise to rush into the lower duress
option. Not easy, nor nice. But procrastinating will make you face worse.

The best I can do, as you know your job, is to ask you a few questions I
have, and I suppose non-involved persons may have and you will have to

- can you explain me the _real_ problem you face in two lines that I can
understand? A _real_ problem is something simple. This is where there is no
other solution than a catastrophe or a smart "trick".

- also, what I grasped it is that there are two ways to write the same thing
with "eszett" or "ss". So you want to make them one single domain name.
However you are not sure which way which IDNA version will resolve that
domain name. Is that correct?

I had a long explanation I did not fully grasp. However it make simpler
sense to me to understand it that way. If I am wrong it would be good for
you to explain me in a way I understand, because I will probably not be the
only one. My difficulty is to understand what is special? Let say today give me access to host A. Then
http://é<>will give me access to B. And
you want to be sure that both give me access
to C = A = B. But this is not what I want: I want them to give me access to
A, and to B. Then I want it A gives access to C, and B gives access to C.
So, I can have a special welcome notice in each case.

Now, a last point. People flock together.Life is copying others.
- Transition is one leader and many followers.
- Confusion is a group of leaders and lost followers.
- Revolution is a rogue leader and upset followers.

I do not want to interfere with political or strategic issues. But I
understand that:
- Google has set-up a service of reference to be the users' visible leader.
- ICANN wants to start with a group of not-much motivated leaders (IDNccTLD)
and has upset/betrayed its best followers (IDNgTLDs).
- That you have not measured enough the determination and the capacity of my
French friends.

My advice - but again I am just coming from the outer space and I do not
know you yet. My advice then, would be:
1) to differentiate the linguist requirements from your concerns - because
they are the same in case/for everyone and you are no linguists.
2) to seriously consider the needs of users, specially when they have the
capacity to forget about you and create havoc.
3) to only discuss one layer at a time. In this case, you want to discuss
how the IDNA can support what (1) and (2) demand.

I am not a network engineer. But I heard some explanations which make sense
to me. There is a basic flaw in your model: the diversity of possible IDNA
modules. Not only in the network, but also on the same machine; may be even
in the same utilization. This is an additional reason for you to go fast
(before there are too many incompatible modules). Then to stabilize on a
case by case basis. Between Google, Users and ICANN Fast Track (including
motivated test IDNgTLDs). Otherwise IMHO your problem will not be the Greek
and German "s's", but a game over decided by Asia and Users.

I am aware that I may be biased by my initial inputs.
1) I must say that these inputs are cristal clear to me. So, I would not be
alone in being biased. This is something we should consider.
2) thank you for correcting me if you think I can help.

Dr. Brottier
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Idna-update mailing list