Mapping and Variants

[JFC Morfin]

At 12:11 07/03/2009, Vint Cerf wrote:
>some exotic appeal for some cases that aren't intentionally "bad".

Exotic to who? Everyone is the exot of others (Segalen).

The real problem we face is that internationalization is a _system_ 
which is not shaped to relate with its _exotem_ (what is external, 
exotic to it, and usually discontinuous).

This problem is two folded:
- the desired relation from the system to its exotem
- the permitted relation from its exotem into the system.

The first thing is for the system to start identifying and accepting 
its exotem.
The easiest is to start considering the system as the exotem of 
another system.
This is why I insist on French because there are long structural, 
semantic, technical, political ties and interests between English and 
French. And we can help in explaining how ourselves we perceive the 
English/ASCII names.

For us, IDNA is currently a non multilinguistic English/ASCII 
internationalization tool.
If you want to make it somewhat multilingual (i.e. to reciprocate to 
other language) let start with French.
The target of the protocol is not to solve randomly a few cases, but 
to provide a common basis allowing each language to build its own 
adequate solutions. Including English.

>I hope that makes sense.

Yes. In a closed world/system.

Expressed in network terms, the Internet is the logical network of 
the physical networks.
Here were are engaged in what I call "externets": external network 
lookalikes within the network of networks.

These externets (you can visualise them as "open closed gardens") 
should be supported by the missing presentation layer.

This is in that sense that IDNA is a layer violation. There is NO way 
to resolve it while staying at a single layer.

One must go deeper. This means analysing the layers which exist wihin 
the domain names. i.e. accepting that we talk at least of of two 
different things:
- the domain names as being used by the DNS
- the usage names as being used by the users.

In English/ASCII as well. _Every_ Domain Names is punycoded, even if 
punycode leaves ASCII unchanged.

This means that usage names are case sensitive or not does not impact 
domain names which are not case sensitive (even though the current 
practice in English ASCII may be confusing).

Now, in terms of security: in the English/ASCII system an 
all-lower-case approach may be better for security, I do not know, up 
to English language authorities to decide. In some parts of its 
exotem however, this is not the case.

The first security problems for users there are :
* the _change_ of their security reflexes between their usual 
syntaxis and the internet one they also may be uncertain about..
* the lack of trust when using a system which does not look secure, 
professionnal, achieved, since it is not able to follow their common rules.
* when they accept that there are some underlaying technical 
constraints they become suspicious because obviously these 
constraints are imposed everywhere so other languages are probably 
not supported any better.

jfc