摘要

  • RFC 3743 将特定的中日韩字符变体作为一个行政包来管理，使同一组相关标签归同一持有人控制。
  • 优选变体通常会被激活并写入区文件；其他字符变体则通常只保留、不发布。该文件既不证明某个注册机构采用了某张表，也不证明域名已经解析。

可见标签背后的更大对象

传统域名注册看起来像单字符串交易：标签可用，申请人注册，随后区文件可以发布它。国际化域名让这套直觉变得复杂。在中文、日文和韩文中，不同码点可能外观相似、含义接近，或在某种语言和地区规则下被视为变体。DNS 可以比较编码后的标签，却不会自行判断两个 Unicode 形式是否应由同一持有人控制。

这正是 RFC 3743 所处理的管理问题。该信息性文件于 2004 年 4 月发布，出自 Joint Engineering Team（JET）。参与者包括中国、台湾、韩国和日本的网络信息社群等。IESG 注记肯定了 JET 将政策与执行机制联系起来的工作，同时明确表示 IETF 不会替各个区域制定政策。同一套表格格式可以承载不同的本地选择。

这不是把 Unicode 标签转换为 DNS 所用 ASCII 形式的问题。早期 IDNA 文档规定了字符串准备和编码；RFC 3743 讨论的是一旦区域接受这类标签，如何管理可能引发混淆的变体。技术配置文件可以检查某个字符串是否符合规范，却无法代替每个语言社群对“哪些形式相同”的判断。

语言变体表把政策变成注册流程

每个区域可为其支持的语言维护 Language Variant Table（LVT）。表格记录有效码点、优选变体和字符变体。这里的分类表达的是不同管理方式，并非对书写系统的普遍高低判断；算法生成的字符串也不一定构成有意义的常用词。

注册时，候选标签先按当时 IDNA 体系中的 Nameprep 处理。注册机构再按申请中关联的每种语言，检查字符是否有效；之后生成优选变体和字符变体的组合，去除重复项，并与已有注册项及保留项核对。区域还可以按自己的规则过滤候选项。Unicode 本身没有决定这些结果；结果来自表格和区域的处理办法。

关键是区分“激活”和“保留”。原始标签以及通常符合条件的优选变体会被激活，成为区文件中的 Zone Variant。字符变体则通常只被保留：其他申请人不能注册，但它们并不因此自动成为 DNS 中可用的活动标签。RFC 3743 将原始标签、关联语言、激活的区域变体和保留变体共同称作 IDL Package。

这改变了管理单位。传统域名制度逐个标签办理注册、删除和转移；而这里的包具有原子性：转移或删除一个 IDL 时，其相关变体也随包一并处理。这样能避免两个持有人分别获得区域认为相关的形式，但代价是一次申请可能涵盖从未出现在活动区文件中的字符串。

RFC 的工作示例说明语言关联为何重要。同一标签可以通过多个语言表的检查，却在各语言下得到不同的优选形式；它也可能因为某个码点不适用于申请所选的一种语言而被拒绝。这些示例解释的是算法，不是某个已知注册机构采用该表的证据，更不是商业域名按该模型实际注册的证明。

保留包不能证明什么

RFC 3743 将许多关键选择留给区域：使用哪张表、接受哪些语言、如何处理冲突、允许生成多少变体，以及注册商和注册机构如何分工。部分例子假定“先到先得”，但区域也可以用自己的权利规则或争议程序替换它。RFC 不会证明某人依法拥有一个名称、一个包已经激活、某个 ASCII 标签已进入区文件，或者 DNS 查询能够成功。

后来的 IDNA2008 文档有助于划清边界：它们定义技术有效性、注册和查询流程，同时承认注册机构还可增加本地限制。这种延续性并没有把 RFC 3743 的 IDNA2003 时代算法变成现行协议规则，也没有让 JET 的语言变体表成为普遍语言标准。字符串校验、注册政策、实际注册、区文件发布和成功解析，是彼此不同的证据。

JET 的历史贡献是一种行政架构，而不是把所有中日韩字符等价关系塞进 DNS 协议。它为区运营者提供了表达本地变体选择、并将相关形式绑定到同一持有人的机制。这降低了一类分散注册风险，却也引入另一种依赖：语言表及其生命周期规则，成了申请人实际取得对象的一部分。用户看到的可能只是一个标签，保留的对象却大得多。

来源