TABLE DE MATIÈRES

1        Introduction.

2        Demande de noms de domaine multilingues.

3        Histoire du développement des noms de domaine multilingues.

4        Défis technologiques du développement des noms de domaine multilingues.

4.1     Aspects techniques du multilinguisme des noms de domaine.

4.2     Concepts de base du groupe de travail de l'IETF.

4.3     Codes de caractères des noms de domaine multilingues.

4.4     Solutions côté client ou côté serveur

5        Normalisation pour la conformité au système DNS actuel

5.1     Préparation des noms d'hébergement internationaux (Nameprep)

5.2     Codage compatible ASCII (ACE)

5.3     Internationalisation des noms d'hébergement dans les applications (IDNA)

6        Impact sur la structure du système DNS.

7        Racines alternatives.

8        Résolution de nom de domaine multilingue par des racines alternatives.

9        Pseudo-racines.

10      Questions de politique et de coordination soulevées par les noms de domaine multilingues.

11      Considération des noms de domaine multilingues dans divers TLD..

11.1   Types potentiels de noms de domaine multilingues.

11.2   Questions techniques et non techniques.

11.3   Noms de domaine mixtes multilingue-ASCII

11.4   Noms de domaine multilingues.multilingues.

12      Quelles sont les langues qui constituent des noms de domaine multilingues?.

13      Qui est l'autorité de langage pour les noms de domaine multilingues?.

13.1   Matrice d'autorité.

13.2   Modèles pour une matrice d'autorité.

14      Résumé.

14.1   Consortium des noms de domaine en chinois (CDNC)

14.2   Centre d'information réseau Internet de Chine (CNNIC)

14.3   i-DNS.net

14.4   Centre d'information réseau du Japon (JPNIC)/Service du registre du Japon (JPRS)

14.5   Centre d'information réseau de Corée (KRNIC)

14.6   NativeNames.

14.7   Neteka 

14.8   Netpia  

14.9   New.net

14.10  RealNames.

14.11  Services mondiaux de registre VeriSign (VGRS)

14.12  WALID  

1                      Introduction

1            Un nom de domaine sert à identifier une entité au sein de l'Internet dans un format aisément compréhensible par les humains; cela a été un des schémas fondamentaux utilisés dans l'Internet pendant plus de quinze ans. A la base, il affiche un nom de domaine lisible par l'homme tel que "www.itu.int" à la place d'une adresse en langage machine du protocole Internet (IP) (par exemple, 156.106.134.92). Dans sa forme habituelle, seul un ensemble limité de caractères ASCII[1], en l'occurrence des lettres, des chiffres et des traits d'union, peuvent être utilisés dans les noms de domaine. Envisagé à l'origine comme un système d'identifiants facilement mémorisables pour aider des ingénieurs réseau à dialoguer avec les ordinateurs, il n'y avait pas de besoin perçu à l'origine d'étendre l'ensemble des caractères acceptés à des écritures non ASCII.

2            Cependant, la décennie passée a vu l'Internet être largement adopté dans le monde. Fondé sur des principes d'innovation technologique et économique, l'Internet a connu une croissance spectaculaire. Il a fallu 74 ans pour que le réseau téléphonique atteigne 50 millions d'utilisateurs. Il n'a pris que quatre ans au World Wide Web pour en atteindre le même nombre. Aujourd'hui, l'Internet est un réseau mondial de plus de 230 économies connectées et plus de 350 millions d'utilisateurs.

3            Une des conséquences de cette croissance est que le nombre d'utilisateurs et les contenus Internet progressent chaque jour, dans des sociétés et des cultures qui ne sont pas familières avec l'ASCII. Pour répondre à ce phénomène, divers éléments de logiciel Internet acceptent la messagerie électronique et les pages web dans de nombreux langages et écritures. Cependant les noms de domaine, sans doute un des symboles les plus visibles de l'Internet, sont encore en caractères ASCII et constituent une barrière linguistique significative. Bien que les utilisateurs de langages écrits en caractères latins, soit d'origine (par exemple, l'anglais), soit dans une forme transcrite (par exemple, le malais), n'aient pas de problème linguistique avec le système actuel de noms de domaine, ceux dont la langue maternelle est l'arabe, le chinois, le japonais, le coréen, le tamoul, le thaï et autres, qui utilisent des caractères non ASCII, subissent un désavantage considérable. Pour tenter de résoudre ce problème, ainsi que pour fournir à tous un support amélioré multilingue et multiécriture, un processus "d'internationalisation" du système de noms de domaine Internet (DNS: Domain Name System) a été mis en chantier.

4            Depuis 1998, plusieurs solutions techniques de ce problème ont émergé. Plus d'une douzaine de compagnies commerciales, ainsi que quelques administrateurs de domaines de premier niveau constituant de code de pays[2] (ccTLD: country code top-level domain), ont construit un certain nombre de solutions techniques pour les noms de domaine multilingues. Sur le marché économique se livre une compétition intense d'où il n'émerge pas de clairs vainqueurs avec une norme de facto.

5            La demande des consommateurs a été extrêmement forte - particulièrement dans les pays d'Asie. En 2000, différents "bancs d'essais" ont été développés de par le monde pour offrir des noms de domaine multilingues. Cependant, la plus grande partie de ces solutions restent techniquement non compatibles entre elles. Reconnaissant le problème, un groupe de travail sur l'internationalisation des noms de domaine (IDN: Internationalized Domain Names) a été formé au début 2000 au sein du Groupe d'étude sur l'ingénierie Internet (IETF) pour définir une démarche technique et les normes adéquates.

6            Il y a eu aussi la prise de conscience progressive de ce que le multilinguisme du système DNS est loin d'être exclusivement un problème technique - c'est aussi un problème d'administration, de gestion et de politique. En 2001, des organisations comme le Consortium pour les noms Internet multilingues (MINC: Multilingual Internet Names Consortium), le Consortium pour les noms Internet en arabe (AINC: Arabic Internet Names Consortium), le Consortium pour les noms Internet en chinois (CDNC: Chinese Domain Names Consortium), le Forum international pour les technologies de l'information en tamoul (INFITT: International Forum for IT in Tamil), et l'Association japonaise des noms de domaine (JDNA: Japanese Domain Names Association), ainsi qu'un certain nombre d'autres groupes de langages naissants sont apparus pour combler un vide politique.

7            En parallèle, il y a des développements majeurs en cours dans les domaines de l'administration et de la politique à propos des noms de domaine conventionnels fondés sur ASCII. En octobre 1998, l'association Internet pour l'allocation des noms et numéros (ICANN: Internet Corporation for Assigned Names and Numbers), association sans but lucratif, a été déclarée dans l'Etat de Californie, aux Etats-Unis d'Amérique[3]. Le mois suivant, un mémorandum d'accord (MoU: Memorandum of Understanding) a été signé entre le Ministère du Commerce des USA et l'ICANN[4]. Dans le cadre de cet accord, l'ICANN a proposé des mesures pour assurer la concurrence sur le marché de l'enregistrement des noms de domaine, une politique uniforme de résolution des conflits de noms de domaine (UDRP: uniform domain name dispute resolution policy)[5], et quelques nouveaux domaines de premier niveau (TLD).

8            Plus récemment, en mars 2001, l'ICANN a officiellement lancé un certain nombre d'activités en rapport avec les noms de domaine multilingues. Une étude récente dirigée par un groupe de travail interne à l'ICANN[6] a indiqué que le développement rapide de noms de domaines multilingues bénéficiait d'un large soutien.

9            A tout le moins, un grand nombre de défis et d'incertitudes demeurent, sur le point de savoir quand et comment les noms de domaine multilingues seront développés. Au moment de la préparation du présent document d'information (novembre 2001), le groupe de travail IDN de l'IETF n'est pas parvenu au consensus nécessaire pour la normalisation technique des noms de domaine multilingues. Considérant les débats sur ce point, même s'il en ressort une norme de l'IETF, il n'est pas évident qu'elle sera universellement adoptée. Il n'apparaît pas non plus clairement si une nouvelle technique émergente de nommage non fondée sur le système DNS comme celle des mots-clés (Keywords), deviendra la solution préférée. Il y a même la possibilité que viennent au jour des techniques hybrides fusionnant le système DNS et les mots-clés. Le seul résultat est que les utilisateurs ont été laissés en pleine confusion par une multiplicité de techniques, développements de "bancs d'essais" et technologies incompatibles.

10          Finalement, il faudra développer le modèle approprié pour l'allocation, l'administration et la gestion des domaines multilingues, y compris les domaines de premier niveau multilingues. L'ICANN, qui ne s'est que récemment attaché à ce problème, n'a pas indiqué clairement la direction à prendre dans cette affaire. En pratique, les approches nationales ou régionales peuvent différer largement en fonction des exigences des langages locaux. Dans ce cas, la question de savoir quelles sont les autorités qui sont responsables pour ce qui doit être considéré comme national, local ou régional peut être assez sensible. Les groupes linguistiques se sont également multipliés, ajoutant ainsi le besoin d'un niveau de coordination supplémentaire. Tout ceci suggère que l'établissement des noms de domaine multilingues peut déboucher sur de futurs défis sur les aspects technologiques, politiques et de gestion du système DNS.

2                      Demande de noms de domaine multilingues

11          L'Internet ayant son origine aux Etats-Unis, il n'est pas étonnant que sa technologie se soit largement fondée sur la langue anglaise. Même ceux qui n'étaient pas américains et qui ont joué un rôle clé dans le développement de l'Internet avaient généralement une culture technique et l'anglais leur était familier. De plus, les codes ASCII ont longtemps été utilisés au coeur de l'informatique et de l'Internet, particulièrement à leurs débuts, lorsque les ressources en unité centrale et en mémoire étaient limitées. A cause de ces circonstances historiques, même des gens de pays qui n'utilisent pas les caractères ASCII dans leur langage écrit se sont mis à utiliser les caractères ASCII pour accéder à des services sur l'Internet. Comme les utilisateurs de l'Internet des débuts de son développement appartenaient au monde de la recherche et de l'université, l'exclusivité de la langue anglaise ne s'est pas révélée être un obstacle significatif à son expansion.

12          Cependant, plus récemment, l'Internet en croissant a atteint tous les coins du monde, des gens de tous ages et de toutes cultures, et il est utilisé aussi bien pour les affaires que la grande consommation. On estime qu'à l'horizon 2003, deux tiers de tous les utilisateurs de l'Internet ne seront pas de langue anglaise[7]. De surcroît, plus de 90 pour cent de la population mondiale parle une langue maternelle autre que l'anglais[8]. Ceci signifie que, pour un nombre croissant de gens, l'anglais et l'alphabet anglais seront considérés comme des entraves à l'accès à l'Internet. Ces gens trouveront tout à fait contre nature d'utiliser l'Internet en anglais avec l'alphabet anglais.

13          Par conséquent, la demande d'utilisation de l'Internet dans des langages autres que l'anglais est croissante et continuera de croître. Il est important de permettre l'utilisation de l'Internet dans la langue maternelle des gens, dans laquelle chacun est à l'aise, pour étendre les bénéfices de l'Internet à tous les utilisateurs individuels. C'est un pas de plus vers la réduction de la "fracture numérique", expression communément utilisée pour désigner le caractère inégal du progrès dans l'accès aux technologies de l'information et de la communication.

14         Il faut noter que, en dehors du désavantage d'avoir à utiliser un alphabet avec lequel ils ne sont pas familiers, les non anglophones doivent souvent faire face à d'autres questions de nature plus complexe. Par exemple, le nom d'un Japonais "博文" est transcrit "hirofumi" en caractères romains. Sur l'Internet, où on ne peut utiliser que des caractères ASCII, il est "hirofumi", tout comme les autres personnes qui s'appellent "hirofumi" mais dont les noms peuvent utiliser des caractères japonais différents tels que "博史" ou "宏史". En fait, il peut y avoir plus de 100 représentations japonaises différentes qui vont finir par être notées simplement "hirofumi" en ASCII. Par conséquent, dans le monde ASCII, la personne en question est juste un "hirofumi" parmi beaucoup d'autres "hirofumi" japonais, bien que dans les caractères japonais originaux il en aurait été clairement différencié.

15          Ce type de problème peut exister, à un degré moindre, pour les gens qui utilisent les langues d'origine latine - par exemple, dans le cas des gens avec des apostrophes, des accents ou autres signes diacritiques dans leur nom. Les formes exactes de ces noms ne peuvent être représentées comme noms de domaine, car ceux-ci sont restreints aux caractères alphanumériques latins et au trait d'union. En d'autres termes, les vrais noms de ces gens doivent se loger dans un espace où un ensemble de caractères beaucoup plus limité est disponible.

16          Avec le temps, il y a eu une évolution substantielle dans l'utilisation de langues non anglaises dans le contenu de l'Internet. Par exemple, dans le cas de la messagerie électronique, les développements suivants sont intervenus:

·         Etape 1: Expression d'un langage maternel non anglais dans le texte de messages électroniques utilisant une transposition de la langue en question dans l'alphabet anglais (translittération).

·         Etape 2: Utilisation de caractères de la langue maternelle dans le texte des messages électroniques.

·         Etape 3: Utilisation de caractères de la langue maternelle dans l'objet des messages.

Que devrait-être la prochaine étape? Il serait naturel que les gens veuillent que le nom de l'expéditeur et du destinataire du message électronique apparaissent dans leur langue maternelle.

17          Toutes les machines connectées à l'Internet reçoivent une adresse unique dans le protocole Internet (IP), en langage machine, (par exemple, 123.4.5.67 dans le cas de IP Version 4). Une adresse IP peut être rendue plus lisible en utilisant le système de nom de domaine qui fournit une chaîne de caractères simple, facile à mémoriser, appelée nom de domaine, synonyme d'une adresse IP particulière. Avec le nombre de services qui sont apparus sur l'Internet, le besoin s'est fait sentir de ne plus s'adresser qu'aux seules machines. Par exemple, avec la messagerie électronique, nous nous adressons à l'utilisateur de la machine. Avec le World Wide Web, nous visons la localisation de documents. Ainsi, pour faciliter la communication, les objets de l'Internet sont nommés au moyen de ressources de localisation uniformes (URL: Uniform Resource Locator) telles que http://www.itu.int/mdns/ ou d'adresses de messagerie telles que itumail@itu.int.

18          Un nom de domaine est une chaîne de caractères, telle que "www.itu.int" ou "www.wipo.int", se référant dans ce cas aux ordinateurs hôtes de l'Internet. Etant donné que les noms de domaine ont été imaginés comme des chaînes faciles à mémoriser pour les utiliser à la place des adresses IP, il ne fait pas de doute que cette exigence de facilité de mémorisation existera aussi dans les langues maternelles car cela fait partie de la vie de tous les jours. De plus, la demande croîtra pour l'utilisation d'autres expressions significatives telles que les noms de compagnies et les noms de personnes. Cela signifie que les noms de domaine ont dans une certaine mesure évolué de la simple identification à la représentation de l'identité des entités. A présent, les noms de domaine sont considérés comme équivalents des noms de marques, de produits et de services. D'un point de vue technique, il s'agit d'une divergence majeure par rapport à l'objectif d'origine.

19          En plus des noms de domaine, il y a différentes méthodes de dénomination des entités sur l'Internet. Elles comprennent, entre autres, les moteurs de recherche et les annuaires, comme le protocole d'accès par annuaire abrégé (LDAP: Lightweight Directory Access Protocol) et le protocole de résolution des noms communs (CNRP: Common Names Resolution Protocol)[9]. Cependant, seuls les noms de domaine sont devenus aussi largement et communément utilisés, et jouent ainsi le rôle d'outils de dénomination préféré pour l'Internet.

20          Les termes "noms de domaine multilingues" et "noms de domaine internationalisés" sont souvent utilisés l'un pour l'autre, bien que les ingénieurs et opérateurs de l'Internet aient une préférence pour "noms de domaine internationalisés." Ceci peut refléter l'idée qu'ils souhaitent éviter les sémantiques des langages naturels dans les noms de domaine et veulent simplement rendre possible l'utilisation de caractères du monde entier dans l'écriture des noms de domaine. Cependant, ce document utilisera en général le terme "multilingue", sauf lorsque "internationalisé" apparaît comme nom propre.

3                      Histoire du développement des noms de domaine multilingues

21          Un des plus récents efforts de développement de noms de domaine multilingues a eu lieu en Asie à la fin des années 1990. Des noms de domaine multilingues ont été développés à l'Université nationale de Singapour (NUS)[10]. A la suite de ce développement, un groupe de travail sur l'internationalisation du système DNS a été formé au sein du groupe Asie-Pacifique de traitement des réseaux (APNG: Asia Pacific Networking Group)[11] en juillet 1998 pour coordonner l'évolution des noms de domaine multilingues. Un des projets du groupe de travail était le développement d'une mise en oeuvre expérimentale d'un service de noms de domaine multilingues multiécritures international (iDNS)[12]. La première phase de ce projet, mené par le Centre de recherches sur l'Internet de NUS, déclarait que son objectif était "Pourquoi les noms de domaine ne seraient-ils pas aussi internationalisés, maintenant que l'Internet a atteint presque chacun des recoins du monde et de ses différentes langues?". Les organes gouvernementaux, universitaires et industriels de Chine, de Hong Kong, du Japon, de Corée, de Singapour, de Taïwan et de Thaïlande, ainsi que Bioinformatrix Pte. Ltd, et un certain nombre d'organisations s'occupant du langage tamoul, ont participé ensemble au projet. Un autre projet, nommé iDomain[13], avait pour objectif de créer un banc d'essai de service iDNS dans les pays de la zone Asie-Pacifique. Pendant les années 1998/1999, des projets de banc d'essai ont été mis au point dans plusieurs pays de la zone Asie‑Pacifique, procurant la capacité d'accepter, entre autres, le chinois, le japonais, le coréen (Hangeul), le tamoul et le thaï.

22          Plus tard cette année‑là, une démonstration d'un prototype fonctionnel de système DNS multilingue a été faite dans les pays d'Asie, prouvant sa faisabilité technique. En août 1998, à une réunion du Forum international sur le Livre blanc (IFWP)[14] à Singapour, un système de noms de domaine multilingues a été présenté aux délégués des pays participant à la réunion à laquelle on discutait d'une nouvelle Autorité d'allocation des numéros Internet (IANA: Internet Assigned Numbers Authority)[15], y compris ceux de l'InterNIC[16] et du Groupe d'étude pour l'ingénierie de l'Internet (IETF: Internet Engineering Task Force)[17]. A la fin de 1998, plusieurs pays avaient exprimé leur intérêt pour la mise en oeuvre d'un tel système, parmi lesquels la Chine, Hong Kong, le Japon, la République de Corée, Singapour et la Thaïlande. Dans plusieurs conférences internationales en 1999, telles que la Conférence régionale Asie‑Pacifique sur les technologies de fonctionnement (APRICOT)[18], et l'INET 99[19], plusieurs réunions spécialisées (BoF: Birds of a Feather) ont été tenues pour discuter des noms de domaine multilingues.

23          A la suite de ces activités, du côté purement technologique, une réunion sur les noms de domaine multilingues s'est tenue pendant la 46ème réunion de l'IETF en novembre 1999. Son but était de déterminer si l'IETF devrait élaborer des normes techniques sur les noms de domaine multilingues. Des groupes de discussions électroniques ont été lancés immédiatement après cette réunion. Trois mois plus tard, à une réunion ultérieure de l'IETF en janvier 2000, le Groupe de travail nom de domaine internationalisé (IDN: Internationalized Domain Name)[20] a commencé ses travaux. Depuis cette date, il y a eu une discussion intense et active sur la normalisation à l'IETF, principalement au moyen d'une liste de diffusion de messages et de réunions physiques périodiques.

24          Sur le front du développement, à la fin de 1999, plusieurs compagnies (y compris la création d'une branche commerciale de l'initiative Asie‑Pacifique iDNS par l'Université nationale de Singapour, appelée i‑DNS.net International Inc.[21]) ont commencé à commercialiser la technologie qui avait été développée. Plusieurs bancs d'essai de noms de domaine internationalisés sont rapidement apparus, avec l'un d'entre eux fondé sur la technologie i‑DNS.net[22] (voir les § 86-88 ci‑dessous) et un autre proposé par VeriSign Global Registry Services (voir les § 104-108 ci‑dessous).

25          Le Consortium des noms Internet multilingues (MINC)[23] est un partenaire mondial majeur dont les activités ne sont pas limitées au développement. Constitué en juillet 2000, avec 39 membres fondateurs tout autour du globe, MINC a hérité de certaines des activités de l'APNG. Il se concentre sur la promotion du multilinguisme des noms de l'Internet, y compris des noms de domaine et mots‑clés Internet, sur l'internationalisation des normes et protocoles de nommage de l'Internet, sur la coordination technique, et sur la liaison avec les autres organes internationaux. Sa mission est de donner aux peuples du monde entier leurs meilleures chances de réussir dans le monde de l'Internet, dans le commerce électronique, et dans l'âge du savoir électronique de l'avenir[24]. En plus de cela, les organisations qui correspondent à un langage, un pays, ou une région, poursuivent activement le déploiement des noms de domaine multilingues. Parmi eux, on trouve le Consortium des noms Internet en arabe (AINC)[25], le Consortium des noms de domaine en chinois (CDNC)[26], le Forum international pour les TI en tamoul (INFITT) et l'association des noms de domaine en japonais (JDNA)[27].

26          Du côté politique, l'ICANN s'est formellement lancé dans les activités liées aux noms de domaine multilingues en mars 2001. Il considérait que la coordination politique était vitale pour l'introduction de noms de domaine multilingues fondés sur toutes normes techniques. En conséquence, il a constitué un groupe de travail IDN consistant en quatre membres du Conseil de l'ICANN, lors de sa réunion de mars 2001. A la même réunion, le Comité consultatif de gouvernance (GAC: Governmental Advisory Committee)[28], comité consultatif de l'ICANN, a produit un communiqué[29] exprimant son soutien aux noms de domaine multilingues. Le communiqué disait: "En ce qui concerne les noms de domaine internationaux (IDN), le comité GAC confirme l'importance et l'intérêt de son développement pour le bénéfice des utilisateurs de l'Internet dans le monde entier". Le petit groupe de travail de l'ICANN a commencé par une mission de recherche factuelle s'appuyant sur une enquête couvrant trois aspects des noms de domaine multilingues, à savoir: technique, politique et services. Les résultats de cette enquête[30] ont été présentés à la réunion de septembre 2001 de l'ICANN. Dans le rapport, il était indiqué qu'il y avait une forte demande de noms de domaine multilingues. Sur la base de ces résultats, le Conseil de l'ICANN a décidé d'établir un comité rassemblant des experts de spécialités variées. La mission de ce comité serait de donner des recommandations sur des questions de politique non techniques, y compris d'interfonctionnement, la résolution de conflits et/ou occupation illégale de l'espace Internet, les domaines de premier niveau, la protection des consommateurs et la concurrence.

4                      Défis technologiques du développement des noms de domaine multilingues

4.1                 Aspects techniques du multilinguisme des noms de domaine

27          L'espace des noms de domaine du système DNS a une structure hiérarchisée (voir la
Figure 1  ci-dessous) utilisée pour identifier les entités dans l'Internet. Chaque noeud de la structure correspond à une entité dans l'Internet. Un nom donné à un noeud dans la structure s'appelle une étiquette de domaine. Tous les noeuds reçoivent une étiquette à une seule exception près: le noeud racine, comme indiqué au sommet de la Figure 1 , qui n'a pas d'étiquette. Le nom de domaine d'une entité (noeud) est une suite d'étiquettes de noeuds commençant depuis elle-même jusqu'à la racine, où les étiquettes sont séparées par des points. Pour ce qui est de la longueur, une étiquette de domaine ne devrait pas dépasser 63 octets[31] et un nom de domaine complet ne devrait pas avoir plus de 255 octets.

 Figure 1

28          La Figure 2 (ci-dessous) montre comment une entité nommée par un nom de domaine est identifiée sur l'Internet. Chaque noeud de la structure DNS peut être considéré comme un tableau, appelé serveur de nom, qui maintient les paires d'étiquettes de noeud directement au-dessous du noeud et des adresses IP correspondantes. Les serveurs de nom correspondent aux organisations ou unités qui ont autorité pour gérer le nom de domaine correspondant au noeud. Par exemple, le serveur racine est l'autorité source pour les noms .int ou .com; les serveurs de nom pour .int sont l'autorité source pour les noms .itu.int et .wipo.int, et les serveurs de nom pour .itu.int sont l'autorité pour www.itu.int. Le système DNS est donc, au bout du compte, une grande base de données distribuée sur le monde entier du point de vue aussi bien de l'ingénierie que de la gestion.

FIGURE 2

29          Du point de vue de la relation entre l'utilisateur Internet et le système DNS, un nom de domaine est traité comme indiqué à la Figure 3 (ci-dessous). Avec les protocoles actuels qui ne peuvent travailler qu'en ASCII, les utilisateurs seront forcés de se limiter à utiliser les caractères ASCII permis par les étiquettes de domaine. Ceci signifie effectivement que les noms de domaine ASCII seraient utilisés à tous les stades, depuis l'usager jusqu'au site web. Cependant, avec l'introduction des noms de domaine multilingues, le protocole entre l'utilisateur et l'ordinateur individuel serait fondé sur des caractères non ASCII, tandis que le système DNS courant est fondé sur l'ASCII.

Figure 3

30          Les questions techniques clés sont:

·         •     Comment les codes non ASCII devraient-ils être représentés?

·         •     Où les codes non ASCII devraient‑ils être reconnus, dans l'application client ou dans le serveur DNS?

·         •     Quel est le mécanisme technique qui met en correspondance les noms de domaine multilingues et la technologie DNS actuelle?

Les concepts de base du travail de l'IETF sur ce problème sont décrits aux § 31 à 33 ci-dessous. La première question est abordée aux § 34 à 37; la seconde aux § 38 à 42; et la troisième est discutée aux § 43 à 52.

4.2                 Concepts de base du groupe de travail de l'IETF

31          Comme le système DNS est une des technologies fondamentales développées dans l'Internet, la compatibilité et l'interfonctionnement des noms de domaines multilingues revêtent une importance critique. Toute nouvelle technologie devrait occasionner le moins de changements possibles à l'Internet, coexister avec les noms de domaine actuels, et permettre qu'un nom de domaine désigne de façon cohérente et unique la même entité partout sur l'Internet. Ceci sera réalisé par une normalisation appropriée et par la conformité systématique aux normes dans l'Internet. La normalisation implique l'établissement d'un protocole commun promouvant l'interaction entre les différentes entités au sein de l'Internet; dans le cas du système DNS, ceci est pris en charge par l'IETF.

32          En janvier 2000, l'IETF a établi le Groupe de travail IDN pour la normalisation de la technique des noms de domaine multilingues. Son mandat peut être résumé comme suit[32]:

·         Le but du groupe est de spécifier les exigences pour l'internationalisation de l'accès aux noms de domaine et de définir un protocole d'élaboration des normes fondé sur ces exigences.

·         Une exigence fondamentale de ce travail est de ne déranger nulle part l'utilisation et le fonctionnement actuels du système de nom de domaine pour traiter tout nom de domaine.

·         Le groupe n'aura pas à traiter de la question de savoir quel organe, s'il en est, doit gérer ou surveiller l'utilisation des noms qui utilisent cette fonctionnalité.

33          Pour le traitement de la normalisation de la technologie des noms de domaine multilingues, les exigences de base du Conseil de l'architecture Internet (IAB)[33] sont les suivantes:

·         RFC 2825: Préservation de la compatibilité avec les noms de domaine actuels.

·         RFC 2826: Préservation de l'unicité de l'espace des noms de domaine.

·         L'Internet ne doit pas être divisé en isolats.

4.3                 Codes de caractères des noms de domaine multilingues

34          Seules les lettres de l'alphabet latin de base (A-Z sans tenir compte de la casse), les chiffres décimaux (0-9), et le trait d'union sont permis dans les noms de domaine (RFC 1034[34] et RFC 1035[35]). Le multilinguisme des noms de domaine implique l'extension de ce jeu de caractères pour inclure des caractères non ASCII. Pour garantir que les applications reconnaissent et traitent uniformément les noms de domaine multilingues, le codage et les représentations de tels caractères non ASCII doivent être déterminés de façon univoque. Pour ce faire, il est souhaitable de disposer d'un jeu de code accepté mondialement pour les noms de domaine multilingues de telle sorte qu'applications et systèmes se rapportant aux noms de domaine de tout l'Internet puissent interfonctionner techniquement.

35          Cependant, pour des raisons historiques variées, le fait est que les écritures de nombreux langages actuellement utilisés dans les systèmes d'information ont adopté des normes nationales ou privées. Pour donner un exemple, le jeu de caractères japonais le plus répandu sur les appareils japonais se fonde sur les normes industrielles japonaises (JIS) X 0208 et X 0201. Par conséquent, de nombreux ordinateurs individuels, assistants numériques personnels (PDA), ainsi que des téléphones mobiles avec accès à l'Internet du Japon, ne peuvent afficher que des caractères JIS et ASCII. Ceci cause des chevauchements de codage et constitue une entrave à la définition d'un type unique de codage utilisé, provoquant des problèmes de compatibilité.

36          La solution la plus prometteuse est l'adoption de Unicode[36] (ISO/CEI 10646), qui spécifie les jeux de code de nombreuses écritures et donc de langages. Bien que Unicode puisse être la meilleure solution actuelle, il pourrait être nécessaire d'y apporter quelques développements pour l'adapter à l'utilisation réelle. De plus, lorsque des applications n'utilisent pas directement Unicode pour une représentation des caractères locaux, il est nécessaire de procéder à une conversion entre les jeux de code utilisés localement et Unicode, quelque part dans l'environnement informatique (par exemple, JIS, dans le cas du japonais).

37          Il existe aussi la possibilité que la simple adoption d'Unicode ne soit pas appropriée pour les noms de domaine. Par exemple, certains caractères chinois ont deux représentations - un caractère chinois traditionnel et un caractère chinois simplifié. Le fait que la correspondance entre un caractère chinois traditionnel et un caractère simplifié ne soit pas biunivoque rend la situation beaucoup plus compliquée. De plus, bien qu'ils soient habituellement utilisés en Chine continentale à la place des caractères chinois traditionnels, les caractères chinois simplifiés sont rarement utilisés à Taïwan ou Hong Kong. La question de savoir si ces deux jeux de caractères devraient être considérés comme n'en étant qu'un a été soulevée[37]. Certains ont avancé que si les noms de domaine sont de simples identifiants ils devraient être traités comme caractères différents. D'autres estiment qu'ils devraient être considérés comme les mêmes caractères si, en réalité, les noms de domaine correspondent à l'identité des entités. Même si ils sont considérés comme les mêmes caractères, d'autres questions peuvent survenir sur le point de savoir si c'est une question de code local ou bien une question relevant du protocole universel, et si on devrait faire une distinction entre ces caractères lorsqu'ils sont utilisés pour le chinois traditionnel ou le chinois simplifié.

4.4                 Solutions côté client ou côté serveur

38          Pour ce qui concerne la question, posée à la Figure 3, page 12 , du lieu où les codes non ASCII devraient être reconnus, les approches d'une solution de ce problème sont principalement fondées sur l'un des scénarios suivants:

Solution côté client

39          Dans une solution côté client, la traduction entre l'écriture multilingue et la représentation compatible ASCII est réalisée dans les applications d'utilisateur (par exemple un moteur de recherche web). L'application client traduit les écritures multilingues en chaînes ASCII, qui peuvent alors être traitées par l'Internet courant: c'est-à-dire que les noms de domaine sont par la suite traités comme des noms de domaine ASCII dans tout l'Internet. Cette catégorie inclut en réalité le cas d'une application qui consiste en un logiciel existant à la fois du côté client et du côté serveur. Mais pour des raisons de facilité de langage, le terme "côté client" est utilisé pour garder la cohérence avec le rapport sur l'enquête de l'ICANN[38].

40          Techniquement, une solution côté client est nécessaire sans considération de l'approche choisie. Il n'est pas vraisemblable qu'une application en ASCII seul puisse immédiatement travailler avec des noms de domaine multilingues. Certaines améliorations seront nécessaires, pour fournir des polices de caractères, ajouter des méthodes ou fonctions techniques supplémentaires pour servir de support à l'internationalisation.

Solution côté serveur

41          Dans une solution "côté serveur", les noms de domaine sont envoyés dès l'origine sur l'Internet par l'application du client avec un codage local, tel que UTF-8[39], GB ou BIG5[40], ou Unicode. Les applications et services communiquent entre eux en utilisant des noms de domaine non ASCII tout au long des voies de communications qui les relient (parfois désignées par l'expression "sur le fil"). Noter que les premières mises en oeuvre de l'IDN étaient en réalité des solutions de serveur mandataire qui interceptaient le codage local des applications client et le convertissaient en codage compatible ASCII de telle sorte que les serveurs DNS restent inchangés.

42          Certains des services, expériences et bancs d'essais développés actuellement utilisent des solutions côté client et d'autres, des solutions côté serveur. Un débat est en cours parmi les experts techniques sur la faisabilité pratique de l'utilisation de caractères non ASCII natifs dans le système DNS et sur la façon dont cela interagirait avec les autres protocoles de l'Internet. Actuellement, l'IETF progresse vers la normalisation d'une solution purement côté client. Cette démarche s'appuie sur les arguments suivants:

·         Premièrement, le système DNS est une énorme et robuste base de données distribuée, mais qui fonctionne sur la base d'un équilibre instable. Trop de logiciels et protocoles de l'Internet utilisent le système DNS dans sa forme actuelle. Non précédée d'essais très complets, la modification du DNS à un niveau aussi fondamental pourrait conduire à l'effondrement de tout le système. En considérant cela, de nombreux ingénieurs de l'Internet déconseillent de modifier le coeur du système DNS, car cela pourrait avoir des conséquences désastreuses pour l'Internet. Il est avancé qu'une solution client ne requérant pas de modifications significatives du système DNS est plus sûre pour la stabilité et la croissance de l'Internet.

·         En second lieu, en vue d'une croissance rapide de la demande, la faculté d'utiliser les noms de domaine multilingues devrait devenir disponible le plus tôt possible. En général, le développement de serveurs devrait prendre plus de temps que le déploiement des applications client. Dans les solutions côté client, seules les entités désirant communiquer en utilisant les noms de domaine multilingues auront besoin d'être adaptées pour accepter les noms de domaine multilingues. Réciproquement, les solutions côté serveur exigent que tous les composants le long des voies de la communication, y compris le client, le serveur et tout ce qu'il y a entre eux, soient préparés aux noms de domaine multilingues. Le développement d'une solution côté serveur peut demander la reconfiguration de tous les serveurs de tout l'Internet pour qu'ils acceptent les écritures multilingues, ce qui prendrait un temps considérable.

·         Troisièmement, étant donné le délai non négligeable qu'il faudrait pour mener à bien le déploiement côté serveur, cette approche pourrait avoir pour résultat que seules des zones limitées de l'Internet seront capables d'accepter les noms de domaine multilingues. Ceci pourrait conduire à la fragmentation de l'Internet en "isolats" et à l'émergence possible de racines alternatives[41]. Il pourrait en résulter confusion et incohérence pour les utilisateurs. Le GAC a exprimé ses préoccupations sur ce sujet dans son communiqué de mars 2001 sur son soutien aux noms de domaine multilingues, en déclarant "la préservation de l'universalité de la connexion et de l'accès dans le système de nom de domaine est vitale pour la perpétuation de l'Internet comme réseau mondial".

5                      Normalisation pour la conformité au système DNS actuel

43          Théoriquement, dans la normalisation technique, toutes les langues et caractères qui pourraient être utilisés dans les noms de domaine multilingues devraient être pris en compte. Cependant, de nombreuses questions se rapportant à une langue particulière ne sont identifiables que par ceux qui utilisent en pratique ces langues et caractères. La normalisation sera donc évolutive, car toutes les questions impliquées ne seront pas identifiées et résolues en une seule fois.

44          L'IETF travaille actuellement sur la normalisation de la solution côté client, comme décrit ci-dessus. Les éléments techniques qui doivent être normalisés comprennent:

·         La préparation des noms d'hébergement internationalisés (Nameprep).

·         Le codage compatible ASCII (ACE).

·         L'internationalisation des noms d'hébergement dans les applications (IDNA).

45          Dans Nameprep, les représentations de chaînes multilingues multiples, qui devraient être considérées techniquement comme la même chaîne, sont combinées en une seule chaîne. Après Nameprep, ACE convertit la représentation multilingue en un nom de domaine ASCII approprié. Les rôles respectifs de Nameprep et d'ACE sont indiqués à la Figure 4 (ci-dessous). L'architecture du logiciel d'application, permettant de mettre en oeuvre ces deux traductions des noms de domaine multilingues originaux et d'être ainsi adéquatement incorporés à l'Internet courant, s'appelle IDNA.

 Figure 4

5.1                 Préparation des noms d'hébergement internationaux (Nameprep)

46          Les principales fonctions de Nameprep sont:

·         Typographie: dans la mesure où la différence entre majuscules et minuscules n'est pas significative pour la constitution des noms de domaine fondés sur ASCII, les casses sont fusionnées en une forme unique. Ceci doit être fait non seulement pour les lettres ASCII mais aussi pour les lettres non ASCII. D'autres types de fusion de casse peuvent être nécessaires pour des caractères non ASCII. La fusion de casse est aussi appelée "correspondance" parce qu'elle met en correspondance un/des caractères avec un ou d'autres caractères qui sont considérés comme équivalents. Les spécifications de fusion de casse se fondent sur le Rapport technique Unicode N° 21[42].

·         Normalisation: de nombreux caractères ont plusieurs représentations même si l'oeil de l'homme ne peut percevoir la différence. Dans les noms de domaine, ces caractères devraient être normalisés avec une seule représentation afin qu'ils soient considérés comme un seul et même caractère. Par exemple:

o        les ligatures "ä" et "a +¨" sont canoniquement équivalentes;

o        le "A" long et le "A" demi‑long sont équivalents.

Les spécifications normalisées se fondent sur le standard Unicode Annexe N° 15[43].

·         Interdiction: de nombreux caractères du jeu de caractères Unicode sont des séquences de commande, des séquences de format ou des caractères d'espacement, qui sont inappropriés et interdits pour les noms de domaine.

Ce qui figure ci-dessus démontre que Nameprep traduit diverses représentations considérées comme même chaîne originale en une représentation unique dans l'espace de la chaîne multilingue. Si les produits en sortie de Nameprep sont les mêmes, les chaînes d'entrée sont considérées comme le même nom de domaine. Si les produits de sortie sont différents, elles sont considérées comme des noms de domaine différents. Pour satisfaire à cette exigence, Nameprep devrait précéder ACE. L'IETF approche maintenant des étapes finales de la normalisation de Nameprep.

5.2                 Codage compatible ASCII (ACE)

47          ACE code une chaîne non ASCII représentée en Unicode par une chaîne ASCII, conforme au format actuel de nom de domaine ASCII. Ceci permet aux noms de domaine multilingues d'être correctement traités en tant que noms de domaine ASCII correspondants. A la 49ème réunion de l'IETF en novembre 2000, le Groupe de travail IDN a été orienté vers le choix de l'ACE, bien que les arguments faisant valoir la nécessité d'utiliser dès l'origine UTF-8 aient fait l'objet d'un débat dans les discussions par messagerie électronique. L'IETF atteint maintenant les étapes finales de la normalisation de ACE.

48          RACE (Codage compatible ASCII par rangées)[44] était l'un des premiers candidats parmi les algorithmes proposés pour ACE. Il était utilisé pour les services d'enregistrement et de résolution fournis par, entre autres, les Services de tenue de registres mondiaux VeriSign (VGRS)[45] et le Centre d'information réseau du Japon (JPNIC)[46]/Service de tenue de registre du Japon (JPRS)[47]. A la suite de RACE, d'autres algorithmes ont été proposés et évalués quant à leurs avantages et inconvénients par les experts en utilisant les noms de domaine multilingues qui étaient enregistrés dans divers scénarios de banc d'essai.

49          A la réunion d'août 2001 de l'IETF, un système ACE dénommé AMC-ACE-Z[48] a reçu un soutien significatif à cause de l'efficacité de sa compression. Par exemple, AMC-ACE-Z peut représenter au moins 18 caractères japonais pour une étiquette de domaine, alors que RACE peut représenter jusqu'à 17 de ces caractères. A titre d'exemple, les chaînes de sortie en ASCII pour "日本語ドメイン名例.JP" (signifiant exemple de nom de domaine en japonais), produites respectivement par RACE et AMC-ACE-Z[49] sont:

·         RACE:                         BQ--3BS6KZZMRKPDBSJQ4EYKIMHTKQGU7CY

·         AMC-ACE-Z:   ZQ--ECKWD4C7CU47R2WFQW7A0ECL32K

50          Un codage ACE met en correspondance un espace de nom de domaine multilingue avec un sous-espace de noms de domaine ASCII. Dans le sens inverse, il devrait être possible à un nom de domaine ASCII utilisant ACE d'être mis en correspondance univoque avec un nom de domaine multilingue. Par conséquent, un sous-espace devrait être réservé pour les noms de domaine multilingues au sein de l'espace de nom de domaine ASCII existant, comme indiqué à la Figure 5 (ci-dessous). Pour cela, un préfixe, suffixe ou "tag" pour une chaîne ACE résultante doit être définie. Toutes les chaînes ayant un tel préfixe ACE constitueront un sous-espace définissant des noms de domaine multilingues. Le préfixe ACE doit être choisi en tenant compte des conditions suivantes: la possibilité d'une coïncidence de noms de domaine ASCII avec un tel préfixe ou suffixe doit être totalement exclue, et le préfixe ou suffixe doit être suffisamment court pour laisser le maximum d'espace pour les noms de domaine multilingues. Dans ces conditions, le préfixe ou suffixe pourrait être une simple chaîne de caractères, c'est-à-dire, "??--", ou "--??", où? est un caractère alphanumérique. Par exemple, si RACE est choisi, les noms de domaine commençant par le préfixe "bq--" indiqueraient un nom de domaine multilingue.

Figure 5

51          Bien qu'ACE soit prometteur, un certain nombre de questions restent encore à résoudre. Tout d'abord, les noms de domaine ASCII ne devraient pas être enregistrés dans le sous-espace réservé pour les noms de domaine multilingues. Par exemple, l'enregistrement de noms de domaine ASCII commençant par "bq--" doit être bloqué si RACE est choisi. Ensuite, comme une étiquette de domaine ne devrait pas excéder 63 caractères ASCII, cela ne permet de traiter qu'un nombre limité de caractères multilingues - par exemple, 18 caractères japonais. Ceci restreindra les étiquettes de domaine multilingues à des longueurs plus courtes que celles des étiquettes de domaine ASCII. De plus, des hiérarchies de domaine plus profondes ne peuvent être obtenues car la longueur totale d'un nom de domaine ne peut excéder 255 caractères.

5.3                 Internationalisation des noms d'hébergement dans les applications (IDNA)

52          Pour utiliser l'Internet dans son état actuel, Nameprep et ACE devraient opérer les traductions avant d'envoyer le nom de domaine "sur le fil" au système DNS ou au serveur d'application. L'architecture d'application dans laquelle Nameprep et ACE sont réalisés suivant la correspondance du code local à Unicode s'appelle IDNA, comme indiqué à la Figure 6 (ci-dessous). A la réunion d'août 2001 de l'IETF, de nombreux participants soutenaient la solution côté client IDNA.

 Figure 6

6                      Impact sur la structure du système DNS

53          Une exigence de base du système DNS est la capacité à identifier les entités sur l'Internet. Pour satisfaire à cette exigence, la structure de l'espace de nom de domaine hiérarchisé doit être coordonnée sur le plan administratif. Ceci est actuellement réalisé par l'ICANN sous la supervision du Ministère américain du Commerce[50]. Ceci signifie que l'autorité de la racine de la hiérarchie DNS indiquée à la Figure 1, page 11 , est généralement l'ICANN. Cette racine est parfois appelée la racine de l'autorité.

7                      Racines alternatives

54          Un nombre croissant de solutions logicielles offrent maintenant ce qu'on appelle des systèmes de racine alternative. Elles incorporent le système DNS public et l'étendent en offrant des domaines de premier niveau supplémentaires, permettant ainsi aux utilisateurs de l'Internet de voir d'autres noms de domaine que ceux reconnus par l'ICANN. A moins qu'il n'y ait une sorte de coordination administrative mondiale des domaines de premier niveau[51], il pourrait en résulter une fragmentation de l'Internet en espaces disparates de nommage.

55          Pour répondre à ce souci, l'ICANN a récemment publié une prise de position[52] faisant valoir la nécessité d'une racine de l'autorité du système DNS public unique, qui devrait être gérée comme un service public, et assurant que l'ICANN a assumé ce rôle de service public. Il est généralement admis parmi les experts techniques qu'un espace de nommage public unique est nécessaire pour maintenir l'intégrité et la connectivité mondiale du système DNS. Il paraît utile de citer ici une déclaration du Conseil de l'architecture Internet ("IAB"), parue dans RFC 2826[53]:

·         "Pour rester un réseau mondial, l'Internet a besoin qu'existe un espace de nommage public unique au niveau mondial. L'espace de nommage DNS est un espace de nommage hiérarchisé, dérivé d'une seule racine, unique au niveau mondial. C'est une contrainte technique inhérente à la conception du DNS. Il n'est donc pas techniquement faisable qu'il y ait plus d'une racine dans le DNS public. Cette racine unique doit être soutenue par un ensemble de serveurs racines coordonnés, gérés par une autorité de nommage unique".

56          Tandis que les arguments procèdent de perspectives aussi bien que d'intérêts économiques variés, il semble qu'il y ait un assentiment général quant à la nécessité d'un espace de nommage DNS visible d'un maximum d'utilisateurs de l'Internet: un espace de nommage très fragmenté n'est intéressant pour personne. A l'évidence, les gestionnaires de domaines de premier niveau "non officiels" dans des systèmes de racine alternatifs ont l'un et l'autre plaidé: a) pour l'inclusion dans la "racine de l'autorité"; et b) contre l'introduction par l'ICANN de TLD identiques à leurs TLD utilisés dans des racines incluant des racines alternatives. Ils soutiennent aussi qu'il est possible d'avoir une fonction racine coordonnée administrativement qui évite les collisions entre les différents domaines de premier niveau fondés sur des systèmes de racine multiples. Ceci suggère que le débat demeure plus autour de qui est la racine ou l'autorité de coordination de nommage plutôt que sur les mérites d'un espace de nommage coordonné unique.

8                      Résolution de nom de domaine multilingue par des racines alternatives

57          Les spécifications standard existantes ne peuvent pas accepter les noms de domaine multilingues. Le déploiement de domaines multilingues avec une technologie propriétaire pourrait encourager l'émergence de racines alternatives. Du point de vue de l'utilisateur, il pourrait en résulter qu'un nom de domaine se rapporte à des entités complètement différentes dans différents espaces de nommage sous différentes structures de racine. En particulier, parce que l'introduction de nouveaux domaines de premier niveau est un processus extrêmement long, on peut se demander si le marché arrivera simplement à dépasser les arrangements administratifs actuels.

58          Un argument avancé par ceux qui proposent des racines alternatives pour la résolution des noms de domaine multilingues est que l'autorité de l'ICANN provient principalement des Etats-Unis d'Amérique, qui ont été considérés comme la source historique des noms de domaine Internet fondés sur ASCII. Il est dit que, comme les noms de domaine multilingues ont une autre origine, les racines alternatives qui servent de support aux domaines multilingues de tête peuvent être plus acceptables que certains ne le prétendent. D'autres soutiennent le concept de racine "inclusive", qui permet à des domaines de premier niveau non soumis à l'autorité de l'ICANN d'être utilisés à des fins nationales ou commerciales. Dans ce cas, tant que les utilisateurs cadrent leurs applications sur la racine inclusive, ils sont à même de résoudre les noms de domaine ICANN aussi bien que les noms de domaine non ICANN - avec un accès direct aux nouveaux domaines de premier niveau multilingues. Certains voient à nouveau des problèmes avec ce modèle en ceci qu'il pourrait y avoir plusieurs entités qui revendiquent la gestion de la "racine inclusive". Ceci pourrait conduire à des conflits d'espace de nommage qui devraient être résolus par négociation, arbitrage, ou même procès. Dans le pire des cas, cela pourrait conduire à la fragmentation de l'espace de nommage Internet comme prédit par l'IAB dans le document RFC 2826.

9                      Pseudo-racines

59          Il existe une voie un peu plus subtile pour la création d'un espace de nom de domaine multilingue, qui consiste à réaliser un "domaine de premier niveaunon ASCII imaginaire" dans l'espace de nom de domaine sous autorité. Cette méthode, appelée domaine de niveau zéro, a été suggérée dans des projets de documents de l'IETF dès 1997. Elle masque la partie supérieure de l'espace de nom de domaine, supposant que l'un des noeuds supérieurs de l'espace non masqué joue le rôle de domaine de premier niveauvirtuel, et utilisant le sous-espace gouverné par le domaine virtuel de tête comme espace entier de nom de domaine. Par exemple, après avoir créé un espace {chaîne non ASCII}.TLD sous le domaine de premier niveausous autorité ".TLD", les utilisateurs peuvent accéder à l'Internet en utilisant des noms de domaine comme xxx.{chaîne non ASCII} si les applications client des utilisateurs délient et/ou relient automatiquement ".TLD" à chaque accès à l'Internet. Ceci peut faire un domaine (virtuel) multilingue de tête pour les utilisateurs de telles applications client. Même si les domaines de niveau zéro sont en quelque sorte plus acceptables que les racines alternatives, les utilisateurs doivent néanmoins être conscients du problème que différentes entités peuvent être apparemment désignées par le même nom de domaine si différentes applications client sont utilisées.

60          Ce ne sont pas par eux-mêmes les noms de domaine multilingues qui conduisent à la création de racines alternatives ou de pseudo‑racines. C'est plutôt la combinaison d'intérêts commerciaux et de la demande des utilisateurs pour un déploiement rapide de nouveaux TLD, qu'ils soient en anglais ou en écritures multilingues. Si les politiques de création de nouveaux TLD sont capables de satisfaire les demandes des utilisateurs et du commerce, le risque de fragmentation est largement réduit. Ceci suggère qu'il est extrêmement important que l'ICANN trouve des méthodes pour répondre effectivement à cette demande.

10                 Questions de politique et de coordination soulevées par les noms de domaine multilingues

61          La technologie est toujours au début d'un processus, et non à la fin. Avant qu'une technologie puisse être pleinement utilisée, elle doit être soutenue par l'économie et la politique. La présente section discute des questions politiques majeures qui se rapportent aux noms de domaine multilingues.

11                 Considération des noms de domaine multilingues dans divers TLD

62          Dans le système DNS actuel, fondé sur ASCII, il y a deux types de base de domaines de premier niveau: les domaines génériques de premier niveau (gTLD), tels que .com et .info, et les domaines de premier niveau qui sont des codes de pays (ccTLD), tels que .uk et .jp. Il y a moins de 15 gTLD, et leurs politiques sont, pour la plus grande partie[54], sous le contrôle de l'ICANN. Il y a actuellement environ 245 ccTLD[55], et la politique de chacun d'eux est pour la plus grande partie, sous le contrôle d'une organisation de gestion des ccTLD, généralement dans leurs pays ou régions respectives[56].

11.1             Types potentiels de noms de domaine multilingues

63          Différentes sortes de noms de domaine multilingues peuvent émerger, selon la sorte de TLD sous lequel ils viennent ou qu'ils représentent. Il peut y avoir des noms de domaine multilingues de même langage, même écriture, ou de langue mixte, écriture mixte. Cela peut être représenté comme suit:

·         {chaîne non ASCII}.{ASCII-ccTLD};

·         {chaîne non ASCII}.{ASCII-gTLD};

·         {toute chaîne}.{non ASCII-ccTLD};

·         {toute chaîne}.{non ASCII-gTLD}.

64          La notation ci-dessus n'est pas formellement définie ici, où il est bien suffisant d'avoir à se débattre avec les principes de base. De plus, il est tout à fait possible que d'autres types de TLD multilingues puissent émerger. Par exemple, des TLD en rapport avec une langue, qui indiquent le langage des noms de domaine associés: par exemple, {chaîne chinoise}.{CHINOIS} ou {chaîne japonaise}.{JAPONAIS}, dans lesquelles "CHINOIS" et "JAPONAIS" représentent les caractères chinois et japonais pour le nom de la langue.

11.2             Questions techniques et non techniques

65          Bien que les obstacles à la mise en oeuvre de ces noms de domaine multilingues soient principalement de nature non technique, un obstacle technique potentiel réside dans la charge croissante qui pèse sur le système DNS, et cela parce qu'une {chaîne non ASCII} est inhabituellement longue lorsqu'on la code en format ACE. Parmi d'autres obstacles techniques figure la nécessité du multilinguisme des systèmes qui s'y rapportent, tels que le système Qui‑est‑qui (Whois), application qui affiche les attributs associés des noms de domaine (par exemple, information sur celui qui enregistre). D'un autre côté, parmi les obstacles non techniques, on trouve:

·         des questions se rapportant à la responsabilité pour l'enregistrement des noms de domaine;

·         des questions à résoudre dans le processus d'enregistrement et d'utilisation.

Le second de ces obstacles sera discuté dans les sections suivantes. Le premier est décrit dans la présente section en classant les sujets selon le type de domaine de premier niveauconsidéré.

11.3             Noms de domaine mixtes multilingue-ASCII

66          Un certain nombre d'organisations jouent déjà un rôle d'opérateur en ce qui concerne {chaîne non ASCII}.{ASCII-ccTLD} et {chaîne non ASCII}.{ASCII-gTLD}. Par exemple, VGRS offre des enregistrements {chaîne-chinoise}.com[57], et JPNIC/JPRS propose {chaîne-japonaise}.jp. La base de la fourniture de ces services est que l'organisation impliquée a "autorité" sur un ccTLD ou gTLD et, si le système DNS est internationalisé, que cette autorité est une base suffisante pour déléguer des noms de domaine multilingues {non ASCII}.{ASCII} sous le TLD correspondant.

11.4             Noms de domaine multilingues.multilingues

67          ".日本" ("日本" représente "Japon" en caractères Kanji japonais) est un exemple de {ccTLD non ASCII}. Si un {ccTLD non ASCII} et son organisation de gestion sont coordonnés avec l'ICANN, il peut ne pas y avoir de problème en ce qui concerne les décisions d'autorité tant qu'il n'y a pas de conflit sur le fait de savoir que c'est cette organisation qui dispose de l'autorité légitime. Dans le cas du japonais, donc, comme le siège de la langue est au Japon, et qu'aucun autre pays n'a désigné le japonais comme étant sa langue officielle, cette décision apparaît bien tranchée. Cependant, on devrait noter que les mêmes caractères japonais "日本" sont aussi utilisés dans le jeu de caractères chinois et que leur graphisme est identique. Ces caractères particuliers ne devraient normalement pas être utilisés comme un TLD chinois et alloués à une autre organisation. Le japonais utilise aussi deux autres écritures, en l'occurrence le Katakana et le Hiragana, mais comme aucun autre pays n'utilise ces écritures, il est peu vraisemblable que cela donne lieu à des complications.

68          Pour les autres langages, les questions seront beaucoup plus complexes. Si un pays ou une région correspondant à un code de pays a deux, ou plus, langues officielles, il peut être nécessaire de décider quelle langue est utilisée pour représenter son code de pays "code"{ccTLD non ASCII}, en supposant que "code de pays" a un équivalent dans cette langue. Même si on établit la règle que deux ou plus {ccTLD non ASCII} peuvent être alloués à un pays ou région, il reste la question de savoir combien de {ccTLD non ASCII} on doit allouer au pays ou région pour le nombre de langages officiels ou en usage dans sa juridiction. Par exemple, dans le cas de l'Inde, il y a plus de vingt langues d'usage courant, chacune d'elles ayant sa propre écriture.

69          ".企業" ("企業" est une chaîne de caractères chinois traditionnels signifiant "une compagnie") est un exemple de {gTLD non ASCII}. Le fait que de multiples langues peuvent aussi utiliser ces caractères est un problème. A cause de cela, des chaînes identiques peuvent représenter les mêmes significations ou des significations différentes dans différentes langues. Et aussi, des caractères similaires existent dans différentes langues. Par exemple, la Chine et le Japon utilisent le mot "企業", et les gens ne peuvent dire si le domaine de premier niveau"企業" est en chinois ou en japonais. Autrement dit, les noms de domaine multilingues peuvent plonger les gens dans la confusion en dépit du but affiché de rendre les noms de domaine plus faciles à mémoriser. Il est très difficile de décider qui devrait être désigné pour gérer ces types de domaines de premier niveau(et dans quel pays). Etant donné les difficultés rencontrées pour simplement introduire de nouveaux domaines de premier niveauASCII, il n'est pas difficile d'imaginer les défis représentés par l'idée d'introduire des domaines multilingues de tête.

12                 Quelles sont les langues qui constituent des noms de domaine multilingues?

70          Une des questions qui devraient être examinées est la définition des langues du point de vue des noms de domaine multilingues. Certaines langues ont deux, ou plus, types d'écritures, et certaines langues ont des écritures mêlées dans la forme écrite de la langue. Par exemple, les documents japonais écrits mêlent des caractères Han chinois, des caractères japonais Katakana et Hiragana, des chiffres arabes, aussi bien que des caractères de l'alphabet anglais. Dans ce cas, toutes les chaînes possibles d'un document écrit japonais peuvent-elles être des noms de domaine multilingues? Dans quelle langue sont les caractères chinois Han lorsqu'ils sont utilisés comme nom de domaine multilingue dans un document japonais?

71          De plus, il faudra prendre en compte les règles locales telles que l'unification des caractères chinois traditionnels et des caractères chinois simplifiés, dont il est question au § 37; et même dans la perspective de savoir s'il s'agit de la même langue ou de langues différentes. Par exemple, est-ce que la "fusion" (voir le § 46) des caractères chinois Han traditionnels et simplifiés affecterait l'utilisation des caractères Han dans d'autres langues non chinoises?

13                 Qui est l'autorité de langage pour les noms de domaine multilingues?

72          Une autre question est de savoir si les sujets décrits aux § 70 et 71 sont des affaires locales ou internationales. Dans le but de clarifier les choses pour les utilisateurs, certains plaident que les règles s'appliquant aux noms de domaine multilingues devraient être les mêmes, bien qu'elles relèvent d'autres domaines de tête. Par conséquent, un registre de nom de domaine unique[58] ne devrait pas être l'autorité ultime pour les règles des noms de domaine multilingues. A titre d'exemple, faut-il que les règles de représentation et de conversion pour les noms de domaine chinois dans .com et dans .cn[59] soient les mêmes? Dans cet exemple, la définition des règles pour les noms de domaine multilingues chinois serait par nature un problème international. Cependant, la communauté internationale qui n'utilise pas la langue chinoise, serait-elle capable de définir les questions de localisation à la place des locuteurs chinois? Et comme le chinois est la langue d'une diaspora, qu'il est utilisé dans diverses juridictions, pays et économies, comment donner une localisation à ces décisions?

73          Il est extrêmement difficile, sinon impossible, pour ceux dont la langue n'est pas concernée par cette discussion d'en appréhender les implications subtiles. Comprendre si les questions des § 70 et 71 sont des problèmes de code ou des problèmes de protocole est très difficile. Mais cette compréhension est nécessaire pour mener à une décision acceptable sur le point de savoir quelles questions doivent faire l'objet d'une normalisation internationale. Quelqu'un doit décider quelles questions existent et comment elles doivent être résolues. Peut-être qu'un premier pas pragmatique est de résoudre qui est l'autorité décisionnelle pertinente vraisemblable.

13.1             Matrice d'autorité

74          Jusqu'à présent, un certain nombre de combinaisons de pays/économies, langage, écriture, et systèmes de codage sont apparues et des exemples en sont donnés au Tableau 1 . Le Tableau 1 suggère qu'une approche de type "taille unique" a très peu de chances de succès.

Tableau 1

13.2             Modèles pour une matrice d'autorité

75          Le tableau ci-dessus suggère qu'il sera important pour les parties prenantes d'un langage de se coordonner entre elles. En cas de besoin, les organisations régionales ou internationales peuvent être des forums appropriés. Généralement, en principe et autant que possible, il semble approprié que des décisions affectant les utilisateurs d'un langage soient prises par les utilisateurs de ce langage eux-mêmes. Le Tableau 2 suggère quelques‑uns des modèles qui pourraient être pris en considération.

Tableau 2

14                 Résumé

76          Pour rendre les noms de domaine multilingues pleinement utilisables sur l'Internet, la normalisation technique ne sera que la partie apparente de l'iceberg. Pour satisfaire les exigences des utilisateurs, il sera nécessaire aussi de franchir les étapes suivantes:

·         normaliser les techniques;

·         définir et coordonner les règles d'enregistrement et de gestion;

·         déployer les serveurs d'application et de nommage.

Les relations entre ces étapes, nécessaires pour le déploiement des noms de domaine multilingues, sont illustrées ci-dessous à la Figure 7.

 Figure 7

77          Pour ce qui concerne la normalisation technique, il est prévu que la normalisation de Nameprep, ACE, et IDNA (voir les § 43 à 52) soit achevée au premier semestre 2002, conformément au calendrier proposé par le Groupe de travail IDN. Cependant, comme il faut prendre en considération toutes les langues du monde, les spécifications de la norme devront nécessairement subir des évolutions ultérieures. De plus, comme le système DNS évolue lui-même, des solutions à long terme, telles que des solutions fondées sur les serveurs ou des couches de logiciels supplémentaires pourraient apparaître (par exemple, des mots-clés) et se révéler offrir de meilleures solutions.

78          Les questions de politique et de coordination discutées aux § 61 à 75 devront être résolues dans un très proche avenir. Cependant, des solutions peuvent être trouvées grâce à la coopération nationale, régionale et internationale.

79          Le développement de serveurs de nommage et d'applications doit s'appuyer sur la dynamique du secteur des affaires. Pour arriver à une utilisation satisfaisante, il est important de promouvoir le développement aussi bien des serveurs que des applications. Il est vital que le développement d'application soit stimulé et fasse l'objet d'une promotion intense. A titre d'exemple concret, l'Association des noms de domaine en japonais (JDNA), constituée en juillet 2001, comporte des membres japonais qui sont des vendeurs d'applications, des fournisseurs de services réseau et des registres de noms de domaine. Au sein de JDNA, on peut déterminer les spécifications nécessaires sur le plan local telle que la représentation détaillée des URL et des adresses e‑mail.

80          Pour résumer, il y a un marché substantiel et une demande des utilisateurs pour des noms de domaine multilingues. Pour satisfaire cette demande, c'est l'environnement tout entier qui devra être développé pour prendre en compte la normalisation technique, la politique et les arrangements administratifs et les nouvelles applications. L'avènement des noms Internet multilingues est imminent. Nous ne devons pas sous‑estimer la signification de cette activité comme partie d'un but bien plus noble: l'internationalisation en cours de l'Internet.

Annexe A

Glossaire des acronymes

Annexe B

Quelques mises en oeuvre de noms de domaine multilingues

81          Souvent la demande du marché n'attend pas qu'il y ait des solutions techniques parfaites, et c'est pourquoi certaines mises en oeuvre de noms de domaine multilingues sont d'ores et déjà apparues. Actuellement, ces mises en oeuvre reposent sur des technologies propriétaires ou des spécifications de normes incomplètes. Cependant, de nombreux fournisseurs de solution ont déclaré qu'ils s'aligneraient sur toute norme future une fois que la normalisation serait achevée. Quelques‑unes des mises en oeuvre connues sur le marché figurent ci-dessous en ordre alphabétique. Comme de nombreux fournisseurs de solution de nom de domaine multilingue utilisent les techniques de mots-clés Internet pour les services de résolution, les compagnies actives dans ce domaine ont également été citées. Les informations fournies le sont, dans la plupart des cas, par le fournisseur de solution. Comme les développements interviennent rapidement dans ce domaine, cette liste est par définition incomplète. Nous souhaiterions que l'on nous communique d'autres informations ou précisions sur les solutions offertes sur le marché.

14.1             Consortium des noms de domaine en chinois (CDNC)

82          Le 19 mai 2000, le Consortium des noms de domaine en chinois (CDNC) a été constitué à Pékin par quatre centres d'information réseau (NIC) autour du Détroit de Taïwan, qui sont le Centre d'information du réseau Internet de Chine (CNNIC), le Centre d'information réseau de Taïwan (TWNIC), le Centre d'information réseau de Hong Kong (HKNIC) et le Centre d'information réseau de Macao (MONIC). En tant qu'organisation à but non lucratif indépendante, CDNC s'occupera principalement de la coordination et de la réglementation des noms de domaine en chinois dans le monde entier. Dans la mesure où les noms de domaine chinois jouent un rôle de plus en plus important en Chine, un grand nombre d'organisations et compagnies ont montré de l'intérêt pour la recherche et la popularisation de noms de domaine en chinois et s'y joignent activement. Cependant, à cause du manque de communication et de coordination entre eux, il y a de très grandes différences dans les approches et les technologies de soutien au système chinois de noms de domaine, ce qui retarderait gravement sa diffusion. Pour éviter ces problèmes, les quatre NIC ont plaidé en faveur de CDNC et l'ont finalement constitué, ce qui améliorera la coordination et la coopération des noms de domaine chinois.

83          Le CDNC va évaluer toutes les questions de résolution de nom de domaine en chinois, en se conformant strictement aux critères internationaux, et va rédiger les normes techniques pour les noms de domaine chinois et les règlements correspondants pour l'enregistrement des noms de domaine chinois. Il coordonne aussi son rodage dans les autres pays ou régions, communique et coopère avec toutes les organisations internationales correspondantes de telle sorte que dans le proche avenir CDNC puisse faire des normes internationales.

14.2             Centre d'information du réseau Internet de Chine (CNNIC)

84          CNNIC[60] fournit à l'essai l'enregistrement des noms de domaine en chinois en utilisant des solutions techniques fondées sur les exigences techniques des noms de domaine internationaux et les exigences des utilisateurs de noms de domaine en chinois.

85          La résolution est "côté serveur" et utilise l'expédition HTTP. Ils fournissent aussi le téléchargement de mots-clés aux clients pour la résolution.

14.3             i-DNS.net

86          i-DNS.net[61] est un fournisseur de solutions de noms de domaine internationaux (IDN) et teneur de registre pour les noms de domaine en {caractère-du-pays}.{caractère-du-pays}. Les domaines génériques de tête (gTLD) acceptés par i-DNS.net sont des versions en langue locale de .com, .net et .org, choisies après consultation avec les centres d'information réseau (NIC) locaux et les experts en linguistique du pays.

87          Tous les noms enregistrés et hébergés dans la base de données d'enregistrement de i‑DNS.net sont compatibles avec le système DNS existant, et jouissent d'une délégation pleine et entière de sa part. Ces noms sont résolubles mondialement via une large gamme de méthodes de résolution, y compris le logiciel largement répandu iClient - un progiciel de résolution côté client fondé sur Windows.

88          Les offres IDN de i-DNS.net sont conformes aux recommandations et normes promulguées par le Groupe de travail IDN du Groupe d'étude pour l'ingénierie Internet (IETF), qui sont - côté client, fondées sur Nameprepped et ACE. Grâce à ses partenaires unités de l'enregistrement (registraires) et stratégiques, i-DNS.net a lancé ses services d'enregistrement dans le monde entier dans plus de 30 langages.

14.4             Centre d'information réseau du Japon (JPNIC)/Service du registre du Japon (JPRS)

89          JPNIC[62]/JPRS[63] fournit des services d'enregistrement et de résolution pour les noms de domaine en japonais[64] avec une solution côté client utilisant presque la même technologie que VGRS (voir les §104 à 108 ci-dessous). JPNIC/JPRS accepte les noms de domaine multilingues écrits en japonais sous son ccTLD .jp et facture le même montant pour l'enregistrement des noms de domaine multilingues que pour les noms de domaine ASCII.

90          Il fournit les fonctions suivantes:

·         Utilisation de RACE (et dans un avenir proche ACE-AMC-Z) pour transcoder les noms de domaine japonais en chaînes ASCII.

·         Etablissement des chaînes ASCII dans les serveurs de nommage du système DNS ordinaire comme noms de domaine.

·         Fourniture de kits de développement pour des applications telles que des moteurs de recherche web pour leur permettre de se rapporter au système DNS avec des noms de domaine en japonais.

·         Enregistrement de plus de 60 000 noms de domaine, ce qui permet leur utilisation. De plus, la technique de résolution de mots-clés RealNames est utilisée, de façon similaire à VGRS.

·         Avant l'enregistrement sur la base du "premier arrivé, premier servi", JPNIC/JPRS a pris quelques mesures de précaution comme le blocage de préfixe, les mots réservés et une période de latence afin d'éviter les problèmes de propriété intellectuelle et les faux départs.

14.5             Centre d'information réseau de Corée (KRNIC)

91          KRNIC[65] a effectué des enregistrements expérimentaux de {chaîne-coréenne}.test.kr et {chaîne-coréenne}.실험.kr entre le 16 mars 2001 et le 25 avril 2001 pour vérifier la faisabilité du déploiement des noms de domaine en Hangeul.

92          Pour les services, KRNIC a mis en oeuvre ce qui suit:

·         utilisation de BIND 8.2.3 avec peu de modifications;

·         téléchargement des fichiers de zone en format EUC-KR, UTF-8 et RACE;

·         réponse directe aux questions avec des adresses IP;

·         développement de plusieurs normes sous RFC-KR dont une sur les domaines de second niveau;

·         développement actuel de plusieurs autres normes sous RFC-KR;

·         début d'essais de TLD multilingues;

·         développement de Nameprep pour les caractères coréens.KRNIC entreprendra d'autres essais ultérieurement et décidera quand commencer l'enregistrement formel de noms de domaine en Hangeul.

14.6             NativeNames

93          NativeNames[66] propose des noms équivalents en arabe, farsi, urdu et cyrillique des gTLD existants .com, .net et .org, et offre l'équivalent de nouveaux TLD dans ces langages[67]. Selon Pyramid Research, NativeNames est leader sur le marché en croissance rapide du DNS international au Moyen‑Orient arabe[68], et il déclare que "la présence croissante de noms de domaine en caractères arabes contribue à dynamiser l'adoption de l'Internet au Moyen‑Orient et en Afrique du Nord".

14.7             Neteka

94          Neteka[69] n'est pas par lui-même un registre ou une unité de l'enregistrement (registraire), mais fournit pour les noms de domaine multilingues une solution qui est une combinaison de solutions côté serveur et côté client. Cette solution permet l'enregistrement de {chaîne non ASCII}.gTLD, {chaîne non ASCII}.ccTLD et de {chaîne non ASCII}.SLD, où SLD représente un domaine de second niveau.

14.8             Netpia

95          Netpia est un fournisseur de services de mots-clés Internet. Le coeur du service de mots‑clés Internet de Netpia donne aux gens l'accès aux sites web de l'Internet dans leur propre langue maternelle sans avoir à se rappeler de cet étrange nom de domaine en anglais.

96          Multilingual Internet Keyword Name (Nom de mot-clé Internet multilingue) est un système de nom de domaine de la prochaine génération, solution brevetée développée par Netpia.com en 1997. La force première du nouveau système est d'accepter le système actuel d'adressage de l'Internet (DNS) tout en permettant un système de reconnaissance multilingue (MSS: Multilingual Scan System). Le double soutien introduit un nouveau concept dans l'environnement en rapide évolution de l'Internet. Avec la chute des barrières entre les pays provoquée par la révolution numérique, Netpia projette d'étendre son domaine d'activité de l'Internet multilingue et de mots-clés à d'autres pays où l'anglais n'est pas une langue officielle, ce qui serait pour cette compagnie une source fraîche de nouvelle opportunités d'affaires.

97          Netpia est supposé normaliser les mots-clés Internet multilingues. Comme les langues maternelles deviennent des ccTLD, de même font les mots-clés Internet. Par la suite, .kr, .jp, .cn ne seront pas nécessaires quand on surfera sur le web. Le projet de Netpia est de permettre aux gens de surfer sur le web dans leur propre langue en donnant une base locale au système d'adresse Internet.

14.9             New.net

98          New.net est un registre de nom de domaine et unité de l'enregistrement (registraire) commercial travaillant sur des noms de domaine plus descriptifs et significatifs dans de multiples langues. En 8 mois, New.net a construit un réseau volontaire de 73 millions d'utilisateurs Internet qui peuvent accéder à, et résoudre, des noms de domaine dans 6 langues différentes. New.net a mis sur le marché 30 extensions en langue anglaise comprenant .shop, .family, .mp3 et .club, et des extensions traduites pour les communautés de langue espagnole, portugaise, française, italienne et allemande, telles que .tienda, .reise et .amor.

99          Pour permettre aux utilisateurs d'accéder à ces noms de domaine, New.net forme des partenariats avec des ISP (fournisseurs de services Internet) qui font des changements mineurs aux logiciels de leur serveur de nommage. Tous les clients des ISP partenaires de New.net reçoivent ainsi la capacité de voir les noms de domaine de New.net. Pour ceux qui ne se connectent pas à l'Internet en utilisant un ISP partenaire de New.net, il y a un petit logiciel à télécharger pour permettre l'utilisation d'un ordinateur individuel.

100        New.net livrera une solution IDNA au premier trimestre de 2002 et elle sera conforme aux normes promulguées par le Groupe de travail IDN du Groupe d'étude d'ingénierie de l'Internet pour la résolution des noms de domaine IDN.IDN. New.net s'occupera aussi de prendre des enregistrements et d'accréditer des unités de l'enregistrement (registraires) pour encourager l'enregistrement et l'usage de ces noms de domaine.

101        L'intention déclarée de New.net est de "continuer à travailler avec le système DNS existant pour fournir des solutions pratiques au nommage Internet pour les utilisateurs du monde entier. Ceci inclut des recherches à long terme sur le côté serveur sur la question de la résolution IDN." 

14.10         RealNames

102        RealNames Corporation est un fournisseur d'infrastructure mondial de Keywords, plate‑forme supérieure de navigation et de nommage web qui apporte des améliorations au système de noms de domaine existant. Keywords remplace les URL compliquées par de simples noms et marques, et travaille dans la langue maternelle de l'utilisateur, rendant l'Internet plus facile à utiliser. Fondée en 1996, RealNames est située à Redwood City, Californie, avec des bureaux à Londres, Tokyo et Séoul.

103        Le service de résolution de mots-clés de RealNames fonctionne sur tous les appareils compatibles Internet, et sur de nombreuses applications et services. Il a été intégré dans le moteur Internet Explorer de Microsoft et dans le portail d'accès mobile d'Openwave Systems, ainsi que dans les principaux sites de recherche et portails d'accès.

14.11         Services mondiaux de registre VeriSign (VGRS)

104        VGRS[70] propose actuellement un banc d'essai de noms de domaine internationaux (IDN) qui pour l'instant fournit des services d'enregistrement et de résolution pour les noms de domaine multilingues utilisant une solution côté client. Dans le banc d'essai VGRS, seul le domaine de second niveau est internationalisé; le domaine en langue maternelle est suivi par un TLD autorisé par l'ICANN .com, .net ou .org pour former un nom de domaine en langue mixte. VGRS accepte plus de 39 écritures Unicode comme IDN. Il facture le même montant pour l'enregistrement de noms de domaine multilingues que pour des noms de domaine ASCII, bien que récemment tous les enregistrements d'IDN faits pendant la première année du banc d'essai aient été prolongés gratuitement pour six mois supplémentaires.

105        Le banc d'essai IDN de VGRS utilise le Codage compatible ASCII (ACE) que le Groupe de travail IDN de l'IETF propose actuellement pour transcoder les IDN en chaînes ASCII. L'ACE utilisé à l'origine était le codage compatible ASCII par rangée (RACE) et plus récemment ACE‑AMC-Z (Z). Les IDN n'ont pas encore été mises dans les zones .com, .net et .org; la résolution a été fournie au troisième niveau. Près d'un million de noms de domaine ont été enregistrés. De plus, la technique de mots-clés de RealNames est utilisée, rendant possible pour les utilisateurs de l'Explorer Internet de Microsoft d'accéder aux sites web qui ont des URL contenant des noms de domaine multilingues.

106        L'IETF a publié le projet d'algorithme RACE en mars 2000. VGRS a lancé à titre de banc d'essai le service d'enregistrement de nom de domaine international fondé sur RACE en novembre 2000. Avant le lancement du service d'enregistrement, certaines personnes transcodaient les noms de domaine multilingues en noms de domaine ASCII commençant par "bq--" et les enregistraient comme noms de domaine ASCII. Ceci signifie que des gens enregistraient des noms de domaine ASCII qui correspondaient à la version RACE des IDN avant que le service d'enregistrement n'ait débuté. Ce qui revient à dire qu'ils bloquaient en fait l'enregistrement IDN correspondant. Plus récemment, pour s'adapter au changement de cap de RACE à Z, le préfixe a été changé en "zq--".

107        Dans l'avenir, on pense que l'algorithme final ACE sera proposé comme norme avec un nouveau préfixe. Tous les préfixes non utilisés à quatre caractères se terminant par deux tirets ont été réservés pour .com, .net et .org, éliminant ainsi le problème qui était arrivé avec les noms RACE au début du banc d'essai.

108        Depuis le début du banc d'essai, VGRS s'était engagé à coopérer au processus de développement des normes: cet engagement perdure. Lorsqu'une norme sera proposée, elle sera mise en oeuvre et le banc d'essai prendra fin. Dans l'intervalle, pour minimiser les efforts de multiples conversions par les unités de l'enregistrement IDN, les unités de l'enregistrement continueront à soumettre les enregistrements IDN en format RACE et VGRS convertira les noms au format Z.

14.12         WALID

109        WALID[71] offre un service d'enregistrement {chaîne non ASCII}.{chaîne non ASCII} avec un logiciel client pour résoudre les noms de domaine multilingues enregistrés. La technologie WALID se fonde sur la recommandation IDNA/ACE approuvée par le Groupe de travail IDN de l'IETF, et accepte toutes les langues fondées sur Unicode à la fois pour l'enregistrement et la résolution. WALID offre aussi des solutions entièrement personnalisées avec des fonctions multilingues pour les registres et unités de l'enregistrement du monde entier. La technologie WALID fait partie du banc d'essai multilingue de VeriSign (voir les § 104 à 108 ci-dessus).