摘要

  • RFC 1394 把地区或国家名称、电话国码、telex 国码、answerback 与 Internet 域名放进一份有日期的对照表。同行只表示已知对应关系，不表示相关网络正在运行。
  • 文档没有掩盖不完整性：它用两种缺失标记区分未知字段，声明准确性无法保证，并邀请读者通过邮寄、电子邮件或 telex 提交更正。
  • 最关键的界线在代码之后。正确的代码仍不能证明 DNS 已委派、线路存在且获准使用、对端身份真实、消息已经送达，或某项政治地位获得承认。

同一行里有五套秩序

1993 年 1 月的 RFC 1394 处理了一种十分具体的障碍：人在一种通信系统里知道某个地方的称呼，却不知道另一种系统使用什么标识。文档把名称、电话国码、telex 国码、answerback 和 Internet 域名横向排在一起，还收录公共邮件系统与美国州级域名等条目。

这使查询变得容易，却没有把各列变成同一种资源。电话前缀交给电话交换系统解释；telex 代码和 answerback 属于另一张编号与回应网络；域名位于分层命名空间；商业邮件地址可能指向服务商，而非一块领土。表格声称它们有关联，不是说任何一个代码都能由统一算法转换成其他代码。

一行记录因此只是下一步调查的起点。它可以告诉读者应该尝试核对什么，却不能替运行者完成路由、网关、委派或投递。

未知没有被填成一个答案

RFC 1394 的使用说明给缺失值分了两类。四个短横表示不知道电话代码，三个短横表示其他信息缺失或未知。看似细小的差别，避免了把“没有收录”“当时不存在”“来源不确定”统统解释成同一种状态。

表内关系也并非一对一。有些地点列出多个 telex 代码，有些旧名和新名落到同一域名，有些地域拥有 Internet 后缀却没有 answerback。领土、历史国家、行政分区和商业网络同时出现，只因它们都能帮助查询，并不意味着它们具有相同性质。

作者明确说明，资料来自多个国家的多种来源。即使编制时已经合理谨慎，准确性仍无法保证，某些代码可能错误。文档同时开放邮寄、电子邮件和 telex 三种更正路径。它有编辑责任与修订入口，却没有同各通信网络实时同步的机制。

因此，印刷在 RFC 里的值仍需要时间戳、来源与本系统的再次确认。出版把观察固定下来，没有把观察升级成永远正确的权威。

两个字母还不是一次委派

RFC 920 早先规定，国家顶级域名采用 ISO 3166 的英文两字母代码。但它也区分了可用的标签、域名是否已经建立、以及管理员和代理人是否已经公开。代码表提供一种命名来源，不会自动在 DNS 根中产生新分支。

RFC 1034 把这条界线落到了运行层。DNS 名称树被切分为不同区域；服务器只对自己的区域拥有权威数据，也可能缓存别处的非权威信息。真正的委派需要父区边界上的记录，以及抵达子区服务器所需的信息。

RFC 1394 在一栏里印出两个字母，并不能完成这些动作。它没有建立父子区域边界，没有指定管理者，也没有证明名称服务器能够响应。若要证明委派，必须观察权威父区；若要证明运行状态，还要在具体时刻检查有关服务器。

反向推理同样不成立。一个 ccTLD 能正常回答 DNS 查询，不代表同一行里的电话或 telex 代码仍然有效。每一列有各自的运营者和更新周期。

有些后缀只是网关语言

RFC 1394 对 BITNET 与 UUCP 的说明揭示了另一类误读。System.BITNET 和 host.UUCP 是各自社群内部使用的名字，并没有注册进 DNS。从 Internet 发邮件时，需要使用当时的百分号路由写法，把地址交给 Internet/BITNET 或 Internet/UUCP 网关转换。

字符串看起来像域名，实际的下一跳却不是解析该后缀。掌握转换规则的是网关。网关接收消息，只能证明某个中间者承担了后续转送；远端系统是否收到、邮箱是否存在、收件人是否阅读，仍是之后的不同状态。

同一份文档把 .ARPA 描述为 DNS 中用于主机和网络反向查询的历史命名空间。相似的点号语法可以指向权威委派、社群内部记法或网关约定。不能只看外形决定真相由谁保管。

能拨什么不只由号码决定

在长表之前，RFC 1394 先提醒读者：能否接触某个国家，要看那里是否存在连接，也要看连接是否获准。它直接把政治限制列为无法通信的原因之一。

这里至少有三份不同记录。第一份是描述性对应：一个代码当时被认为属于某地。第二份是运行观察：从某个起点出发，某条运营路径在某时是否存在。第三份是许可：运营商、合同与适用公共权力是否允许使用它。

一次失败无法自动选择原因。目录值可能过期，起点网络可能没有路由，网关可能停机，政策可能禁止连接，对端也可能拒绝具体收件者。沉默不能证明某个地方不存在，也不能证明代码或域名无效。

成功也只提供有限证据。一次连接证明当时有路径完成了交换；它不一定认证了对方身份，更不产生未来持续通信的法律或技术权利。

目录没有资格决定国家是否存在

RFC 1394 特别声明，它不对国家名称或存在的有效性表达立场。作者征集旧称和别名，是为了让持有不同历史词汇的读者找到同一行，而不是把收录变成外交承认。

这项克制对于一份并列历史国家、领土、地区、私营网络和国家代码的目录尤其重要。目录要保留来源使用过的名字，才能服务查询；若每个词都被理解为政治裁决，普通更正便会被迫承担宪法意义。

一年后的 RFC 1591 说明了顶级域名的管理与委派责任。国家域名需要指定管理者、运行能力和行政技术联系人；管理者承担面向本地与全球 Internet 社群的服务责任。与此同时，RFC 1591 明说 IANA 不负责判断什么是或不是国家，采用 ISO 3166 正是因为另有程序处理那项问题。

这不是把国家主权交给域名管理者，而是把责任拆开：代码来源、根区协调、域名运行、通信运输和公共法律分别由不同主体承担。一个主体保管其中一层，不能据此获得其他层的权力。

薄目录的用处是引出下一项证据

RFC 1394 没有讨论安全问题。它没有认证表格行，没有证明联系得到同意，也没有保证网关保留作者身份或送达结果。把它当作凭证，会要求文档完成从未承诺的任务。

它真正提供的是一组更清楚的问题：代码应向谁确认？后缀是否真的受委派？哪个服务器给出权威回答？网关是否存在？从这里有没有路？使用是否获准？目的端是否接收？

只要这些问题不被合并，目录就能以很薄的方式促进协调。它让不同系统的引用可以互相发现，却把执行留给真正掌握执行能力的主体。