L'internationalisation des noms de domaine

Merci à Marc Blanchet, co-président du groupe " Internationalized Domain Names " à l’IETF pour sa relecture attentive et ses judicieux conseils et compléments.

 

L'importance de l'internationalisation

Les jeux de caractères multilingues (ISO10646-Unicode)

L'UCS-16

L'UCS-32

l'UTF-8

Le contexte des noms de domaine multilingues

Multilingual Internet Name Consortium (MINC)

Le problème technique

Le groupe de travail sur l'internationalisation des noms de domaine de l'IETF (idn)

Définition des besoins pour les idn (requirements)

Le protocole (idna)

La conversion des caractères multilingues en ASCII (ACE)

La préparation des noms de domaine (Name Preparation)

Les jeux de caractères asiatiques

le chinois (Hanzi)

Le coréen (Haja et Hangeul)

Le japonais (Kanji, Hiragana, Katakana)

Vietnamien

Trouver les équivalences pour garantir l'unicité des noms de domaine

Futurs travaux

Références

 

 

 

L'importance de l'internationalisation

L'Internationalisation est un enjeu majeur au moment où l'Internet touche à la fois une population plus large, et plus diversifiée. Les Etats-Unis représentent d'ores et déjà moins de la moitié des Internautes et le nombre de langues parlées sur la toile va en grandissant. Par exemple, sur les 1,2 milliards de Chinois, environ 400 millions disposent d'un pouvoir d'achat suffisant pour accéder prochainement à l'Internet. Par comparaison, l'ensemble de la population de l'Union Européenne, toutes populations confondues, avoisine les 350 millions.

La tentation est grande souvent de simplifier le problème en pensant que c'est aux hommes de s'adapter aux machines et non l'inverse. Ainsi, un américain lors de la session idn à l'IETF-50 a expliqué que l'on n'avait pas besoin de tout cela et que les seules langues étrangères qu'il avait apprises à l'école étaient la musique et le langage de programmation Pascal !

L'exemple donné par YJ Park est éloquent : Si l'Internet avait été inventé en Thaïlande et si tous les noms de domaines utilisaient des caractères thaïs comme standard, pourrions-nous, les non-thaïs, nous rappeler facilement cet URL ?

Des voix s’élèvent également pour se demander si beaucoup de travaux sur l’internationalisation ne sont pas plus basés sur des besoins commerciaux de certaines sociétés que sur de véritables besoins des utilisateurs. Il s’agit probablement d’être très attentif pour que les travaux sur l’internationalisation qui sont souvent très complexes ou même périlleux (voir le cas des noms de domaines multilingues plus bas) soient bien basés sur les besoins de la grande diversité des nouveaux utilisateurs qui sont de plus en plus touchés par le phénomène Internet.

Les populations qui n'utilisent pas les jeux de caractères latins doivent-elles être les parents pauvres de la société de l'Information ? Le slogan de l'Internet Society "L'Internet est pour tous" veut apporter une réponse à ce point.

L’Internationalisation a été définie comme une des priorités de l’IETF et est incluse dans une politique officielle (RFC2277).

Les jeux de caractères multilingues (ISO10646-Unicode)

Il existe une norme incluant la plupart des caractères utilisés sur la planète. Elle résulte de la fusion entre les travaux de l'organisme de normalisation international l'ISO et du consortium Unicode : ISO 10646-Unicode.

Il s'agit en fait d'un ensemble de caractères permettant l'utilisation des différentes langues. On l’appelle " jeu universel de caractères ". Il existe différentes manières de coder ce jeu universel de caractères : l'UCS-16, UCS-32 et l'UTF-8.

L'UCS-16

L'UCS-16 (Unicode Character Set 16 bits) permet un codage sur 16 bits des caractères (la proposition originelle d'Unicode). Elle regroupe une grande partie des caractères nécessaires. Les autres caractères peuvent être ajoutés sur d'autres "plans" codés chacun sur 16 bits supplémentaires.

Un caractère UCS-16 est souvent représenté sous la forme U+XXXX où U signifie Unicode et XXXX est un nombre hexadécimal de 16 digits (soit 16 bits).

Par exemple U+0082 signifie un 'é' et U+5C71 représente l'idéogramme signifiant la montagne en chinois

L'UCS-32

L’UCS-32 permet le codage des caractères sur 32 bits. Il prend 2 fois plus de place que l'UCS-16 et 4 fois plus de place que le jeu de caractères 8 bits que nous utilisons en français (ISO/IEC 8859-1), mais il permet d'intégrer la quasi-totalité des caractères. Certaines langues anciennes ne sont pas encore insérées et il reste des problèmes à régler dans les futures versions (par exemple entre le coréen et le japonais).

l'UTF-8

Puisqu’un jeu de 16 ou 32 bits n’est pas efficient dans l’utilisation courante des protocoles, des mécanismes de transformation, appelés Unicode Transformation Format (UTF) ont été définis. Un des mécanismes tout à fait intéressant permet de coder les caractères du jeu universel sur une taille variable. Ceci est très utile en particulier pour transférer des caractères d'un système à l'autre en optimisant la taille des messages transmis. Ainsi l'UTF-8 est supporté par de nombreux systèmes d'exploitation ainsi que par Java. En UTF-8, les caractères ASCII (principalement les caractères latins non accentués) seront codés avec un seul octet de manière identique. Les caractères latins accentués nécessiteront deux octets, les idéogrammes souvent 3 octets etc... Ainsi, on peut dire par extension qu’un fichier contenant uniquement de l’ASCII est aussi un fichier UTF-8, puisque les codes binaires sont identiques.

Le contexte des noms de domaine multilingues

Les noms de domaines accessibles en multiples langues représentent la troisième étape qui doit permettre à tous d'accéder à l'Internet dans sa propre langue :

1. La première étape a été de fournir des logiciels dans plusieurs langues. Par exemple le navigateur Opera est disponible dans plus de vingt langues (http://www.opera.com/opera5/localization.html )
2. La deuxième étape a permis de fournir des contenus multilingues. Les travaux sur les jeux de caractères (Unicode et ISO 10646), et leur prise en compte dans le standard HTML permet d'afficher des contenus dans différentes langues (voir par exemple les comptes rendus de l'Internet Fiesta 2000 en 15 langues dont l'arabe, le japonais et le coréen : http://212.73.194.71/report2000/index.html ). Le W3C a également travaillé sur les aspects d'internationalisation de HTTP, les URIs etc... (http://www.w3.org/International/ )
3. La troisième étape permet des noms de domaines et des URLs dans différents alphabets tout en les gardant accessibles quel que soit le lieu.
4. Les réflexions sur une quatrième étape prenant en compte des mots clés multilingues débute actuellement.

Les noms de domaines multilingues présentent un certain nombre de défis

• Des défis pour les utilisateurs, afin qu'ils puissent continuer d'accéder partout quel que soit le clavier dont ils disposent à tous les sites Web.
• Des défis techniques pour permettre l'évolution des noms de domaines sans remettre en question l'existant.

Dans les années 1994-1998, l’Asian Pacific Networking Group (APNG : http://www.apng.org/commission/idns/ ) a porté ses travaux sur l’internationalisation dans l’Internet. A partir des travaux de Tin Tan Wee sur l’UTF-5, elle a produit dès 1998/1999 un premier jeu de test du procédé iDNS (Internationalized Domain Name System). 8 NICs asiatiques (organismes qui s’occupent de gérer les noms de domaine d’un pays), l’ont testé avec succès pour le support du chinois, du japonais, du coréen, du thaï et du tamul.

A la suite de cette expérience, un grand nombre de fournisseurs de technologies ont émergé, attirés par ce nouveau marché juteux ( .nu domain, Neteka Inc2000, iDNS.net International Inc, Network Solutions registry Inc appelé maintenant Verisign GRS , NetNatives, CNNIC, KRNIC, JPNIC...). Parmi ceux-là, IDNS.net est celui qui a promu l’invention initiale.

Il y avait un grand danger de " babelisation " de l’Internet et d’avoir des îlots non interopérables. Un groupe de travail a été mis en place rapidement à l’IETF (idn) pour traiter des aspects techniques.

L'Icann a d’abord été réticent (en juin 2000 à Yokohama, il a été déclaré que " l’ASCII est le langage de l'Internet "...). Il a ensuite accueilli une première réunion sur les noms de domaine internationaux à Marina del Rey en novembre 2000 et tout récemment lors de la réunion de Melbourne en mars 2001, l’Icann a mis en place des groupes de travail et un comité intérimaire pour les DNSO (Domain Name System Organizations). Il souhaite mettre en place les noms de domaines internationalisés lorsqu'ils seront standardisés à l’IETF.

Un consortium MINC qui traite plus largement de l'internationalisation des noms, mais laissant les spécifications techniques à l’IETF. s'est créé récemment.

Multilingual Internet Name Consortium (MINC)

Le " Multilingual Internet Name Consortium " (MINC : http://www.minc.org/ ) a d’abord été initié lors de la réunion de coordination de Pekin en janvier 2000 et est né officiellement les 12 et 13 juin 2000 à Seoul.

Le but de MINC est de :

• Coordonner les travaux de R&D sur les noms multilingues (ce qui comprend les noms de domaines internationalisés mais aussi par exemple les mots clés internationalisés).
• Coordonner le déploiement des noms internationaux
• Se coordonner avec les autres organisations concernées (IETF, W3C, Icann, ISOC, Unicode, IEEE, ISO et UIT)
• Coordonner le développement des standards en lien étroit avec l’IETF

En mars 2001, Minc regroupait 52 membres (20 en Asie, 1 dans le Pacifique, 5 en Afrique, 7 en Amérique Latine, 4 au Moyen-Orient, 13 en Amérique du Nord et seulement 2 en Europe : Core et Kulturserver).

MINC se réunit 4 fois par an. La prochaine réunion aura lieu à Stockholm en juin 2001 à l’occasion de la h1>

Actuellement le système de gestion des noms de domaine (DNS) ne supporte que les caractères ASCII codés sur 7 bits. Il en va de même pour plusieurs aspects de l'Internet (le champ objet et en général les champs d'en-tête des messages électroniques par exemple mais aussi d'autres applications telles que telnet).

Cela pose un problème pour les langues utilisant des caractères accentués tels que le français (dont les caractères sont en général codés sur 8 bits) et plus encore pour certaines langues n'utilisant pas les caractères latins mais des jeux de caractères idéogramiques qui demandent beaucoup plus de caractères (par exemple, le japonais, le chinois et le coréen).

Le problème des noms de domaine multilingues a été posé depuis le début des années 80 mais aucune solution satisfaisante n'ayant été trouvée, le problème est resté en l'état.

De plus, le DNS est une des infrastructures clé de l'Internet et on retrouve des noms de domaines partout. Une solution non compatible avec l'existant nécessiterait de modifier la quasi-totalité des protocoles de l'Internet ! Cette situation a fait dire à John Klensin, président de l'Internet Architecture Board de l’IETF lors de la session idn que "les noms de domaines multilingues sont un des problèmes les plus difficiles auquel nous ayons été confronté depuis le déploiement d'IP". Il avait également dit, il y a quelque temps " L’internationalisation de ‘l’Internet est le développement le plus important depuis que l’Internet est apparu ".

Le DNS est même le seul protocole développé par l'IETF qui n'a qu'une seule mise en oeuvre lors d'une nouvelle version acceptée (les règles de l'IETF imposent en général deux mises en oeuvres indépendantes interopérables pour approuver un RFC)

Si des jeux de caractères existent, il n'est pas toujours facile de s'y retrouver et les jeux utilisés ne sont pas toujours indiqués (les navigateurs et les clients de messagerie actuels envoient le plus souvent les noms de domaine sans vérification). Ainsi, la représentation en binaire d'un mot en français utilisant le jeu de caractère ISO/IEC 8859-1 peut très bien être la même qu'un autre mot en japonais utilisant le jeu de caractère Shift-JIS.

L'idéal est d'utiliser le jeu de caractères universel ISO10646-Unicode qui contient l’ensemble de tous ces jeux de caractères. Puisque seul le 7 bits est accepté, le système UTF-8 ne peut pas être appliqué directement sans réécrire la plupart des protocoles de l'Internet. Une première solution basée sur un codage UTF-5, proposé Martin Duërst, semblait cependant prometteuse : les premières pistes étaient là et il devenait possible de créer un groupe de travail au sein de l'IETF pour traiter de ce sujet. L'idée étant de transformer les caractères des différents jeux internationaux en une séquence de caractères ASCII qui pourront être utilisés tels quels par les DNS.

Il faudra cependant définir de nouveaux noms de domaines en particulier pour les pays qui utilisent des idéogrammes. Par exemple le japon qui utilise actuellement le nom de domaine .jp (ccTLD) souhaiterait également pouvoir disposer d'un nom de domaine en japonais. En japonais le mot "Japon" (prononcé "nippon") est représenté par la suite des deux caractères Unicode {U+65E5 U++672C} qui n’ont aucun rapport avec les caractères " jp ".

Le groupe de travail sur l'internationalisation des noms de domaine de l'IETF (idn)

Une première BOF (réunion informelle pour juger de l'opportunité de créer un groupe de travail) s'est tenue en novembre 1999. Le groupe idn lui-même est officiellement né en février 2000.

La première charte du groupe portait uniquement sur les besoins techniques. Mais celle-ci a ensuite été étendue pour y inclure des travaux sur un protocole pour les noms de domaine internationaux.

Le groupe idn a actuellement 3 équipes de proposition sur

• La préparation des noms (avant d'être convertis) (nameprep)
• Le protocole qui sera ensuite proposé comme standard
• Choix d'un modèle de conversion des caractères non-ASCII en séquence de caractères ASCII (Ascii-Compatible Encoding : ACE)

Définition des besoins pour les idn (requirements)

Version actuelle : draft-ietf-idn-req-04.txt

Un premier document produit par le groupe de travail définit les besoins techniques pour la mise en place des noms de domaines internationaux.

Quelques éléments importants qui y figurent :

• l'idn ne doit pas perturber le DNS actuel et les applications
• Il faut conserver un espace de nom unique, complet, universel et cohérent.
• Les noms de domaines doivent être uniques
• Le document recommande de n'utiliser que les caractères Unicode
• Il faut conserver l'équivalence entre les minuscules et les majuscules
• Le nom doit rester facilement modifiable
• idn doit fonctionner avec IPv4, IPv6, DNSsec, etc...
• etc...

Faut-il ensuite prendre en compte dans le futur protocole des aspects liés à la présentation ou laisser cela aux applications qui seront développées ?

Par exemple les chinois qui ont déjà ouvert dans le domaine .cn un enregistrement des noms en idéogrammes chinois souhaiteraient pouvoir utiliser un ordre dans les noms de domaine en chinois plus proche de l’approche traditionnelle, ce qui reviendrait à écrire les noms de domaine de manière inverse sous la forme cn.foo.www plutôt que l’habituel www.foo.cn.

Le protocole (idna)

Version actuelle : draft-ietf-idn-idna-01.txt (Internationalizing Host Names in Applications)

Le résumé du document indique : "L'infrastructure actuelle des noms de domaine ne permet pas l'utilisation de noms de serveurs internationalisés. Ce document décrit un mécanisme qui ne demande aucun changement dans les serveurs ou système de résolution DNS, qui permettra aux noms internationalisés d'être utilisés par les utilisateurs finaux et qui ne change que les applications. Il permet une flexibilité dans la saisie par les utilisateurs et dans l'affichage et s'assure que les noms de serveurs qui comprennent des caractères non-ASCII ne sont pas envoyés aux serveurs et aux systèmes de résolution DNS."

La solution proposée permet de transformer les caractères non-ASCII en une séquence de un ou plusieurs caractères ASCII qui sont ensuite envoyés au système DNS.

La conversion des différents jeux de caractères aractères multilingues en ASCII (ACE)

Une solution alternative pourrait être de contourner le DNS et d'utiliser les répertoires dans les couches plus élevées (par exemple utiliser LDAP). Il n'y a pas de répertoire mondial complètement déployé, mais ce pourrait être une solution sur le long terme.

La solution actuellement envisagée consiste à ne pas changer le DNS actuel mais à transcoder les caractères multilingues pour les convertir en ASCII (ACE : ASCII-compatible Encoding). Un simple préfixe permet de savoir s'il s'agit d'étiquettes en véritable ASCII ou s'il s'agit d'étiquettes ACE. Ce sont les applications qui seront chargées de l'encodage, de la détection et du décodage des caractères multilingues.

L'avantage de l'approche ACE est de ne pas toucher aux DNS actuellement déployés (qui ne verront toujours que des étiquettes en ASCII). La difficulté est que l'on perd le contrôle sur le déploiement (ce qui permet le cybersquatting) et que l'on devra limiter la longueur des noms pour les étiquettes qui ne sont pas en anglais.

Le groupe de travail a décidé de ne traiter que le jeu de caractère ISO 10646/Unicode et de ne pas prendre en compte les multiples jeux de caractères existant représentant des sous-ensembles adaptés à une langue. Cela évite d'avoir à indiquer le jeu de caractère utilisé et permet également des noms de domaine multilingues (plusieurs langues dans le même nom de domaine). Cela a cependant un inconvénient car le jeu ISO10646/Unicode contient beaucoup de "bruit" (caractères pour la compatibilité, caractères non affichables...). Il devient nécessaire de procéder à un nettoyage préliminaire. C'est l'objectif de la préparation du nom (Name Preparation).

Une des difficultés est qu'il existe plusieurs propositions concurrentes pour la conversion de caractères multilingues en ASCII (ACE) : Parmi elles UTF-5, RACE, BRACE, LACE, TRACE, AMC-ACE-M, DUDE, etc.

Il n'y a pas actuellement de consensus, mais un rapport sera préparé par le sous-groupe dans quelques semaines. L'équipe laissera alors le groupe choisir quel ACE choisir. En fait le groupe se concentre principalement sur 3 ACES :

• AMC-ACE-M qui permet une transformation en une passe en UTF-5. Il est plus efficace en compression que DUDE pour les mots mélangeants de nombreux types de caractères
• DUDE qui permet également une transformation en une passe en UTF-5, il est plus simple à mettre en oeuvre que AMC-ACE-M
• LACE qui nécessite deux passes pour effectuer la transformation. Chaque étape étant simple à mettre en oeuvre.

Zhu Yu, un des premiers à mettre en oeuvre le futur protocole indique que la priorité dans les choix doit porter sur une taille des noms encodés en ASCII la plus petite possible et sur une vitesse de traitement la plus grande possible plutôt que sur la complexité des algorithmes à mettre en oeuvre. Après un test sur la conversion de 100000 noms de domaines choisis aléatoirement en utilisant plusieurs méthodes ACE différentes, il est arrivé à la conclusion que le temps de traitement de l’étape ACE était insignifiante par rapport à celle de la préparation du nom (Nameprep). Cela relativise le choix à faire, même s’il trouve une taille moyenne des noms de domaine codé légèrement plus faible avec AMC-ACE-M qu’avec LACE.

Mark Welter de Walid, un second implémenteur indique également que la mise en oeuvre de Nameprep est bien plus complexe que celle de l’a conversion ACE. Il a cependant testé la mise en oeuvre de plusieurs systèmes. Si les systèmes UTF-5, UTF-6 et RACE n’ont pas posé de problème spécifique de mise en oeuvre, le procédé DUDE nécessiterait d’être mieux défini et d’une façon moins abstraite que dans le document actuel.

Un troisième implémenteur, John Colosi de Verisign, a rencontré des circonstances qui rendent l’algorithme RACE inconsistent. La méthode LACE est plus facile à mettre en oeuvre mais la décompression n’est actuellement pas totalement autonome.

Enfin le JPNIC a également effectué des tests de mise en oeuvre pour voir comment ils répondaient aux besoins japonais. Il trouve que BRACE présente le plus gros taux de compression mais qu’il est difficile à développer alors que LACE et DUDE présente un niveau de compression exploitable et sont faciles à mettre en oeuvre.

La préparation des noms de domaine (Nameprep)

Version actuelle : draft-ietf-idn-nameprep-03.txt. Ce document est considéré comme pratiquement complet.

Pour préparer un nom de serveur on effectue 3 étapes sur lui :

1. La conversion des caractères équivalents (par exemple les minuscules et les majuscules)
2. La normalisation
3. La suppression des caractères interdits

Une table d'équivalence permet en particulier de rapprocher les minuscules et les majuscules selon les règles fournies par la forme KC du rapport technique Unicode [UTR21] (les noms de serveurs doivent être insensibles à la casse). Certaines conversions de caractères ne sont pas décrites dans [TR21] comme certains caractères grecs. Un mécanisme est proposé pour les convertir. Enfin certains caractères sont tout simplement supprimés (mapped out), tel que le trait d'union qui sert au passage à la ligne (soft hyphen).

Normaliser les caractères (les rendre uniques) permet de rassembler les caractères et les combinaisons de caractères équivalents suivant les règles du rapport technique Unicode [UTR15] . Par exemple dans les jeux de caractères coréens, plusieurs combinaisons de caractères sont équivalentes. En Français, il existe les caractères Unicode " e ", " ´ ", recul. La combinaison des trois permet d’arriver au " é ". La normalisation permet de convertir toutes les combinaisons possibles en un seule unique.

Enfin, une vérification est faite pour trouver les caractères interdits. Ceux-ci incluent

• Certains caractères ASCII interdits dans les noms de domaines tels que '?' ou '='
• Toutes les formes d'espaces (il y en a 17 !)
• Les caractères de contrôle tels que le DELETE ou le séparateur de ligne LF ou de paragraphe CR
• Les caractères pour usage privé (par exemple de U+E000 à U+F8FF) et le caractère de remplacement (U+FFFD) qui permet d'afficher dans un espace une information comme quoi il doit y avoir un caractère à cet emplacement mais qu'il ne peut pas être affiché.
• Les emplacements qui sont assignés dans la norme ISO 10646 mais qui ne sont pas des caractères
• Les emplacements délégués
• Les caractères inappropriés pour les textes simples (l'ancre pour les annotations U+FFF9, etc...)
• Les caractères inappropriés dans les noms de domaines (voir les caractères de description dans la partie sur les caractères asiatiques)
• Les propriétés de changement d'affichage (marques pour l'affichage de droite à gauche ou de gauche à droite...)
• Les caractères inappropriés pour la saisie (par exemple le point idéogramique U+3002 qui est souvent utilisé en Asie comme le point U+002E ce qui pourrait poser un problème pour savoir à quelle partie du nom de serveur on accède)

Les jeux de caractères asiatiques

Les particularités des jeux de caractères asiatiques illustrent bien la complexité de prendre en compte les différents aspects culturels au sein des technologies.

Cette partie est très largement inspirée de l'Internet Draft draft-ietf-idn-cjk-00.txt

(Rappel : les caractères Unicode UCS-16 sont notés U+XXXX où 'U' signifie "Unicode" et XXXX est un nombre Hexadécimal de 4 digits (16 bits en tout) représentant la position du caractère dans le jeu.)

Les idéogrammes Han sont utilisés en Chine, Japon, Corée etc. Lorsque le consortium Unicode a commencé à travailler sur un jeu de caractère universel, il a été proposé que les idéogrammes chinois (hanzi), japonais (kanji) et coréen (hanja) soient rassemblés au sein du même espace dans le jeu Unicode. En effet, de nombreux caractères sont communs aux trois langues. C'est ce que l'on a appelé l'unification CJK (China, Japan, Korea). Les idéogrammes han sont codés entre U+3400 et U+9FFF et entre U+F900 et U+FAFF, d'autres idéogrammes han pourront apparaître dans le futur. Ils seront alors placés sur d'autres plans (en dehors des 65536 premières possibilités offertes par le plan 0 du jeu UCS-16).

En fait la forme des idéogrammes a évolué au cours du temps depuis les origines chinoises communes aux trois langues. Ainsi par exemple le mot "villa" est représenté par l'idéogramme {U+838A} 'zhuan' en chinois et par {U+8358} 'sou' en japonais. Leur représentation étant différente, ils ont un code différent dans le jeu Unicode.

Une des grandes difficultés consiste à rassembler les caractères identiques (han folding) pour réduire les ambiguïtés dans les noms de domaine par exemple. Pour les caractères latins, par exemple, les minuscules et les majuscules sont traitées comme identiques. Cela se fait aisément au sein des DNS avec une simple fonction "ET". Pour les idéogrammes, le problème est bien plus complexe et le même ensemble d'idéogrammes peut correspondre à des choses différentes suivant le contexte.

le chinois (Hanzi)

Il existe plusieurs jeux de caractères chinois concurrents, tels que GB2312, GBK ou GB18030 pour la Chine, BIG5 pour Taiwan ou encore BIG5-HK pour Hongkong. Le choix du groupe idn de ne travailler que sur ISO10646-Unicode a un effet simplificateur. Il suffit d’ajouter une étape de conversion depuis les caractères entrés au clavier (par exemple de BIG5 vers Unicode) puis d’appliquer le même mécanisme pour tout le monde pour convertir les caractères vers une forme utilisable avec les serveurs DNS.

Les idéogrammes chinois appelés hanzi sont codés dans les deux espaces {U+5B57- U+6F22} et {U+5B57-U+6C49}. La plupart sont issus de pictogrammes représentant un mot (par exemple l'idéogramme pour montagne {U+5C71} ressemble encore actuellement à 3 sommets de montagne), d'autres sont des compositions à partir d'autres idéogrammes (le foyer est composé de l'idéogramme de la femme et de celui de la maison) et d'autres encore sont des idéogrammes donnant des informations de phonétique (le mot "maman" est composé de l'idéogramme de la femme et de celui du cheval qui se prononce comme le mot "maman" en chinois).

Dans les années 1950, après l'établissement de la république populaire de Chine, les idéogrammes ont subi une réforme majeure. Un comité a travaillé sur une simplification des idéogrammes. Le chinois simplifié (SC) est utilisé en Chine et à Singapour alors que le chinois traditionnel (TC) est toujours celui utilisé à Taiwan, Hong Kong, Macao et la plus part des chinois à l'étranger. La dernière liste complète officielle des caractères simplifiés publiée en 1986 compte 2244 idéogrammes en chinois simplifié.

Deux idéogrammes en chinois traditionnel peuvent être représentés par le même idéogramme en chinois simplifié. La transformation d'idéogrammes traditionnels en idéogrammes simplifiés est assez simple (un document informel d'Unicode propose la traduction pour 2145 caractères traditionnels ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt, il est encore incomplet et contient plusieurs erreurs). A l'inverse, la conversion de caractères simplifiés vers des caractères traditionnels est beaucoup plus complexe et nécessite une analyse sémantique de la phrase.

Dans les noms de domaines internationalisés, le problème est de vérifier les équivalences. De ce point de vue, une simple traduction des caractères traditionnels vers les caractères simplifiés semble suffisante.

Les caractères traditionnels et les caractères simplifiés ne sont pas utilisés conjointement dans les mots. Mais les choses se gâtent avec les noms propres. En Chine et à Singapour où les caractères traditionnels sont utilisés, les deux types de caractères sont parfois utilisés simultanément pour des raisons esthétiques. Certains créent même des idéogrammes pour leur nom en ajoutant ou retirant des radicaux à des idéogrammes composés...

La question est de savoir s’il faut considérer comme différents les mêmes noms de domaine écrit en chinois simplifié et en chinois traditionnel (comme c’est le cas par exemple pour les orthographes anglaises et américaines ou " center " et " centre " sont deux mots considérés différents), ou si au contraire il faut considérer qu’il s’agit de deux façons différentes d’écrire le même nom (comme c’est le cas dans les langues latines pour l’utilisation des minuscules et des majuscules).

Le coréen (Haja et Hangul)

La langue coréenne (appelée hanmal) s'écrit avec des idéogrammes issus du chinois ("hanja") codés dans deux espaces Unicode { U+5B57-U+6F22} et {U+C790-U+D55C}. Ils ont été très utilisés jusqu'à récemment où les caractères "hangul" {U+D55C-U+AE00} sont devenus plus populaires.

Les caractères "hanguls" sont un alphabet syllabique basé sur la prononciation. Ils ont été définis au 15^ème siècle par King Sejong un expert linguiste. Chaque syllabe "hangul" peut être décomposée en caractères "jamo" {U+5B57-U+6BCD} et {U+BAA8-U+C790} qui représentent chacun un son.

Tous les idéogrammes hanja peuvent être représentés aussi sous forme de syllabes hangul qui elles-mêmes peuvent être redécomposées en jamo. Les choses deviennent plus complexes lorsque l'on sait que certains idéogrammes hanja se prononcent différemment suivant des critères d'orthographe ou de position dans le mot impliquant une décomposition en hangul différente. Et bien sûr, la conversion de syllabes phonétiques hangul en idéogrammes hanja est impossible sans prendre en compte la sémantique.

Les coréens ont également défini leurs propres idéogrammes appelés "gugja" {U+56FD-U+5B57} et {U+AD6D-U+C790}

Le japonais (Kanji, Hiragana, Katakana)

Les japonais ont adopté les idéogrammes issus du chinois et du coréen depuis le 5^ème siècle. Ils sont appelés "Kanji" {U+5B57-U+6F22}. Ils utilisent également deux alphabets syllabiques qui correspondent à une prononciation : Le "Hiragana" pour les mots japonais et le "Katakana" pour les mots venant de l'étranger. Les deux sont issus de caractères Kanji ayant la même prononciation.

Le Katakana est un miroir du Hiragana et y ajoute plusieurs caractères pour prendre en compte les sons des mots étrangers. En plus de son utilisation pour la représentation des mots étrangers, le Katakana sert aussi à mettre en valeur un mot ou une phrase et à représenter les onomatopées.

Le Kanji est utilisé pour les noms et les verbes car leur écriture en Hiragana ou Katakana rendrait les phrases très longues. Chaque idéogramme Kanji peut être décomposé en une ou plusieurs syllabes Hiragana. Mais les idéogrammes Kanji peuvent avoir une prononciation différente (et donc une décomposition en Hiragana différente) suivant leur place dans la phrase et comment ils sont utilisés. A l'inverse deux idéogrammes Kanji différents peuvent avoir la même signification et la même prononciation (et donc la même décomposition en Hiragana). Le mot rivière "Hawa" peut être représenté par l'idéogramme U+5DDD ou U+6CB3. Les deux se prononcent de la même manière, la seule différence est dans la taille de la rivière (le deuxième idéogramme étant une rivière plus large).

Les caractères Kanji eux-mêmes ont également évolué et les formes se sont simplifiées (d'une façon différente du chinois simplifié). Les caractères traditionnels sont utilisés pour les textes historiques et parfois pour les noms propres tels que les noms de personnes et les noms de société. Il n'est cependant pas nécessaire d'établir une correspondance entre les Kanji traditionnels et les Kanji actuels.

Les japonais ont également inventé leurs propres idéogrammes appelés "Kokuji" {U+56FD-U+5B57}. Ils ont été définis suivant les règles de ligature Han pour assembler différents idéogrammes.

Vietnamien

Les vietnamiens ont adopté les idéogrammes chinois qu'ils appellent "chu han" et ont également créé leurs propres idéogrammes (les "chu nom"). Mais ils sont maintenant remplacés par les caractères "quoc ngu" issus de l'alphabet latin.

S'il est important d'avoir les caractères Vietnamiens dans les jeux de caractères ISO10646-Unicode pour pouvoir conserver de façon numérique les textes anciens, il n'est pas nécessaire de les prendre en compte dans les noms de domaines par exemple. Les caractères alphabétiques "quoc ngu" ne posent eux pas de problèmes particuliers.

Trouver les équivalences pour garantir l'unicité des noms de domaine

Des parties précédentes, il résulte que le problème des équivalences est complexe pour les 3 langues basées sur des idéogrammes. Il n'est pas possible d'assimiler simplement ces équivalences à la conversion minuscules-majuscules existant en alphabet latin ou caractères isolés, au début, au milieu ou en fin de mot existant en arabe.

Unicode propose un modèle tridimensionnel pour l'unification des idéogrammes.

• Un premier axe (X) permet de relier les caractères ayant le même sens (sémantique)
• Un deuxième axe (Y) relie les idéogrammes en fonction de leur forme abstraite
• Un troisième axe (Z) relie les idéogrammes en fonction de leur codage

Lorsque deux idéogrammes ont le même sens mais ont des codes différents dans le jeu Unicode, ont les appelle des idéogrammes zVariants.

Par ailleurs, Unicode introduit les descriptions idéogrammiques qui permettent de construire des idéogrammes à partir d'autres idéogrammes et de radicaux (des formes élémentaires). Cette méthode n'est pas déterministe et le même idéogramme peut être représenté par différentes séquences.

Pour permettre l'utilisation d'idéogrammes dans les noms de domaines, il faut s'assurer de l'unicité du nom et donc prendre en compte les équivalences. Comme nous l'avons vu certaines équivalences sont impossibles à établir simplement.

D'autres seraient souhaitables :

• Idéogrammes chinois traditionnels et idéogrammes chinois simplifiés
• Idéogrammes coréens hanja en caractères hangeul
• Idéogrammes japonais Kanji en caractères Hiragana
• Caractères Hiragana en Katakana

Certaines de ces combinaisons ne sont pas faisables dans les deux sens sans prendre en compte la sémantique, ce qui rend la conversion extrêmement complexe. Heureusement, pour les problèmes d'équivalence, il suffit de convertir dans un seul sens et de comparer les résultats. Actuellement, il n'est pas clair quelles sont les vérifications qui pourront être faites et celles qui seront effectivement mises en oeuvre.

La mise en oeuvre de ces mécanismes dans les clients de DNS ou par les " user agents " des messageries nécessiteraient des tables de correspondance sur l'axe X des caractères Unicode. De telles tables sont au-delà de la portée des petits appareils (pda, téléphones...)

Une solution serait que la correspondance soit faite par les services d'enregistrement de nom de domaines pour éviter que deux noms de domaines, une fois transcodés ne soient les mêmes.

Futurs travaux

Les prochaines étapes pour le groupe idn de l’IETF seront :

• D’ajouter une section " intended scope " dans le document sur les besoins pour y mettre les besoins utilisateurs auxquels il répond et ainsi mieux les séparer des besoins techniques
• De terminer le travail des 3 équipes de proposition pour passer à la phase de standardisation active
• De voir avec la société Walid pour régler le problème de droit de propriété sur le protocole prévu (voir chapitre sur le protocole)
• Si ce problème est réglé, de mettre le document sur le protocole dans le processus de standardisation en RFC en y incluant les références par rapport aux choix faits sur les ACE et sur Nameprep

Lorsque le groupe idn de l'IETF aura produit un protocole accepté, il restera encore plusieurs points à traiter :

Si vous n'avez pas par exemple un 'é' accessible facilement sur votre clavier, comment ferez vous pour envoyer un email à une personne dont le nom de domaine contient ce caractère (on pourrait utiliser la représentation ACE mais cela n'est pas adapté à l'utilisateur lambda).

Il faudra également étudier les autres identifieurs tels que la partie gauche de l'email

Il faudra enfin rechercher une solution plus efficace pour le long terme.

Références

Ce document a été préparé à partir de

• La présentation "l'anglais est-il le langage de l'Internet ?" par YJ Park, deputy CEO de MINC (Multilingual Internet Name Consortium) le 3 mars 2001 à Sofia (Bulgarie)
  http://www.minc.org
• La présentation "Présentation des travaux de l'IETF sur les noms de domaines internationaux" de Marc Blanchet, co-président du groupe de travail IDN (Internationalized Domain Names) à l'IETF, le 1^er mars 2001 à Tokyo (Japon)
  www.viagenie.qc.ca
• La session du groupe de travail "Internationalized Domain Names" lors de la 50^ème réunion de l'IETF (Internet Ingeneering Task Force) du 19 au 23 mars 2001 à Minneapolis
  http://www.ietf.org/html.charters/idn-charter.html
  les travaux du groupe sont accessibles sur http://www.i-d-n.net/
• Et de plusieurs Internet-drafts. Ces documents ayant une durée de vie limitée (au maximum 6 mois) seul leur nom est indiqué ici. Ceux qui sont encore disponibles peuvent être trouvés dans le répertoire http://www.ietf.org/internet-drafts/1id-abstracts.txt