摘要

  • 1982 年 1 月 11 日，ISI 的计算机邮件会议决定将 username @ hostname 扩为 username @ host.domain。新的层级全放在唯一的 @ 右边，左边继续由各站点决定，连已经用在用户名里的点号也不碰。
  • 会议要求高层域名全局唯一，讨论了名称查询的不同返回结果，并安排修改软件以接受主机字段中的点号。DARPA 还须确定新格式可在整个网络发送而不遭收件方反对的日期。

想象一间邮局，左边一排抽屉归各个租户自己编号。有的叫 Li.Wen，有的点号另有本地含义。扩建工程师走进来，说要给整座城市统一门牌，顺便把旧抽屉重编一遍。柜台后的人大概会先把他请出去。Jon Postel 在 RFC 805 中记录了 1982 年 1 月 11 日 ISI 的计算机邮件会议：网络变大，地址必须变长，但已经有人住在旧地址里。

会议考虑过一个更漂亮的方案：unique-id @ location-id。邮箱身份可以独立于所在机器，搬迁只改投递位置。问题是，当时通行的已经是 user @ host，而 user 字段的本地变体太多。为了全局概念上的整洁，强迫每个站点改动已运行的软件，账单会由最不想装修的人支付。与会者暂时搁置了这个构想，选择扩展现有格式。

层级到底放在哪里？记录说，大家比较过放在 @ 左边和右边，也比较过各层的排列顺序。信息量并无差异，破坏性却大不相同。一些系统早就在用户名里使用点号；如果突然宣布点号是新的全球分隔符，昨天合法的收件人今天就可能找不到。于是新层级全部归到主机一侧。地址恰好有一个 @，右边的节点以点分隔，从最具体排到最一般。文中的例子是 Postel @ F.ISI.IN。顶层名称须全球唯一，名称的选取也受行政控制。统一的是位置的坐标，左边抽屉上的名字仍由本地掌握。

会议还把几个常被混成一团的问题拆开。层级域名是绝对地址，源路由表达的是相对路径。所谓名称服务，至少可能做三件不同的事：根据个人特征找人，把稳定身份映射到位置，再把位置映射为数字网络地址。当时只有最后一项需要尽快实现。一次查询可能返回最终主机地址、下一级名称服务器，或者转发节点；软件必须知道拿到的是哪一种，不能把路标当成收件人。NCP/FTP 与 TCP/SMTP 并存时，服务和协议的信息也可能影响投递。

具体怎么查，会议列出过 FTP 可取的文本文件，以及用类似 TCP 的连接或 UDP 数据报提供查询。中央服务器可以先起步，再由各域的服务器分担管理，每份数据库保留若干副本。那是设计选项，并非后来名称系统已在会上落地的证明。眼前更迫切的事情是修改 RFC 733、过渡计划和 SMTP 相关文件，让邮件程序认识主机字段里的点。

最后轮到日历出场。会议给 DARPA 的 Duane Adams 布置任务，期限为 1982 年 3 月 1 日：确定哪一天起，发件方可在 ARPANET 和 Internet 各处使用带点的主机名，而不再遭收件方抱怨。RFC 805 只记下任务和期限，没有给出如期切换或所有软件同步升级的证据。桌上通过的语法，撞上第一台旧解析器仍会退信。

这个决定的妙处在于认清边界。@ 左边是住户自家的抽屉，右边才是共同绘制的街道。扩建不必拆迁整条街，但邮差什么时候按新地图送信，必须有人明确通知。