Le projet de la version 2.0 de ces directives a été publié le 20 septembre 2005. Il reflète les expériences des registres IDN dans la mise en oeuvre de la version 1.0 des directives. Une attention particulière a été consacrée aux préoccupations qui ont été soulevées concernant l’usage trompeur de caractères susceptibles d’être confondus visuellement dans différents scripts d’étiquettes IDN individuelles.

Les mesures suivantes ont été prises dans le cadre du développement de la version 2.0 :

Un projet de révision de la version 1.0 des directives IDN a été préparé par :

• Les représentants des constituants du registre gTLD :
• Cary Karp, MuseDoma
• Pat Kane, VeriSign
• Ram Mohan, Afilias
• Les représentants de la ccNSO :
• Hiro Hotta, JPRS
• Mohammed EL Bashir, registre .sd
• Le personnel de l’ICANN :
• Tina Dam

Le premier projet de la version 2.0 est actuellement affiché pour faire l’objet de commentaires publics pendant 30 jours ; il sera modifié par la suite en fonction des commentaires reçus pendant cette période. Un projet définitif de cette version sera alors soumis au Conseil d’administration de l’ICANN pour approbation.

Les registres gTLD devront établir des politiques IDN qui seront conformes à ces directives et ils mettront en place aussi rapidement que possible une structure de soutien des procédures détaillée ci-dessous. À l’exception des détails administratifs qui sont clairement spécifiques au fonctionnement des TLD, ces directives sont destinées à être mises en oeuvre dans d’autres registres, à tous les niveaux.

À mesure que se poursuivra le déploiement des IDN, l’ICANN et les registres IDN examineront ces directives à intervalles réguliers et les réviseront selon les besoins dictés par l’expérience.

Versions précédentes

Version 1.0 : Les directives de l’ICANN pour la version 1.0 de la mise en oeuvre des noms de domaines internationalisés ont été publiées le 20 juin 2003, publication qui coïncidait avec le début du déploiement des IDN conformément à la norme proposée de 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.

Directives

1. Les registres des domaines 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 (désignées collectivement par les termes « 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 figurant 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, en utilisant les désignations acceptées pour tous deux. La restriction, dans un cas comme dans l’autre, 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 à la fois une désignation de langue et une désignation 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. Les désignations de langues sont illustrées dans le RFC 3066 (http://www.rfc-editor.org/rfc/rfc3066.txt). Les désignations de scripts sont illustrées dans l’ISO 15924 et le rapport technique Unicode no. 23 (http://www.unicode.org/reports/tr23/). (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 les propriétés des caractères Unicode (UTR#23). Une exception à cette règle est autorisée pour les langues ayant des orthographes et conventions établies exigeant l’usage combiné de plusieurs scripts. Les caractères de différents scripts susceptibles d’être confondus visuellement ne doivent pas apparaître dans une seule étiquette, sauf s’il existe une raison linguistique légitime pour procéder ainsi. Chacune de ces situations doit être associée à une langue spécifique et une table de caractères correspondante doit être disponible avant que l’inscription de ces noms puisse être acceptée. (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 de ponctuation qui n’ont pas de signification grammaticale dans la langue à laquelle l’inscription IDN est associée (avec la ponctuation nécessaire, y compris les caractères comme l’ESPACEMENT DES MOTS ÉTHIOPIEN en amharique et le POINT DU MILIEU en Catalan), et (d) d’autres caractères ayant des fonctions bien établies à titre d’éléments de protocole. Quand un registre établit qu’une exception peut être faite à l’une quelconque de ces règles, comme stipulé dans la directive no. 3, la base de cette décision doit être consignée dans le registre IANA des tables IDN ou publiée 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 la portée d’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 actuellement déterminée par sa faculté de codage dans le schéma défini dans le RFC 3491, et tous changements à ce composant de la norme IDN risquent de perturber le fonctionnement d’un nom Unicode. Pour cette raison, un registre IDN doit traiter la forme codée ASCII comme nom inscrit de premier niveau et inclure dans sa documentation une description des facteurs qui déterminent la façon dont la séquence apparaît à l’interface utilisateur.

6. Les registres des domaines de premier niveau oeuvreront en collaboration avec les intervenants pertinents et intéressés 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 (ainsi que les registraires) devront élaborer des définitions de ce qui constitue une inscription IDN avec ses règles d’inscription associées disponibles sur <registre IANA for 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.

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.

Détails administratifs

Pour les registres ayant des accords avec l’ICANN : Les registres ayant des accords de sponsorisation ou des accords de registre avec l’ICANN devront également respecter dans ces accords les conditions de formats exigées pour les noms inscrits. D’une manière ou d’une autre, les accords stipulent que tous les noms inscrits (y compris les noms ACE) devront respecter la syntaxe suivante dans la forme de Backus Naur augmentée (BNF) décrite dans RFC 2234:

point = %x2E ; "."
tiret = %x2D ; "-"
alpha = %x41-5A / %x61-7A ; A-Z / a-z
chiffre = %x30-39 ; 0-9
ldh = alpha / chiffre / tiret
préfixe id = alpha / chiffre
étiquette = préfixe id [*61ldh préfixe id]
sldn = étiquette point étiquette
nom de l’hôte = *(étiquette point) sldn

En outre, les limites de longueur doivent également être respectées.

Pour répondre à ces conditions requises, l’indicateur UseSTD3ASCIIRules décrit dans RFC 3490 doit être défini pour effectuer les conversions vers ASCII afin de produire les noms ACE, et la restriction de format qui en résulte doit être interprétée comme ci-dessus.

Pour les gTLD non sponsorisés : Les ensembles de règles basées sur ces directives ne doivent pas perturber l’accès équivalent aux services de registre de l’opérateur de registre par tous les registraires accrédités de l’ICANN qui ont des accords de registre-registraire en vigueur. Les opérateurs de registre des TLD non sponsorisés donneront en temps ordinaire un préavis de trente jours à l’ICANN et aux registraires autorisés et accrédités relatif à l’établissement ou à la révision des ensembles de règles. Dans les cas urgents, l’opérateur de registre et l’ICANN pourront convenir par écrit d’un délai plus court. Des conditions spéciales peuvent également être associées à la diffusion des informations asservies au temps, par exemple dans les cas où des effets d’urgence de territoire sont anticipés.

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/. Des limites concernant les répertoires de caractères disponibles pour les IDN y sont suggérées dans des tableaux présentés sous le titre « Fichiers de données ».

La liste des langues dans ISO 639-2 est actuellement en cours de révision, ce en préparation pour ISO 639‑3, qui est en au stade de projet avancé (à la date des présentes directives). La référence normative à BCP47 figurant dans les termes du registre de tableau de langues IANA IDN devra être modifiée lors de la finalisation de ISO 639‑3 ; il convient également de noter que l’IETF élabore à l’heure actuelle le projet définitif d’un document qui succédera à BCP. Ceci fournira des moyens plus élargis de spécifier des langues, y compris des désignations d’autorités en matière de scripts et d’orthographe comme composants d’une balise de langue. Cette révision est en cours de préparation par le groupe de travail d’actualisation du registre d’insignes linguistiques IETF (ltru). Étant donné que ses travaux exigent un statut normatif formel, les résultats exigeront peut-être d’apporter d’autres modifications aux directives IDN.