L’approche de mise en œuvre définie dans la version 2.0 des directives de mise en œuvre des IDN (« Directives IDN ») a été approuvée par le Conseil d’administration de l’ICANN le 8 novembre 2005 pour une période temporaire de 9 mois, au cours de laquelle des recommandations spécifiques d’améliorations pour la mise en œuvre des IDN devront être fournies au Conseil d’administration de l’ICANN. Un plan de travail initial a été annoncé ( http://icann.org/announcements/announcement-27feb06.htm ) d’autres événements marquants et dates limites seront annoncés ultérieurement.

Le processus de révision des directives IDN a été fait de la manière suivante. L' Atelier IDN (légende en temps réel ici) au Luxembourg a fourni une base pour cette première révision des directives IDN. À la suite de cet atelier, un groupe de travail de registres gTLD et ccTLD jouissant d’une expérience dans les IDN (les noms des membres figurent ci-dessous) a été formé afin de collaborer à une révision des directives qui sera affichée pour faire l’objet de commentaires publics. Le group de travail a incorporé les résultats de l’atelier IDN au Luxembourg et une Version initiale 2 des directives IDN a été publiée le 20 septembre 2005. De nombreuses remarques et suggestions sur le projet initial de la Version 2 ont été soumis à un forum de commentaires public souvert jusqu’au 23 octobre 2005. Sur la base de ces informations, un projet définitif de la version 2.0 sur les directives a été préparé et transmis au Conseil d’administration de l’ICANN pour approbation. Le projet définitif de la version 2.0 a été approuvé par le Conseil d’administration de l’ICANN, qui n’a rien modifié à son contenu.

La version 2.0 des directives IDN figure ci-dessous ; elle a été préparée par les membres suivants du groupe de travail :

Nous remercions vivement tous ceux dont les noms figurent sur le forum public, ainsi que ceux qui nous ont assisté. .

Introduction

La Version 1.0 des directives pour l'implémentation des noms de domaines internationalisés , version initiale, a été publiée le 20 juin 2003, coïncidant avec le début du déploiement des IDN conformément à la norme proposée par l’IETF pour les noms de domaines internationalisés dans les applications, ainsi que stipulé dans les RFC 3454 , 3490 , 3491 et 3492 . L’approche de mise en oeuvre stipulée dans la Version 1.0 des directives avait été approuvée par le Conseil d’administration de l’ICANN le 27 mars 2003 . Ce document établissait les conditions dans lesquelles un registre TLD ayant besoin de l’autorisation de l’ICANN pour accepter l’inscription de l’IDN pouvait commencer à le faire. Un autre objectif des directives a été de fournir un document de support pour d’autres registres établissant des politiques sur les IDN.

L’expérience acquise dans la pratique effective des registres devait alors servir de base de révision des directives lorsque le besoin s’en ferait sentir. Pendant la revue qui a précédé la présente révision, et comme indiqué dans les commentaires reçus sur le projet de texte qui en a résulté, la version initiale des directives a dû être largement modifiée. Les modifications requises ne pouvaient pas être effectuées en apportant simplement des changements incrémentiels au texte initial. Toutefois, étant donné la nature urgente de certaines préoccupations concernant les IDN et le besoin correspondant d’une réponse rapide, le groupe de travail responsable de la tâche a décidé de produire aussi rapidement que possible une version révisée des directives en gardant leur format initial, puis de créer un autre instrument qui les remplacerait tout à fait.

Le texte présenté ci-dessous n’aborde pas toutes les préoccupations qui se rattachent actuellement aux IDN. (Une liste de ces points a été extraite des commentaires publics sur le projet de texte ; elle sera affichée séparément.) La prochaine rédaction prévue consistera à recadrer les directives d’une manière qui permette d’autres développements sous forme d’un document intitulé meilleures pratiques actuelles (Best Current Practices - BCP), auquel il conviendra également de donner un statut IETF formel.

Les directives présentées ci-dessous n’ont pas d’implications directes de conformité aux normes des IDN référencées ci-dessous. Il convient de ne pas lire le terme « sera » comme dans un instrument normatif formel. Même si les directives s’appliquent directement aux registres gTLD, elles sont destinées à s’adapter à une mise en œuvre dans d’autres registres de second niveaux et de niveaux inférieurs. Il sera remédié dans les BCP suivantes au manque de clarté éventuel qui subsisterait dans le texte actuel.

Directives

1. Les registres de domaine de premier niveau qui mettent en oeuvre les capacités des noms de domaines internationalisés y procéderont en respectant strictement les conditions techniques requises décrites dans les RFC 3454 , 3490 , 3491 et 3492 (collectivement, les « Normes IDN »).

2. En mettant en oeuvre les normes IDN, les registres des domaines de premier niveau auront recours à une approche « basée sur inclusion » (c'est-à-dire que les points de codes qui ne sont pas explicitement autorisés par le registre sont interdits) pour identifier les jeux de points de codes autorisés parmi ceux qui figurent dans tout le répertoire Unicode, comme décrit ci-dessous.

3. (a) En mettant en oeuvre les normes IDN, les registres des domaines de premier niveau associeront chaque étiquette d’un nom de domaine internationalisé inscrit, tel qu’il apparaît dans leur registre, à une seule langue ou à un seul script. Cette restriction est destinée à limiter le jeu de caractères autorisés dans une étiquette. Si l’on désire plus de spécificité, il est possible d’effectuer cette association en combinant en même temps des désignations de langue et de script. Ou encore, une étiquette pourra être associée à un jeu de langues ou à plusieurs désignations, selon les conditions décrites ci-dessous. (b) Un registre publiera la totalité des jeux de points de codes qu’il aura mis à disposition, dans des tables de caractères spécifiques aux IDN et clairement identifiées ; il devra également définir les variantes de caractères équivalentes si les politiques d’inscription sont établies sur leur base. Ces tables devront être désignées d’une manière indiquant la (les) langue(s) et/ou le (les) script(s) auxquels elles se réfèrent. (c) Tous les points de codes d’une seule étiquette devront être tirés du même script, comme établi par l’Annexe no. 24 des normes Unicode : Noms de scripts à http://www.unicode.org/reports/tr24 . Une exception à cette règle est autorisée pour les langues ayant des orthographes et conventions établies exigeant l’usage combiné de plusieurs scripts. Dans ce cas, les caractères de différents scripts susceptibles d’être confondus visuellement ne doivent pas apparaître dans un seul jeu de points de codes autorisés, sauf si une politique et une table de caractères correspondantes sont clairement définies. (d) Toutes les politiques de registre basées sur ces considérations doivent être accompagnées de documents et être mises à la disposition du public, y compris une table de caractères pour chaque jeu de points de codes autorisé, avant que l’inscription d’un IDN associé à ce jeu puisse être acceptée.

4. Les points de codes autorisés ne comprendront pas : (a) les caractères symboles de codes (par exemple ceux qui figurent dans le bloc de page de code Unicode), (b) les symboles et icônes qui ne sont pas des caractères linguistiques alphanumériques ou idéographiques, par exemple des symboles typographiques et pictographiques spéciaux, (c) les caractères ayant des fonctions bien établies à titre d’éléments de protocole, (d) les caractères de ponctuation utilisés uniquement pour indiquer la structure des phrases. (e) Les caractères de ponctuation utilisés à l’intérieur des mots ne sont autorisés que s’ils ne sont pas exclus par l’un des points précédents, s’ils sont essentiels à la langue de l’inscription IDN, et s’ils sont associés à des règles prescriptives explicites sur le contexte dans lequel ils peuvent être utilisés. (f) Dans des conditions correspondantes, un seul caractère spécifié peut être utilisé comme caractère de séparation dans une étiquette, soit en autorisant le trait d’union-caractère moins à apparaître dans des textes non latins, soit en désignant un caractère de ponctuation ayant une équivalence fonctionnelle dans le script.

Quand un nom inscrit préexistant requiert qu’un registre fasse une exception transitoire à l’une quelconque de ces règles, les conditions de cette décision doivent être mises à disposition en ligne. Un registre ne peut pas, même par exception, autoriser des points de codes qui sont interdits par les normes IDN.

5. Un registre doit définir une inscription IDN en termes à la fois de ses représentations codées Unicode et ASCII. La disponibilité d’une séquence Unicode donnée est déterminée actuellement par sa faculté de codage dans le schéma défini dans le RFC 3491, et les changements qui seraient apportés à ce composant de la norme IDN risquent de perturber le fonctionnement d’un nom Unicode. Étant donné que l’apparition de traits d’union en troisième et quatrième positions d’une étiquette indique un schéma de codage, l’inscription d’une étiquette contenant des traits d’union dans ces positions ne sera pas autorisée, sauf si le trait d’union suit une désignation de deux lettres pour un schéma sanctionné et si l’étiquette est conforme aux caractéristiques correspondantes.

6. Les registres des domaines de premier niveau oeuvreront en collaboration avec les intervenants pertinents afin de développer des politiques d’inscription spécifiques aux IDN, avec pour objectif d’obtenir des approches cohérentes à la mise en oeuvre des IDN dont bénéficieront les utilisateurs des DNS dans le monde entier. Les registres des domaines de premier niveau oeuvreront en collaboration les uns avec les autres pour traiter des questions communes, par exemple en formant ou en nommant un consortium qui coordonnera les contacts avec les communautés externes, qui sollicitera l’assistance de groupes de soutien et qui établira des forums globaux.

7. Les registres des domaines de premier niveau devront élaborer des définitions de ce qui constitue une inscription IDN avec ses règles d’inscription associées disponibles sur le registraire IANA des tables IDN. Si des documents cruciaux à la compréhension des politiques IDN d’un registre ne sont pas publiés par l’IANA, ils devront alors être mis à disposition en ligne par le registre, qui s’assurera également que ses registraires attireront l’attention des futurs détenteurs de noms IDN à ce sujet.

8. Les registres des domaines de premier niveau devront fournir les ressources contenant des informations sur les sources et les références qui ont été utilisées dans la formation des politiques d’inscription aux IDN correspondantes pour toutes les langues et tous les scripts dans lesquels ils offrent des inscriptions aux IDN.

Autres remarques

L’usage trompeur des caractères susceptibles d’être confondus visuellement dans différents scripts est couvert en détail dans le rapport technique Unicode no. 36 sur les « Conditions de sécurité Unicode » à http://www.unicode.org/reports/tr36/ ainsi que dans un projet de rapport technique Unicode no. 39 à http://www.unicode.org/reports/tr39/ . Des limites concernant les répertoires de caractères disponibles pour les IDN sont suggérées dans l’UTR no. 26, dans des tableaux présentés sous le titre « Fichiers de données ».

En raison de la restriction actuelle des étiquettes de premier niveau aux 26 lettres de l’alphabet latin de base, il est nécessaire de déterminer les attributs linguistiques d’un IDN sans prendre en compte l’étiquette de premier niveau. La discussion actuellement en cours concernant l’autorisation de disposer d’un répertoire plus étendu de caractères dans les étiquettes de premier niveau pourra apporter un changement à cette situation et fera en outre ressortir la nécessité d’avoir d’autres directives spécifiques à la nouvelle situation.