Nom de domaine internationalisé - Internationalized domain name

Ne doit pas être confondu avec Indonésie .
Exemple d'IDN grec avec nom de domaine en alphabet non latin : ουτοπία.δπθ.gr

Un nom de domaine internationalisé ( IDN ) est un nom de domaine Internet qui contient au moins une étiquette qui s'affiche dans les applications logicielles , en tout ou en partie , dans une écriture ou un alphabet non latin , comme l' arabe , le chinois , le cyrillique , le devanagari , Caractères basés sur l' hébreu ou l' alphabet latin avec signes diacritiques ou ligatures , comme le français . Ces systèmes d'écriture sont codés par les ordinateurs en Unicode multi-octets . Les noms de domaine internationalisés sont stockés dans le système de noms de domaine (DNS) sous forme de chaînes ASCII à l' aide de la transcription Punycode .

Le DNS, qui effectue un service de recherche pour traduire des noms conviviaux en adresses réseau pour localiser les ressources Internet, est limité en pratique à l'utilisation de caractères ASCII, une limitation pratique qui a initialement fixé la norme pour les noms de domaine acceptables. L'internationalisation des noms de domaine est une solution technique pour traduire les noms écrits dans des scripts natifs en une représentation textuelle ASCII compatible avec le DNS. Les noms de domaine internationalisés ne peuvent être utilisés qu'avec des applications spécialement conçues pour une telle utilisation ; ils ne nécessitent aucun changement dans l'infrastructure d'Internet.

IDN a été initialement proposé en décembre 1996 par Martin Dürst et mis en œuvre en 1998 par Tan Juay Kwang et Leong Kok Yong sous la direction de Tan Tin Wee. Après de nombreux débats et de nombreuses propositions concurrentes, un système appelé Internationalizing Domain Names in Applications (IDNA) a été adopté comme standard et a été mis en œuvre dans plusieurs domaines de premier niveau .

Dans IDNA, le terme nom de domaine internationalisé désigne spécifiquement tout nom de domaine composé uniquement d'étiquettes auxquelles l' algorithme IDNA ToASCII (voir ci-dessous) peut être appliqué avec succès. En mars 2008, l' IETF a formé un nouveau groupe de travail IDN pour mettre à jour le protocole IDNA actuel. En avril 2008, l' UN-ESCWA, en collaboration avec le Public Interest Registry (PIR) et Afilias, a lancé le groupe de travail sur l'écriture arabe dans les IDN (ASIWG), qui comprenait des experts en DNS, des opérateurs de ccTLD , des entreprises, des universitaires, ainsi que des membres d'organisations régionales et organisations internationales. Présidé par Ram Mohan d'Afilias, l'ASIWG vise à développer une table IDN unifiée pour l'écriture arabe et a constitué un exemple de collaboration communautaire qui aide l'expertise locale et régionale à s'engager dans l'élaboration de politiques mondiales ainsi que dans la normalisation technique.

En octobre 2009, l' Internet Corporation for Assigned Names and Numbers (ICANN) a approuvé la création de domaines de premier niveau de code de pays internationalisés (IDN ccTLD) sur Internet qui utilisent la norme IDNA pour les scripts en langue maternelle. En mai 2010, les premiers IDN ccTLD ont été installés dans la zone racine du DNS .

Internationaliser les noms de domaine dans les applications

L'internationalisation des noms de domaine dans les applications (IDNA) est un mécanisme défini en 2003 pour le traitement des noms de domaine internationalisés contenant des caractères non ASCII .

Bien que le système de noms de domaine prenne en charge les caractères non ASCII, les applications telles que les e-mails et les navigateurs Web restreignent les caractères pouvant être utilisés comme noms de domaine à des fins telles qu'un nom d'hôte . À proprement parler, ce sont les protocoles réseau utilisés par ces applications qui ont des restrictions sur les caractères pouvant être utilisés dans les noms de domaine, et non les applications qui ont ces limitations ou le DNS lui-même. Pour conserver la rétrocompatibilité avec la base installée, le groupe de travail IETF IDNA a décidé que les noms de domaine internationalisés devraient être convertis en une forme ASCII appropriée qui pourrait être gérée par les navigateurs Web et autres applications utilisateur. IDNA spécifie comment cette conversion entre les noms écrits en caractères non ASCII et leur représentation basée sur ASCII est effectuée.

Une application compatible IDNA est capable de convertir entre les représentations internationalisées et ASCII d'un nom de domaine. Il utilise la forme ASCII pour les recherches DNS, mais peut présenter la forme internationalisée aux utilisateurs qui préfèrent probablement lire et écrire des noms de domaine dans des scripts non ASCII tels que l'arabe ou l'hiragana. Les applications qui ne prennent pas en charge IDNA ne seront pas en mesure de gérer les noms de domaine avec des caractères non-ASCII, mais pourront toujours accéder à ces domaines si on leur donne l'équivalent ASCII (généralement plutôt cryptique).

L'ICANN a publié des directives pour l'utilisation de l'IDNA en juin 2003, et il était déjà possible d'enregistrer des domaines .jp en utilisant ce système en juillet 2003 et des domaines .info en mars 2004. Plusieurs autres registres de domaines de premier niveau ont commencé à accepter les enregistrements en 2004 et 2005. Les directives IDN ont été créées pour la première fois en juin 2003 et ont été mises à jour pour répondre aux problèmes d' hameçonnage en novembre 2005. Un groupe de travail de l'ICANN axé sur les noms de domaine de code de pays au plus haut niveau a été formé en novembre 2007 et promu conjointement par le code de pays prenant en charge l'organisation et le Comité consultatif gouvernemental. De plus, l'ICANN soutient le groupe de pilotage d' acceptation universelle dirigé par la communauté , qui cherche à promouvoir la convivialité des IDN et d'autres nouveaux gTLDS dans toutes les applications, appareils et systèmes.

Mozilla 1.4, Netscape 7.1, Opera 7.11 ont été parmi les premières applications à prendre en charge IDNA. Un plug-in de navigateur est disponible pour Internet Explorer 6 afin de prendre en charge les IDN. Internet Explorer 7.0 et les API d'URL de Windows Vista fournissent une prise en charge native des IDN.

ToASCII et ToUnicode

Les conversions entre les formes ASCII et non-ASCII d'un nom de domaine sont effectuées par des algorithmes appelés ToASCII et ToUnicode. Ces algorithmes ne sont pas appliqués au nom de domaine dans son ensemble, mais plutôt à des étiquettes individuelles. Par exemple, si le nom de domaine est www.exemple.com, les libellés sont www , exemple et com . ToASCII ou ToUnicode est appliqué à chacun de ces trois séparément.

Les détails de ces deux algorithmes sont complexes et sont spécifiés dans la RFC 3490. Ce qui suit donne un aperçu de leur fonction.

ToASCII laisse inchangée toute étiquette ASCII, mais échouera si l'étiquette n'est pas adaptée au système de noms de domaine. Si une étiquette contient au moins un caractère non ASCII, ToASCII appliquera l' algorithme Nameprep , qui convertit l'étiquette en minuscules et effectue une autre normalisation, puis traduira le résultat en ASCII à l'aide de Punycode avant d'ajouter la chaîne de quatre caractères " xn -- ". Cette chaîne de quatre caractères est appelée préfixe de codage compatible ASCII ( ACE ) et est utilisée pour distinguer les étiquettes codées Punycode des étiquettes ASCII ordinaires. L'algorithme ToASCII peut échouer de plusieurs manières ; par exemple, la chaîne finale peut dépasser la limite de 63 caractères d'une étiquette DNS. Une étiquette pour laquelle ToASCII échoue ne peut pas être utilisée dans un nom de domaine internationalisé.

La fonction ToUnicode inverse l'action de ToASCII, en supprimant le préfixe ACE et en appliquant l'algorithme de décodage Punycode. Il n'inverse pas le traitement Nameprep, car il s'agit simplement d'une normalisation et est par nature irréversible. Contrairement à ToASCII, ToUnicode réussit toujours, car il renvoie simplement la chaîne d'origine si le décodage échoue. En particulier, cela signifie que ToUnicode n'a aucun effet sur une chaîne qui ne commence pas par le préfixe ACE.

Exemple d'encodage IDNA

Le codage IDNA peut être illustré en utilisant l'exemple de domaine Bücher.example. ( allemand : Bücher , lit.  'livres'.) Ce nom de domaine a deux étiquettes, Bücher et example . La deuxième étiquette est en ASCII pur et reste inchangée. La première étiquette est traitée par Nameprep pour donner bücher, puis convertie en Punycode pour donner bcher-kva. Il est alors préfixé par xn--pour produire xn--bcher-kva. Le nom résultant adapté à une utilisation dans les enregistrements et les requêtes DNS est donc " xn--bcher-kva.example".

Groupe de travail IDN sur l'écriture arabe (ASIWG)

Alors que la région arabe représente 5 % de la population mondiale, elle ne représente que 2,6 % de l'utilisation mondiale d'Internet. De plus, le pourcentage d'utilisateurs d'Internet parmi la population du monde arabe n'est que de 11 %, contre un taux mondial de 21,9 %. Cependant, l'utilisation d'Internet dans la région a augmenté de 1 426 % entre les années 2000 et 2008, ce qui représente une forte augmentation, en particulier par rapport au taux de croissance mondial moyen de 305,5 % sur la même période. Il est donc raisonnable de déduire que la croissance de l'utilisation aurait pu être encore plus importante si DNS était disponible en caractères arabes. L'introduction des IDN offre de nombreuses opportunités et avantages potentiels pour les internautes arabes en leur permettant d'établir des domaines dans leurs langues et alphabets natifs, et de créer toute une gamme de services et d'applications localisées en plus de ces domaines.

Le président de l'ASIWG, Ram Mohan, a présenté les arguments en faveur du développement d'un Internet multilingue lors du Forum sur la gouvernance de l'Internet à Hyderabad, en Inde (3-6 décembre 2008).

Implémentation de domaine de premier niveau

En 2009, l'ICANN a décidé de mettre en œuvre une nouvelle classe de domaines de premier niveau, attribuables à des pays et à des régions indépendantes, similaire aux règles pour les domaines de premier niveau de code de pays . Cependant, les noms de domaine peuvent être n'importe quelle chaîne de caractères, de symboles ou de glyphes dans l'alphabet ou l'écriture non latin spécifique à la langue de la langue du demandeur, dans le cadre de certaines directives pour assurer une unicité visuelle suffisante.

Le processus d'installation des domaines de code de pays IDN a commencé par une longue période de test dans un ensemble de sous-domaines du domaine de premier niveau de test . Onze domaines utilisaient des écritures ou des alphabets natifs, tels que δοκιμή, qui signifie test en grec.

Ces efforts ont abouti à la création des premiers domaines de premier niveau de code de pays internationalisés (IDN ccTLD) pour une utilisation en production en 2010.

Dans le système de noms de domaine, ces domaines utilisent une représentation ASCII constituée du préfixe « xn-- » suivi de la traduction Punycode de la représentation Unicode de l'alphabet ou des glyphes de script spécifiques à la langue. Par exemple, le nom cyrillique de l'IDN ccTLD russe est "рф". Dans la représentation Punycode, il s'agit de " p1ai ", et son nom DNS est " xn--p1ai ".

Registres non-IDNA ou non-ICANN qui prennent en charge les noms de domaine non-ASCII

Il existe d'autres registres qui prennent en charge les noms de domaine non ASCII. La société ThaiURL.com en Thaïlande prend en charge les enregistrements .com via son propre encodage IDN, ThaiURL . Cependant, comme la plupart des navigateurs modernes ne reconnaissent que les IDN IDNA/punycode, les domaines codés ThaiURL doivent être saisis ou liés sous leur forme codée, et ils seront ainsi affichés dans la barre d'adresse. Cela limite leur utilité ; cependant, ce sont toujours des domaines valides et universellement accessibles.

Plusieurs registres prennent en charge les caractères emoji codés en petits caractères en tant que domaines emoji .

Problèmes d'usurpation d'identité ASCII

Article principal: attaque d'homographe IDN

L'utilisation d'Unicode dans les noms de domaine rend potentiellement plus facile l' usurpation de sites Web, car la représentation visuelle d'une chaîne IDN dans un navigateur Web peut faire en sorte qu'un site frauduleux semble indiscernable du site légitime falsifié, selon la police utilisée. Par exemple, le caractère Unicode U+0430, lettre minuscule cyrillique a , peut sembler identique au caractère Unicode U+0061, lettre minuscule latine a , utilisé en anglais. Comme exemple concret, en utilisant les lettres cyrilliques а , е ("Ie"/"Ye", U+0435, semblant essentiellement identiques aux lettres latines a , e ), biélorusse-ukrainien і (U+0456, essentiellement identique à la lettre latine i ), р ("Er", U+0440, essentiellement identique à la lettre latine p ), l'URL wіkіреdіа.org est formée (" xn--wkd-8cdx9d7hbd.org " sous forme codée), qui est pratiquement impossible à distinguer du visuel représentation du wikipedia.org légitime (éventuellement en fonction des polices).

Domaines de premier niveau acceptant l'enregistrement IDN

De nombreux domaines de premier niveau ont commencé à accepter les enregistrements de noms de domaine internationalisés au deuxième niveau ou à un niveau inférieur. Afilias (.INFO) a proposé les premiers enregistrements gTLD IDN de deuxième niveau en 2004 en langue allemande.

DotAsia, le bureau d'enregistrement du TLD Asia , a mené une période de lever de soleil de 70 jours à compter du 11 mai 2011 pour les enregistrements de domaine de deuxième niveau dans les scripts chinois, japonais et coréen .

Chronologie

  • 1996-12 : Internet Draft original de Martin Dürst proposant l'UTF5 (le premier exemple de ce que l'on appelle aujourd'hui un codage compatible ASCII (ACE)) – UTF-5 a été défini pour la première fois à l'Université de Zürich
  • 1998-03 : Early Research on IDN à l'Université nationale de Singapour (NUS), Centre for Internet Research (anciennement Internet Research and Development Unit - IRDU) dirigé par Tan Tin Wee (TWTan) (IDN Project team - Tan Juay Kwang et Leong Kok Yong) et par la suite continué sous une équipe à Bioinformatrix Pte. Ltd. (BIX Pte. Ltd.) – une entreprise dérivée de la NUS dirigée par le professeur S. Subbiah.
  • 1998-06 : Le système de noms de domaine en langue coréenne est développé par Kang, Hee-Seung au KAIST (Korea Advanced Institute of Science and Technology)
  • 1998-07 : Conférence INET'98 de Genève avec une discussion du BoF sur l'Assemblée générale et la réunion du groupe de travail iDNS et APNG.
  • 1998-07 : Groupe de travail en réseau Asie-Pacifique (APNG, qui existe toujours et distinct d'un rassemblement connu sous le nom d'APSTAR) Groupe de travail iDNS formé.
  • 1998-10 : James Seng , ancien étudiant de Tan Tin Wee à Sheares Hall, NUS, et étudiant chercheur à Technet et IRDU, Computer Centre, NUS, a été recruté par le PDG S. Subbiah pour diriger le développement d'IDN à BIX Pte. Ltd.
  • 1999-02 : Lancement du banc d'essai iDNS par BIX Pte. Ltd. sous les auspices de APNG avec la participation de CNNIC , JPNIC , KRNIC, TWNIC, THNIC, HKNIC et SGNIC dirigé par James Seng
  • 1999-02 : Présentation du rapport sur les IDN à la réunion conjointe APNG-APTLD, à APRICOT'99
  • 1999-03 : Approbation du rapport IDN lors de l'Assemblée générale de l'APNG le 1er mars 1999.
  • 1999-06 : Demande de subvention de l'APNG conjointement avec le Centre for Internet Research (CIR), Université nationale de Singapour, au Centre de recherches pour le développement international (CRDI), une organisation internationale financée par le gouvernement canadien pour travailler sur les IDN pour IPv6. Ce projet APNG a été financé dans le cadre de la subvention de R et D panasiatique administrée au nom du CRDI par le Comité canadien d'hygiène et de sécurité au travail (CCHST). Chercheur principal : Tan Tin Wee de l'Université nationale de Singapour.
  • 1999-07 Tout, Walid R. (WALID Inc.) Dépôt de la demande de brevet IDNA numéro US1999000358043 Méthode et système d'internationalisation des noms de domaine. Publié 2001-01-30
  • 1999-07 : Internet Draft sur UTF5 par James Seng, Martin Dürst et Tan Tin Wee. Renouvelé en 2000.
  • 1999-08 : L'APTLD et l'APNG forment un groupe de travail pour examiner les problèmes d'IDN présidé par Kilnam Chon.
  • 1999-10 : BIX Sdt. Ltd. et l'Université nationale de Singapour, ainsi que les investisseurs de New York Venture Capital, General Atlantic Partners , ont filé l'effort IDN dans 2 nouvelles sociétés singapouriennes - i-DNS.net International Inc. et i-Email.net Pte. Ltd. qui a créé la première implémentation commerciale d'une solution IDN pour les noms de domaine et les adresses e-mail IDN respectivement.
  • 1999-11 : IETF IDN Birds-of-Feather à Washington a été lancé par i-DNS.net à la demande des responsables de l'IETF.
  • 1999-12 : i-DNS.net InternationalPte. Ltd. a lancé le premier IDN commercial. C'était à Taïwan et en caractères chinois sous le TLD IDN de premier niveau ".gongsi" (ce qui signifie vaguement ".com") avec l'approbation du ministre des Communications de Taïwan et de certains grands FAI taïwanais avec des rapports de plus de 200 000 noms vendus dans une semaine à Taïwan, Hong Kong, Singapour, Malaisie, Chine , Australie et USA.
  • Fin 1999 : Kilnam Chon lance un groupe de travail sur l'IDNS qui a conduit à la formation du MINC, le Consortium des noms Internet multilingues.
  • 2000-01 : Groupe de travail IETF IDN formé, présidé par James Seng et Marc Blanchet
  • 2000-01 : Le deuxième lancement commercial d'IDN était celui des IDN TLD en langue tamoule, correspondant à .com, .net, .org et .edu. Ceux-ci ont été lancés en Inde avec le soutien du ministère des TI par i-DNS.net International.
  • 2000-02 : Proposition BoF du Consortium pour les noms Internet multilingues (MINC) à l'IETF Adelaide.
  • 2000-03 : ABRICOT 2000 Session DNS multilingue.
  • 2000-04 : WALID Inc. (avec la demande de brevet IDNA en instance 6182148) a commencé l'enregistrement et la résolution de noms de domaine multilingues.
  • 2000-05 : GT Tests d'interopérabilité, réunion du MINC. San Francisco, présidé par Bill Manning et Y. Yoneya 12 mai 2000.
  • 2000-06 : Lancement inaugural du Multilingual Internet Names Consortium (MINC) à Séoul pour piloter le déploiement collaboratif d'IDN à partir de l'Asie-Pacifique.
  • 2000-07 : Joint Engineering TaskForce (JET) initié à Yokohama pour étudier les problèmes techniques dirigé par JPNIC (K.Konishi) et TWNIC (Kenny Huang)
  • 2000-07 : Formation officielle du consortium de noms de domaine chinois CDNC pour résoudre les problèmes liés aux noms de domaine Han Character et les déployer , fondé par CNNIC , TWNIC , HKNIC et MONIC en mai 2000.
  • 2001-03 : Groupe de travail IDN du Conseil d'administration de l' ICANN formé
  • 2001-07 : Japanese Domain Name Association : Cérémonie de lancement du JDNA (13 juillet 2001) à Tokyo, Japon.
  • 2001-07 : Urdu Internet Names System (28 juillet 2001) à Islamabad, Pakistan, organisé conjointement par SDNP et MINC.
  • 2001-07 : Présentation sur IDN à la réunion du comité du Computer Science and Telecommunications Board, National Academies USA (11-13 JUILLET 2001) à la University of California School of Information Management and Systems, Berkeley, CA.
  • 2001-08 : Présentation et sensibilisation du MINC à la conférence annuelle Asia Pacific Advanced Network, Penang, Malaisie, 20 août 2001
  • 2001-10 : Réunion conjointe MINC-CDNC à Pékin 18-20 octobre 2001
  • 2001-11 : formation du comité IDN de l' ICANN , Ram Mohan (Afilias) nommé membre fondateur
  • 2001-12 : Symposium conjoint UIT-OMPI sur les noms de domaine multilingues organisé en association avec le MINC, 6-7 décembre 2001, Centre international de conférences, Genève.
  • 2003-01 : Groupe de travail sur les directives IDN de l'ICANN formé avec des membres des principaux registres gTLD et ccTLD.
  • 2003-01 : Implémentation gratuite de StringPrep, Punycode et IDNA dans GNU Libidn.
  • 2003-03 : Publication des RFC 3454, RFC 3490, RFC 3491 et RFC 3492
  • 2003-06 : Publication des directives IDN de l'ICANN pour les registres. Adopté par les registres .cn, .info, .jp, .org et .tw.
  • 2004-05 : Publication de la RFC 3743, Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese , Japanese and Korean
  • 2005-03 : Première réunion de la Commission d'études 17 de l'UIT-T sur les noms de domaine internationalisés.
  • 2005-05 : .IN ccTLD (Inde) crée un groupe de travail d'experts IDN pour créer des solutions pour 22 langues officielles. Ram Mohan nommé responsable de la mise en œuvre technique. C-DAC nommé expert linguistique.
  • 2006-04 : La réunion de la Commission d'études 17 de l'UIT en Corée a donné son approbation finale à la Question sur les noms de domaine internationalisés.
  • 2006-06 : Atelier sur l'IDN lors de la réunion de l'ICANN à Marrakech, Maroc
  • 2006-11 : Groupe de travail ICANN GNSO IDN créé pour discuter des implications politiques des TLD IDN. Ram Mohan élu président du groupe de travail IDN.
  • 2006-12 : la réunion de l'ICANN à São Paulo discute de l'état des tests en laboratoire des IDN au sein de la racine.
  • 2007-01 : Travail sur les tables de variantes tamoul et malayalam achevé par le C-DAC indien et Afilias
  • 2007-03 : le groupe de travail IDN GNSO de l'ICANN termine ses travaux, Ram Mohan présente un rapport à la réunion de l'ICANN à Lisbonne.
  • 2007-10 : Onze domaines de premier niveau IDNA ont été ajoutés aux serveurs de noms racine afin d'évaluer l'utilisation d'IDNA au niveau supérieur du DNS.
  • 2008-01 : ICANN : Évaluations réussies des TLD IDN .test
  • 2008-02 : Atelier IDN : IDN dans les langues et les scripts indiens ICANN, DIT, Afilias, C-DAC, NIXI dirigent
  • 2008-04 : le groupe de travail IETF IDNAbis présidé par Vint Cerf poursuit le travail de mise à jour de l'IDNA
  • 2008-04 : Groupe de travail sur les IDN en écriture arabe (ASIWG) fondé par Ram Mohan (Afilias) et Alexa Raad (PIR) à Dubaï.
  • 2008-06 : le conseil d'administration de l'ICANN vote pour développer une proposition finale de mise en œuvre accélérée pour un nombre limité d'IDN ccTLDS.
  • 2008-06 : L'adhésion au groupe de travail sur les IDN en caractères arabes (ASIWG) s'étend à l'Égypte, l'Iran, le Koweït, le Pakistan, l'Arabie saoudite, la Syrie, les Émirats arabes unis, la Malaisie, l'UN ESCWA, l'APTLD, l'ISOC Afrique et les experts invités Michael Everson et John Klensin
  • 2008-10 : L'ICANN cherche à s'intéresser au processus accéléré des IDN ccTLD
  • 2009-09 : l'ICANN met la proposition d'IDN ccTLD à l'ordre du jour de la réunion de Séoul en octobre 2009
  • 2009-10 : l'ICANN approuve l'enregistrement des noms IDN dans la racine du DNS via le processus IDN ccTLD Fast-Track lors de sa réunion à Séoul, du 26 au 30 octobre 2009.
  • 2010-01 : l'ICANN annonce que l'Égypte, la Fédération de Russie, l'Arabie saoudite et les Émirats arabes unis ont été les premiers pays à avoir réussi l'évaluation accélérée des chaînes dans le cadre du processus de candidature de domaine IDN ccTLD.
  • 2010-05 : Les premières implémentations sont mises en ligne. Il s'agit des ccTLD en alphabet arabe pour l'Égypte, l'Arabie saoudite et les Émirats arabes unis.
  • 2010-08 : L' IETF publie les spécifications « IDNA2008 » mises à jour en tant que RFC 5890 – 5894
  • 2010-12 : Groupe de travail sur les variantes d'IDN du Conseil d'administration de l'ICANN formé pour superviser et suivre le projet sur les problèmes de variantes d'IDN. Les membres du groupe de travail sont Ram Mohan (président), Jonne Soininen, Suzanne Woolf et Kuo-Wei Wu.
  • 2012-02 : Le courrier électronique international a été standardisé, en utilisant l'IDN.

Voir également

Les références

Liens externes