notes

TO UNDERSTAND THE IDNs
COMPRENDRE LES IDNs

Bonjour !
Hello!

Vous accédez à mon site en utilisant "Jean-François". Comment est-ce possible ?
You accessed my website by using "Jean-François". How is that possible?

J'ai simplement appliqué les RFC, Firefox a appliqué les RFC.
I just followed the RFCs. Firefox followed the RFCs.

J'ai lancé Firefox et j'ai tenté d'accéder "jean-françois.idn". Firefox m'a répondu qu'il ne savait pas trouver "xn--jean-franois-sdb.idn".
I started Firefox and I attempted to access "jean-françois.idn". Firefox answered that it could not find "xn-jean-franois-dsb.idn".

Cela me disait que le transcodage punycode de "jean-françois" est "xn--jean-franois-sdb". Punycode est la fonction standardisée pour convertir les labels des noms de domaine non-ASCII en ASCII acceptable par le DNS.
Great! This tells me that the punycode transcoding for "jean-françois" is "xn-jean-franois-sdb". Punycode is the standardised function to convert non-ASCII domain name labels into DNS acceptable ASCII labels.

J'ai donc été sur mon serveur serveur web et j'ai créé le sous-serveur "xn--jean-franois-sdb". Mon hébergeur a automatiquement créé le nom de troisième niveau équivalent.
Therefore, I went onto my web server and created the "xn--jean-franois-sdb" sub-server. My hosting service programme automatically created the 3rd level equivalent domain name.

J'ai ensuite créé cette page et je l'ai téléchargée dans mon sous-répertoire "xn--jean-franois-sdb" avec le nom "index.htm".
I subsequently created this page and loaded it into my "xn--jean-franois-sdb" sub-directory with the name "index.htm".

C'est tout.
That's all.

PS.
Pourquoi ai-je utilisé "Jean-François.idn"? J'aurais pu utiliser n'importe quel faux TLD. Il me fallait une réponse d'erreur. Parce que mon ISP qui est malin opère un service de mots clés sans le dire. Si je demande uniquement "Jean-François" il m'envoie sur le Blog d'un quidam Jean-François dont je n'ai rien à faire.

Why did I use "Jean-François.idn"? I could have used any erroneous TLD. I just needed a documented error message. Because my ISP rather intelligent and supports keywords (but do not tell others). When I enter "Jean-François" by itself, they route me to the blog of Jean-François X., which is something...of which I do not care much about.

Au passage, ce service de mots clés est capable de supporter des mots clés en chinois, arabe, russe or hébreux.
BTW, that keyword service is also able to support keywords in Chinese, Arabic, Russian, and Hebrew.


Alors, où est le problème ?
Where is the problem then?

Il y a deux types de problème:
There are three types of problems:

  • punycode
  • IETF
  • ICANN

Voyons cela :
Let us explore these further:

  • Punycode est très bon mais rien n'est parfait. Il y a des cas où il n'assure pas. Il a été développé avant quelques mises à jour. Cependant rien de grave.

    Punycode is very good but nothing is perfect. There are cases where it cannot fully do the job. It was designed before some Unicode updates, however, nothing of much significance
    ..
  • Les RFC sont proposées par des groupes de travail de l'IETF. Le Groupe de Travail qui a proposé l'architecture IDNA a fait ses choix - auxquels je me suis opposé. Vous comprenez que si je suis capable de créer cet IDN de 3ème niveau, tout le monde peut en faire de même pour du "phishing" (faire croire que l'on lit un autre noms de domaine en utilisant l'homographie de différents caractères). La raison architecturale est que les IDNs doivent supporter des noms de domaine de différentes écritures. Mais en fait le système "internationalise" ajoutant à l'ASCII tous les caractères de toutes les écriture. En vrac. Il traite tous les caractères sur le même pied, et non comme appartenant aux jeux de caractères des différentes écritures. On a tenté de corriger cela en créant des tables pour les Registres de TLD. Mais les voyous ne vont pas enregistrer des noms de domaine délictueux!

    RFCs are produced by IETF Working Groups. The WG-IDNA, which proposed the IDNA architecture, made choices - I opposed. You see, if I was able to create this 3rd level IDN, anyone can do the same for phishing. The architectural reason is that IDNs support domain names in different scripts. The system actually "internationalises", bulk extending ASCII, however, to every character from every script. This means that it treats every character equally (and not scripts character sets). They attempted to correct this by creating tables for the TLD Registries. However, robbers are not going to register unlawful names! They work at 3rd level, etc
    ..
  • il est intéressant de noter que l'IETF a décidé que le punytranscodage serait au niveau des applications et non de l'accès réseau. Ainsi votre navigateur peut supporter les IDN et votre agent e-mail non.

    Interestingly, IETF decided that transpunycoding should be at the application level. Therefore, your browser can support IDN while your mail agent may not
    ..
  • l'ICANN a aussi fait un certain nombre de choix.
    ICANN also made different choices.
    ..
    • Le premièr est l'exigence de noms de domaine à deux claviers. Un clavier d'usage local pour le nom de domaine, un clavier ASCII pour le TLD. Le but étant de garder le contrôle sur les TLD et le DNS. Sinon à quoi servirait l'ICANN?

      The first one was to demand "two keyboards" IDNs, with one local language keyboard for the domain name and one ASCII keyboard for the TLD. This was put in place to retain control of TLDs and DNS.
      ..
    • Un autre est "amusant". Ils ont choisi au hasard "xn--" comme préfixe. Dans bien des endroits "xn" signifie "chrétien". En Europe c'est le signe des matériaux dangereux. Aux USA c'est une publicité pour l'assurance leader pour les expatriés et l'internationalisation des entreprises. Bravo ! Mais en plus ils personne n'a accepté d'utiliser "x--n" au lieu de "xn--". Ceci crée les "babelnames". Un babelname est un nom de domaine sans sens particulier que les babelsquatter peuvent déposer en Ethiopien ou en Sanscrit ancien et dont l'ASCII a un sens. Un sens qu'il va imprimer partout où le jeu de caractères correspondant ne sera pas supporté. Exemple: "xn--coca-cola". ("x--ncoca-cola" aurait eu moins d'attrait). Des dommages et intérêts solides contre les TLD Managers ?

      Another one is "funny". They randomly chose "xn--" as a prefix. "xn" in many places means "Christians". In Europe, it is a sign for harmful things. In the USA, it is advertised as a leading expat corporate internationalisation insurance company. Great! However, no one accepted the use of "x--n" instead of "xn--". This creates "babel names". A babel name is a domain name that has no particular meaning; but babelsquatters can TM. Yet, its ASCII has a meaning. It will print everywhere that the corresponding script is unsupported. E.g.: "xn--coca-cola". ("x--ncoca-cola" would have been less appealing). Significant damage law suits against the TLD Managers?
      ..

Cependant la difficulté principale n'est pas là. La difficulté principale est de fournir des TLD linguistiques. Sauf à tout reconstruire la solution est simple : des TLD sont traduits et punycodés.
Oui, mais comment doivent-ils être compris par le DNS ?

However, the main difficulty is not here. The main diifculty is to propose lingual TLD, i.e. one keyboard IDN. Except in the case that one rebuilds everything, the solution is simple: the TLDs underlying concepts are translated and the translation is punycoded.
OK, but how are they to be supported by the DNS?.

Deux solutions possibles :
Two possible solutions:

  • DNAME TLDs.

    Ceci signifie que les TLD linguistiques sont des alias des TLD existant qui restent sous le contrôle des opérateurs actuels (.com, .net, .org, info, .museum, .name sont les plus intéressés). Ceci est supporté par le DNS. Le TLD linguistique est d'abord transcodé en ASCII puis la requête est présentée à nouveau. Ceci réclame des serveurs racine récursifs. Un nombre substantiel ne l'est pas. Pour des raisons de sécurité. C'est donc quelque chose à discute. Quelque chose que l'on ne peut pas tester facilement. Au coeur du DNS.
    Probablement une affaire de plusieurs années.

    This means that the lingual TLDs are the alias of the existing TLDs. This is supported by the DNS. The lingual TLD is first transcoded into the ASCII TLD and the request is asked again. This calls for recursive root servers. A substantial number is not recursive for security reasons. This is something to discuss. Something one cannot easily test. We are at the core of the DNS.
    This process will probably last several years.
    ..
  • Lingual TLDs.

    Ceci signifie un nouveau TLD par langue et par pays. Ceci signifie probablement de 300 à 10.000 TLDs. Il en existe déjà un : ".cat" pour le Catalan. Les revenus vont aux TLD linguistiques qui peuvent être des associations de défense culturelles.

    .This means one new TLD per language and country. This most likely means 300 to 10,000 TLDs. One already exists: ".cat" for Catalàn. Revenues go to linguistic TLDs, which can be cultural defence associations..

Personne ne connaît l'impact sur les opérations, les ventes de noms de domaine, la gestion des TLD Managers, l'évolution du modèle économique et politique des Gestionnaire de Registres Nationaux, etc.

Nobody knows the impact on operations, domain name sales, TLD Managers management, political and economic models, and TLD Manager revenues evolution etc.

Une autre solution. Trés simple ?
Another solution. A very easy one?

Supprimer le système de serveurs racine.
Kill the root server system.

A proposition stupide ? Il convient de se poser la question de l'utilité (et pour qui) du système racine, par rapport à la pratique majoritaire réelle qui est de télécharger une copie de ftp://internic.net/domain/root.zone.gz. Télécharger toutes les semaines un fichier de 18 K modifié moins de 10 rois par mois avec des délais pouvant atteindre 3 mois diminuerait la charge réseau due à la zone primaire de 90%. 97.5 % des appels aux serveurs racine sont, semble-t-il, "illégitimes".

A stupid proposition? Maybe it is time to ask what the real benefit (and for who) of the root system is when compared with the common practice of unloading a copy of ftp://internic.net/domain/root.zone.gz. To unload every week an 18 K file updated less than 10 times per month, often along with a 3 month delay, would decrease the top zone related traffic by 90%. 97.5% of the calls to the root servers' systems is apparently be illegitimate.

Nevertheless, is that a proposition … or a current reality?
Mais est-ce vraiement une proposition ou une réalité actuelle ?
..