Skip to main content

Publication de recommandations pour gérer les variantes des noms de domaine de premier niveau internationalisés

Cette page est disponible en:

Los Angeles, le 5 février 2019. La Société pour l'attribution des noms de domaine et des numéros sur Internet (lCANN) a annoncé aujourd'hui la publication d'un recueil de 6 documents contenant des recommandations pour gérer les variantes des noms de domaine de premier niveau internationalisés (TLDs). Ces recommandations ont été élaborées par l'organisation ICANN à partir des retours de la communauté reçus pendant la période de consultation publique.

  1. Mise en œuvre des variantes TLD IDN – Résumé analytique [PDF, 70 KB].
  2. Mise en œuvre des variantes TLD IDN – Motivation, hypothèses et cadre [PDF, 391 KB].
  3. Mise en œuvre des variantes TLD IDN – Recommandations et analyses [PDF, 382 KB].
  4. Mise en œuvre des variantes TLD IDN – Fondements des RZ-LGR [PDF, 497 KB].
  5. Mise en œuvre des variantes TLD IDN – Risques et mesures d'atténuation [PDF, 230 KB].
  6. Mise en œuvre des variantes TLD IDN – Annexes (A : définitions, B : utilisation de ROID, C : limitation des variantes de TLD allouées) [PDF, 530 KB].

Même si la communauté Internet avait souvent exprimé le besoin d'utiliser des variantes des TLD IDN, aucune procédure ou cahier de charges technique n'avait été mis en place à ce propos. Le 25 septembre 2010, le Conseil d'administration de l'ICANN a décidé qu' « aucune variante de gTLD ne serait déléguée (...) jusqu'à l'établissement de solutions appropriées pour la gestion de variantes ». L'analyse menée par l'organisation ICANN et la communauté des problèmes liés aux alphabets arabe [PDF, 1.06 MB], chinois [PDF, 2.86 MB], cyrillique [PDF, 1 MB], dévanagari [PDF, 461 KB], grec [PDF, 354 KB] et latin [PDF, 425 KB] en 2011, incluse dans le Rapport thématique intégré [PDF, 2.14 MB] (2012), a permis d'identifier deux difficultés : (i) il n'y a pas de définition acceptée des variantes de TLD ; et (ii) il n'y a pas de mécanisme de « gestion de variantes » pour les TLD.

Pour le premier problème, la procédure de génération d'étiquettes pour la zone racine (RZ-LGR) [PDF, 1,39 MB] a été développée grâce au soutien de la communauté, et sa mise en œuvre a été adoptée par le Conseil d'administration de l'ICANN le 11 avril 2013. Après la mise en application de la procédure, des RZ-LGR ont été développées pour six écritures. D'autres écritures seront ajoutées à mesure que les propositions correspondantes seront mises au point par leurs communautés respectives. Il s'agit d'un mécanisme transparent et prévisible pour permettre l'identification de variantes d'étiquettes.

Pour le deuxième problème, l'organisation ICANN a entrepris un examen détaillé en vue d'aboutir à des recommandations sur des mécanismes de gestion de variantes pour les TLD, qui ont été peaufinées à partir des retours de la communauté. Voici les principales recommandations :

  1. Les RZ-LGR doivent être la seule source de génération de TLD valides et de leurs étiquettes de variantes.
  2. Les variantes de TLD IDN {t1, t1v1, …} doivent être attribuées à la même entité.
  3. Certaines étiquettes sous des variantes TLD IDN s1.{t1, t1v1, …} doivent être enregistrées dans la même entité.
  4. Les étiquettes de variantes au second niveau sous des variantes de TLD IDN {s1, s1v1, …}.{t1, t1v1, …} doivent être enregistrées dans la même entité.
  5. Les tables IDN de second niveau, proposées sous des variantes de TLD IDN, doivent être harmonisées.
  6. Les étiquettes de variantes d'IDN susceptibles d'être allouées ou ayant été activées sous des variantes de TLD IDN peuvent ne pas forcément être les mêmes.
  7. Les fournisseurs de services de registre doivent être les mêmes pour les variantes des TLD IDN.
  8. Les politiques existantes et les procédures associées aux TLD doivent être mises à jour pour tenir compte des recommandations concernant les variantes de TLD IDN.
  9. Toutes les autres politiques existantes en matière de TLD doivent s'appliquer aux variantes de TLD IDN, sauf indication contraire.

Ces recommandations et les analyses figurant dans les six documents seront soumises à la considération du Conseil d'administration de l'ICANN en mars 2019.

À propos de l'ICANN

La mission de l'ICANN est de garantir un Internet mondial sûr, stable et unifié. Pour contacter une personne sur Internet, vous devez saisir une adresse sur votre ordinateur ou autre dispositif : un nom ou un numéro. Cette adresse doit être unique pour permettre aux ordinateurs de s'identifier entre eux. L'ICANN coordonne ces identificateurs uniques à l'échelle mondiale. La société ICANN a été fondée en 1998 en tant qu'organisation à but non lucratif, reconnue d'utilité publique. Elle rassemble au sein de sa communauté des participants du monde entier.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."