Noms de domaines et courriels multilingues :
Problèmes actuels et propositions alternatives

Espace Numérique Méditerranéen

26 Avril 2008, Tunis


Présentation paginée :
Appuyez sur la barre espace pour voir la prochaine page.




PLAN






REMARQUE INTRODUCTIVE

    Le multilinguisme est un des enjeux majeurs de la Gouvernance de l'Internet. D'une manière générale, les problèmes de Gouvernance sur la Toile sont différents d'une ceux d'une gouvernance traditionelle. Cette dernière approche, plus politique que technique consiste à dire :
  • 1) les noms de domaines sont une ressource critique, donc pas d'alternative.
  • 2) aucune alternative n'est pratiquement envisageable, ( et ceci parceque l'évaluation courante de la structure de gouvernance actuelle est incomplète )
  • Il en résulte des conflits classiques dont les éffets sont négatifs.







PUNY pour les Noms de Domaines ?



Pour les noms de domaine internationalisé (IDN), la solution proposée par l'ICANN repose sur l'utlisation d'un Puny Code :
Punycode transforme une chaîne Unicode ( en général UTF-8) en une chaîne ASCII de manière unique et réversible. Les caractères ASCII dans la chaîne Unicode sont inchangés, et les caractères non-ASCII sont représentés par des caractères ASCII.

Par exemple académie-française.org donnerait xn--acadmie-franaise-npb1a.org.
Cette approche ressemble à un patch.









et PUNI de courriel ?


Pour envoyer un courriel à secrétaire@académie-française.org,
le problème se corse, car secrétaire est codé en UTF-8 et académie-française.org en Puny Code.

Un protocole pour essayer de résoudre ce problème n'est toujours pas finalisé par l'ICANN.
Le choix de ce double codage interdit les copier/coller, complique très sérieusement l'écriture des applications informatiques.

Une question vient de suite l'esprit : Serait-il possible de concevoir un système homogène tout UTF-8 ?
Pour répondre, il faut d'abord analyser le système de nommage ( DNS) actuel.








EVALUATION de la STRUCTURE actuelle de GOUVERNANCE

  • L'attention a été presqu'exclusivement concentrée sur le contrôle des racines DNS.
  • ... et reste dans l'obscurité : les outils logiciels pour accéder à ces fameuses racines DNS.
  • L'ensemble des serveurs DNS ( en dehors des treize racines et de leurs sauvegarde ) n'est ni possédé, ni sous contrat avec L'ICANN. Le sous-réseau des serveurs DNS est maintenu d'une manière bénévole par les utilisateurs ( principalement les FAIs, les grosses sociétés, les services d'hergement, quelques registraires, etc... )
  • Pratiquement tous les machines de ce sous-réseau utilisent le logiciel libre ( license FreeBSD ) nommé assez astucieusement BIND ( lier en Anglais ) qui est maintenu par l' Internet Systems Consortium (ISC).
  • BIND s'efforce de respecter strictement les standards IETF standards, cad, avec les Request for Comments (RFCs) ( Demandes de Commentaires ) établie par l' Internet Engineering Task Force (IETF) ( chapeauté par l'ISOC ) mais ce n'est pas encore complètement achevé dans la version 9 actuelle.
  • Il existe d'autres logiciels de DNS ( cf Comparaison ) mais ils suivent, pour la plupart, les caractéristiques de BIND.







EVALUATION de la STRUCTURE actuelle de GOUVERNANCE (II)

Le T-shirt de l' Internet Systems Consortium (ISC) est à la fois drôle et révélateur :







EVALUATION de la STRUCTURE actuelle de GOUVERNANCE (III)



Par conséquent, concernant le nommage dans l'Internet,
il y a deux organes "executifs" :
  1. ICANN, de jure, concernant les racines
  2. ISC, de facto, concernant le logiciel qui permet d'accéder aux bases de données des racines.

Tandis que l'IETF ( Internet Engineering Task Force ) joue le rôle d'un organe "législatif" avec les RFCs.








BIND, as a PUBLIC RESSOURCE


In fact, it is very fortunate that BIND allows to carry different resolving services related to different classes of network.

2.1.3 Resource Records : The data associated with domain names are contained in resource records, or RRs. Records are divided into classes, each of which pertains to a type of network or software. Currently, there are classes for internets (any TCP/IP-based internet), networks based on the Chaosnet protocols, and networks that use Hesiod software. (Chaosnet is an old network of largely historic significance.) The internet class is by far the most popular. (We're not really sure if anyone still uses the Chaosnet class, and use of the Hesiod class is mostly confined to MIT.)

This possibility has been moslty ignored except for the proposal made by John C Klensin for a new class that is not limited to ASCII from its initial definitions. This would have allowed to a cleaner Internationalized Domain Name system, instead of relying on the patch that constitutes Punycode. However, the seamless implementation of such a two class system, where records of a new class are used as remedies to the shortcomings of the class "IN" would have created technical difficulties. These problems should not occur when starting with only one class, conceived from the onset for internationalisation.






Now it is interesting to mention the RFC 2929 

CLASS is a two octet unsigned integer containing one of the RR CLASS
   codes.  See section 3.2.

DNS CLASSes have been little used but constitute another dimension of
   the DNS distributed database.  In particular, there is no necessary
   relationship between the name space or root servers for one CLASS and
   those for another CLASS.  The same name can have completely different
   meanings in different CLASSes although the label types are the same
   and the null label is usable only as root in every CLASS.  However,
   as global networking and DNS have evolved, the IN, or Internet, CLASS
   has dominated DNS use.

   There are two subcategories of DNS CLASSes: normal data containing
   classes and QCLASSes that are only meaningful in queries or updates.

   The current CLASS assignments and considerations for future
   assignments are as follows:

   Decimal Hexadecimal
     0      0x0000 - assignment requires an IETF Standards Action.
     1      0x0001 - Internet (IN).
     2      0x0002 - available for assignment by IETF Consensus as a data CLASS.
     3      0x0003 - Chaos (CH) [Moon 1981].
     4      0x0004 - Hesiod (HS) [Dyer 1987].

     5 - 127    0x0005 - 0x007F - available for assignment by IETF Consensus as data
          CLASSes only.

     128 - 253  0x0080 - 0x00FD - available for assignment by IETF Consensus as
          QCLASSes only.

     254  0x00FE - QCLASS None [RFC 2136].
     255  0x00FF - QCLASS Any [RFC 1035].
     256 - 32767    0x0100 - 0x7FFF - assigned by IETF Consensus.

     32768 - 65280    0x8000 - 0xFEFF - assigned based on Specification Required as defined
	  in [RFC 2434].

     65280 - 65534    0xFF00 - 0xFFFE - Private Use.
     65535  0xFFFF - can only be assigned by an IETF Standards Action.

This leaves the possibility of 216= 65536 - 5 ( taken by the IN, CH, HS, None, Any classes ) = 65531 classes ( among which 255 for private use ) that could be used to carry other DNS services, using BIND.







ICANN cannot, in good faith, object to the use of yet another class, since ICANN recommended in May 2001 this approach :

Moreover, it should be noted that the original design of the DNS provides a facility for future extensions that accommodates the possibility of safely deploying multiple roots on the public Internet for experimental and other purposes. As noted in RFC 1034, the DNS includes a "class" tag on each resource record, which allows resource records of different classes to be distinguished even though they are commingled on the public Internet. For resource records within the standard root-server system, this class tag is set to "IN"; other values have been standardized for particular uses, including 255 possible values designated for "private use" that are particularly suited to experimentation.
As described in a recent proposal within the IETF, this "class" facility allows an alternative DNS namespace to be operated from different root servers in a manner that does not interfere with the stable operation of the existing authoritative root-server system. Those that have deployed alternative roots have not used a different class designation, however, choosing instead to have their resource records masquerade as emanating from the standard root, and creating the potential for disruption of other's operations.

Another view it is that the actual subnetwork of DNS servers ( in fact a P2P network, before the term was coined ) should be able carry several DNS systems, in other words to "degroup" the "lines" of this "commoun carrier" to introduce "competition".






Net4D, networks to empower
the second generation of the Web: the Semantic Web

  • Net4D are another classes of Network, like Hesiod and Chaosnet, ICANN has no jurisdiction on this network, only on the class "IN".
  • There could be other classes in competition with the ICANN IN class and the NET4D classes. Fair and ethical competition is welcome.
  • Net4D classes are not designed to provide similar minimal services as ICANN, it has in mind to provide value added services, in view to empower the Semantic Web.
  • Net4D domain holders should abide by a specific ontology, as a contractual requirement to the effect of :
  • Establishing pollution free zone concerning metadata, and providing pathway for the interoperability of metadata concerning specific activities following the Semantic Web approach.
  • Providing a Open Digital Ressource Identifier system that is clearly needed for future evolution of the Web and to authenticate metadata
  • Providing a Open Digital Ressource Identifier (ODRI) that is P2P friendly, that is facilitating a maximal flow via P2P, therefore allowing sites with little bandwith to exchange vast amount of data.





Empowering the Semantic Web


Net4D are classes of Next Generation Domain Services that are empowering the Semantic Web.
Two main networks/services are for the moment being considered :
  • Web4D: The Network of People
  • Epc4D : The Network of Things

    Web4D: The Network of people. As an example of gTLDs with Web4D : the and Language related semantic extension or Linguistic SWgTLDs or LSWgTLDs. An extension shall be assigned to each language so that sites or sites' versions written in specific languages can be easily found and identified. It would facilate greatly the task of search engines and would foster linguistic diversity. The gist of the breaktrough is the following : Automatic translation would be much improved if automatic tools could work with several human certified translation of the same language. For example, if the same document has been available in English and in French by the authors on the same site, and translated by human users in Russian and Korean on other sites, it would be tremendous advantage for automatic translation tools to have access and make use of all existing versions in different languages of the same document. For example "Société Civile" would not be translated in yet other languages such as Italian as "Civil Company" with the help the english version. Of course, it is required that the translation tools could retrieve and identify the various versions at different locations, therefore the need for the ODRI, as well as standardized metadata. SWgTLDs could be the keys to multilinguism on the Web.

    Other possible SW gTLDs:
    • equitable commerce global market place ( operated by UNCTAD )
    • trademarks ( operated by WIPO )







    • EN PRATIQUE

    Jusqu'à présent seuls les utilitaires d'inspection ( DNS look-up, tels que dig, host ) associé à BIND permettent d'interroger un serveur DNS en spécifiant le champ class. Les navigateurs courants ne le permettent pas.
    Avec dig on peut interroger un serveur DNS en spécifiant le champ class. Par défault la class est IN ( pour internet ).
    Ce qui est important, et ce qui distingue cette proposition des "serveurs racines alternatifs" de réputation ternie, c'est que l'utilisateur n'a pas besoin de spécifier un autre serveur DNS que celui qui lui donné par son FAI. Par contre il faut que :
    1. son navigateur puisse interroger le serveur DNS avec le champ class.
    2. chez le serveur DNS BIND, les fonctionnalités disponibles pour la class IN, soient aussi disponibles pour toutes les autres classes.
    Pour faciliter l'interrogation par le navigateur, et d'autres programmes, il faudra généraliser la définition d'une URL ( et URI ), par exemple http://fr.wikipedia.org avec un champ class, par exemple comme suggestion : http://net4d%fr.wikipedia.open avec la class net4d, et le gTLD open dans cette classe.
    Pour que le navigateur ( tel que Mozilla ) puisse interroger le serveur DNS avec le champ class, la modification à apporter dans le navigateur est relativement mineure. Il faudra que le navigateur inclut dans sa requète au serveur Web le champ class. Ces modifications sont pas plus compliquées que la mise en oeuvre du Puny Code dans le navigateur. Après cette modification, il n'y a pas besoin de plug in ou de client spécifique.
    Du coté serveur Web tel que Apache, les modifications à apporter sont aussi relativement mineures.
    Les fonctionnalités disponibles pour la class IN, devraient être aussi disponibles pour toutes les autres classes, en accord avec les RFCs. Ce n'est pas difficile en principe, mais à notre connaissance, ce n'est pas le cas de la version 9 actuelle de BIND. En pratique, la difficultée va dépendre de la manière dont est écrit le code de BIND 9. L'ISC est en train de prévoir une refonte complète de BIND pour la version 10, avec des modules, ce qui devrait faciliter la tâche.
    Les modifications dans les logiciels libres Mozilla et Apache pourraient être écrites rapidement et surtout admises facilement dans la version officielle de distribution. Pour les logiciels propriétaires, celà dependra du bon vouloir des fournisseurs, cependant vues la domination d'Apache chez les serveurs, et l'importance de Mozilla chez les navigateurs, on peut raisonnablement estimer qu'ils ne pourront rester à la traine.
    Chaque classe dispose de son réseau distinct de serveurs racines.






    GOUVERNANCE

    • Si la situation de quasi-monopole sur le DNS n'existe plus, si une compétition saine est introduite entre différents réseaux, les tensions diminueront. Il devient envisageable de laisser l'ICANN évoluer vers sa destinée propre, suivant un lien gouvernemental préférentiel et historique.
    • Concernant la gouvernance Net4D, il est suggéré de considérer un partenariat transparent, inclusif, multi-acteurs, reconnu dans le contexte du droit international public selon la proposition UNMSP.
    • Le rôle du W3C qui recherche et développe, pour le bien commun, des standards, langages et protocoles ouverts pour la Toile Sémantique devrait être mieux reconnu, et une partie substantielle des revenus devrait lui être allouée pour soutenir ses activités.
    • Les réseaux Net4D devraient être ouverts pour interagir avec d'autres systèmes de nommage ( par ex. Handle.net ).





    CONCLUSIONS


    • DNS 1.0 --> Monopole : ICANN, Web 1.0 HTML, filiation US , Anglophone.

    • DNS 2.0 --> Compétition incluant entres autres, en plus de l'ICANN qui restera l'opérateur historique, d'autres "réseaux" Net4D , Web4D, EPC4D globalement internationaux et multilingues dès le départ.