3. 问题陈述

应用程序中的国际化域名(IDNA) [RFC5890] 允许使用国际化域名, 但其部署尚未惠及大多数用户. 原因之一是我们仍然没有完全国际化的命名方案. 域名只是需要国际化的各种名称和标识符之一. 在许多场景中, 只要更多其他标识符尚未国际化, 单独使用国际化域名的价值就很有限.

电子邮件地址是说明仅对域名进行国际化还远远不够的典型例子. 大多数观察者都从经验中了解到, 相比看似毫无意义的字母或数字串, 用户更喜欢与姓名或首字母缩写相似的电子邮件地址. 除非整个电子邮件地址都能使用用户熟悉的字符和格式, 否则用户会认为电子邮件在文化上不够友好. 如果电子邮件地址中的姓名和首字母缩写可以用用户的母语和书写系统表示, Internet 就会显得更加自然, 对母语并非使用罗马字母派生文字子集书写的用户尤其如此.

电子邮件地址国际化并不只是更改 SMTP 信封, 或修改 "From:", "To:" 和 "Cc:" 首部字段, 也不只是允许升级后的邮件用户代理(MUA)解码某种特殊编码并显示本地字符. 为了让用户认为它可用, 地址在所有出现的场景中都必须国际化并得到一致处理. 这一要求影响深远, 零散的补丁和变通办法并不足够. 即使它们勉强够用, 基于变通办法的方法也可能产生采用不同补丁和变通办法组合的各种实现, 导致用户无法判断究竟哪些功能可用, 哪些功能受支持. 因此, 我们需要构建完全国际化的电子邮件环境, 重点支持共享同一种语言和书写系统的人们高效通信. 这又意味着必须更改邮件首部环境, 让适合国际化的首部字段能够使用完整的 Unicode 字符范围; 必须提供 SMTP 扩展, 以允许 UTF-8 [RFC3629] [RFC5198] 邮件寻址并投递这些扩展首部字段; 必须支持投递通知和服务通知的国际化 [RFC3461] [RFC3464]; 最后还必须要求支持 8BITMIME SMTP 扩展 [RFC6152], 从而让所有这些内容都能通过邮件系统传输, 而不必克服首部字段没有内容传输编码这一限制.