J. KlensinP. Faltstrom (Cisco)C. Karp (Swedish Museum of Natural History)IABSeptember20062006-10-03
Les IDN ont toujours déclenché des passions
et suscité des oppositions vigoureuses, notamment de la part de ceux
qui regrettent que tout le monde n'écrive pas en
anglais. Autant dire que ce RFC, pourtant écrit
de manière très prudente et donc les aspérités ont été gommées, ne va
pas passer inaperçu. Il dresse un bilan plutôt négatif des IDN et
exprime de nombreuses craintes.
Après un rappel des normes existantes (les
IDN ont été normalisés à l'origine dans le ) et du vocabulaire du domaine (beaucoup de gens, à
commencer par l'ICANN
confondent encore langue et
écriture), ainsi que la littérature existante
(l'ICANN a produit des documents sans intérêt,
uniquement pour tenter de faire croire qu'elle avait un rôle dans
l'internationalisation de l'Internet), le RFC consacre sa section 2 à
lister plusieurs problèmes.
L'équivalence de deux noms dépend du langage : est-ce que
cafe.fr et café.fr sont le
même domaine ? D'autres peuples d'Europe accordent une plus grosse
importance aux accents que les français.
Certaines langues peuvent s'exprimer en plusieurs écritures, par
exemple l'azéri. Le même mot en différentes
écritures sera considéré comme différent par le DNS.
La canonicalisation des caractères par IDN
peut ne pas correspondre aux attentes des utilisateurs
(straße.de est canonicalisé en
strasse.de).
La forme imprimée de l'IDN peut ne pas être évidente à lire. C'est
le problème connu à l'IETF sous le nom de
"problème du côté des bus". Une publicité comprenant un
URL, chose banale aujourd'hui, pourra t-elle
être lue si elle se trouve sur le côté d'un bus qui passe, sachant que
de nombreux caractères se ressemblent ?
De même, certains caractères peuvent être facilement confondus
(comme .py - le Paraguay et
.ру - la Russie, écrit en
russe avec les caractères cyrilliques). Cela peut mener à des problèmes de
sécurité, par exemple en cas d'hameçonnage.
Une longue section 3 est consacrée à un problème urgent : la
migration vers de nouvelles versions
d'Unicode. IDN est limité à la version 3.2,
mais la 5.0 est déjà sortie. Un manque de stabilité de certaines
normes Unicode fait qu'IDN se limite donc à une vieille version
d'Unicode, sans moyen simple de mettre à jour.
De ces questions, notre RFC tire les conclusions suivantes :
Nécessité de revoir la norme IDN (une révision partielle a eu lieu depuis dans le ), notamment en passant d'un
modèle "Tous les caractères sont autorisés sauf" à un modèle "Sont
autorisés les caractères suivants :",Étudier les solutions non-DNS (par exemple avec un couche
supplémentaire dans l'interface utilisateur pour traduire
.com en chinois),Restrictions sur l'usage de multiple écritures dans un seul
nom.
D'autres conclusions sont explicitement dirigées plutôt vers
l'ICANN (notons que le RFC fait comme si
l'ICANN était responsable des politiques des
registres) :
Politiques d'enregistrement plus strictes chez les
registres,Politique d'introduction des IDN dans la
racine du DNS (ce qu'on nomme souvent les IDN.IDN par
exemple café.ré pour l'île de la
Réunion).
Le RFC appelle aussi à reconsidérer le rôle (limité) du
DNS et à considérer que, peut-être, les efforts
d'internationalisation pourraient porter sur des solutions non-DNS,
par exemple des moteurs de recherche.
Si ce RFC est très prudent dans ses recommandations (tout est
présenté sous forme de question, il n'y a pratiquement pas de
directive concrète qui pourrait fâcher), il appartient quand même à la
vaste catégorie des textes s'inquiétant, en général assez
hypocritement, des problèmes liés à IDN. La plupart de ces textes sont
émis par des organismes qui ne veulent pas de l'internationalisation
de l'Internet (on peut lire un bon
exemple). En fait, la plupart de ces textes, tout comme notre
RFC, oublient deux choses :
La complexité ne vient pas d'IDN ou
d'Unicode, elle vient des langues
humaines. Cells-ci sont très complexes, point. On peut le regretter et
se dire que cela serait plus simple si tout le monde parlait
anglais ou lojban mais
ce n'est pas le cas. L'IETF et les autres
SDO doivent faire avec.La plupart de ces problèmes sont marginaux. Ils ne se produisent
que dans des cas rares, avec des écritures peu courantes. Retarder les
IDN à cause de problèmes aussi artificiels serait retarder une
évolution de l'Internet vers plus de prise en compte des autres
cultures.
Ce RFC, comme beaucoup d'autres textes et discours analogues est,
quoique écrit dans le style IETF, de la même eau : du FUD.