3. Énoncé du problème

L'internationalisation des noms de domaine dans les applications (IDNA) [RFC5890] permet les noms de domaine internationaux, mais le déploiement n'a pas encore atteint la plupart des utilisateurs. L'une des raisons est que nous n'avons pas encore de systèmes de nommage entièrement internationaux. Les noms de domaine ne sont qu'un des divers noms et identifiants qui doivent être internationaux. Dans de nombreux contextes, jusqu'à ce que plus de ces identifiants soient internationaux, les noms de domaine internationaux seuls ont peu de valeur.

Les adresses e-mail sont des exemples principaux de la raison pour laquelle il n'est pas suffisant de simplement internationaaliser le nom de domaine. Comme la plupart des observateurs l'ont appris par expérience, les utilisateurs préfèrent fortement les adresses e-mail qui ressemblent à des noms ou des initiales à celles impliquant des chaînes de lettres ou de chiffres apparemment sans sens. À moins que l'ensemble de l'adresse e-mail puisse utiliser des caractères et des formats familiers, les utilisateurs perçoivent le courrier électronique comme étant culturellement hostile. Si les noms et les initiales utilisés dans les adresses e-mail peuvent être exprimés dans les langues et systèmes d'écriture natifs des utilisateurs, Internet sera perçu comme plus naturel, en particulier par ceux dont la langue maternelle n'est pas écrite dans un sous-ensemble d'un script dérivé de la tradition romaine.

L'internationalisation des adresses e-mail ne consiste pas simplement à modifier l'enveloppe SMTP; ou à modifier les champs d'en-tête "De:", "À:", et "Cc:"; ou à permettre aux agents utilisateurs de messagerie (MUA) améliorés de décoder un codage spécial et de répondre en affichant des caractères locaux. Pour être perçus comme utilisables, les adresses doivent être internationalizées et gérées de manière cohérente dans tous les contextes dans lesquels elles se produisent. Cette exigence a des implications de grande envergure: les collections de correctifs et de solutions de travail ne sont pas adéquates. Même si elles étaient adéquates, une approche basée sur la solution de travail peut entraîner une variété d'impléments avec différents ensembles de correctifs et de solutions de travail ayant été appliquées avec une confusion conséquente de l'utilisateur sur ce qui est réellement acceptable et supporté. Nous devons construire un environnement de messagerie entièrement internationalisé, en nous concentrant sur la communication efficace entre ceux qui partagent un système de langue et d'écriture. Cela implique à son tour des changements dans l'environnement d'en-tête de messagerie pour permettre à ces champs d'en-tête qui sont appropriément internationaux d'utiliser la gamme complète de caractères Unicode, une extension SMTP pour permettre l'adressage de messagerie UTF-8 [RFC3629] [RFC5198] et la livraison de ces champs d'en-tête étendus, le support pour l'internationalisation des notifications de livraison et de service [RFC3461] [RFC3464], et (finellement) une exigence de soutien de l'extension SMTP 8BITMIME [RFC6152] afin que tous ceux-ci puissent être transportés à travers le système de messagerie sans avoir à surmonter la limitation que les champs d'en-tête ne disposent pas de transférencodings.