Parmi les protocoles utilisés sur
Internet, presque tous sont internationalisés
depuis longtemps. Le dernier gros manque concernait les adresses de
courrier électronique, obligées de s'en tenir à
stephane@internet-en-cooperation.fr alors qu'on voudrait pouvoir
écrire à
stéphane@internet-en-coopération.fr. Désormais,
nous avons une solution, Internationalized
Email Addresses. Expérimentale à l'époque de la
parution de ce RFC, cette solution est devenue une norme complète par
la suite avec le , qui a remplacé ce RFC.
Bien sûr, pour l'exemple ci-dessus, le gain n'est pas évident. Mais
il l'est beaucoup plus si vous voulez écrire votre adresse avec
l'écriture arabe ou
chinoise.
Le contenu des courriers était internationalisé
depuis longtemps, au moins depuis MIME ( à l'origine, en juin 1992). Mais les adresses ne l'étaient pas
encore. Notre RFC décrit le cadre général de l'internationalisation
des adresses de courrier.
Il y a deux parties à l'adresse (décrites dans le ) : la partie locale, à gauche du @ et le nom de domaine
à droite. Si ce nom de domaine, depuis la sortie du , en mars 2003, peut s'écrire en
Unicode (norme IDN), le
courrier exigeait toujours un nom de domaine en
ASCII donc un message de non-délivrance, par
exemple, allait affichait la forme Punycode du
nom. Ce n'était pas une vraie internationalisation.
Le cadre d'internationalisation du courrier couvre plusieurs
aspects, couverts chacun par un RFC. Ce premier RFC expose
l'architecture générale.
SMTP est modifié pour permettre une nouvelle
extension, indiquant le support du courrier internationalisé ().
Le format des messages () est modifié
pour permettre d'inclure de l'Unicode, encodé
en UTF-8, directement dans les en-têtes, comme
le champ To: ().
Un mécanisme de repli
(downgrading) était prévu pour le cas où un émetteur
internationalisé rencontrerait un récepteur qui ne l'est pas,
nécessitant une modification des adresses en ASCII (). En effet,
contrairement à HTTP, le courrier ne fonctionne
pas de bout en bout et le message est relayé par plusieurs serveurs,
qu'on ne connait pas forcément a priori. Ce mécanisme s'est révélé
bien compliqué pour pas grand'chose et a finalement été abandonné avec
le .
De même, les protocoles POP et
IMAP doivent être modifiés pour que le courrier
ainsi internationalisé puisse être récupéré... et lu.
Le repli est certainement la partie la plus complexe et fera
l'objet d'un RFC propre : modifier un message est toujours une
opération délicate, notamment en présence de signatures cryptographiques,
que le repli ne doit pas invalider !
Notons (section 6.3 du RFC) que les adresses de courrier sont utilisés en de nombreux
endroits, par exemple comme identificateurs sur certains sites Web de
commerce électronique, comme Amazon et que ces
utilisateurs vont également devoir s'adapter. Quant on voit le nombre
de sites, supposés professionnels, qui continuent à interdire des
adresses de courrier légales, on mesure
l'ampleur
du travail. La sortie en février 2012 de la norme , qui remplace notre RFC, accélérera-t-elle
les choses ?