摘要

  • RFC 1261 宣布 Network Information Center 将于 1991 年 10 月 1 日从 SRI International 交接给 Government Systems Inc.。服务接触面力求延续，但 9 月 26 日至 30 日 WHOIS 不作修改，所有登记动作暂停，以便移交主数据库。
  • 一个持续可用的主机名、邮箱、帮助台或档案服务，只能证明读者或请求者仍有入口。它不能证明某份申请已经进入权威记录，更不能证明交接期间写入权从未中断。

用户看见的是服务，登记员面对的是状态

Network Information Center 的工作很容易被压缩成一个名字。用户会想到查询信息、发邮件提问、获取 RFC 或打给 Help Desk；管理者会想到网络号与顶级域名的登记；而维护者还要面对另一层事实：哪一份数据库是主库，谁有权把一项申请变成这份主库中的变更。

RFC 1261 没有把这些职责混为一谈。它说明 NIC 将从加州 Menlo Park 的 SRI International 迁至弗吉尼亚 Chantilly 的 Government Systems Inc.，正式交接日为 1991 年 10 月 1 日。文中列出了当时由 SRI 面向 DDN 与 Internet 用户提供的服务：网络与用户登记——明确包括网络号码和顶级域名分配——在线信息服务、Help Desk，以及 RFC 和 Internet-Draft 的档案与分发。SRI 会持续提供服务并回应电话与请求至 9 月 30 日；GSI 则承担后续服务。

对使用者而言，最重要的承诺是“看起来差不多”。RFC 1261 说，除少数例外外，连接到新的 GSI NIC 主机时，原有在线服务会呈现相同的样子。例外来自操作系统从 TOPS-20 改为 SunOS；文中还点出了新主机是一台运行 SunOS 4.1 的 Sun 470 SPARCserver。这个细节说明，界面和通道可以被设计得连续，运行环境却已改变。

但“看起来一样”只能描述访问体验。它不是对所有行政动作的证明。服务页面能打开，表示读者可能抵达了某个服务面；主数据库可写，表示有明确责任的一方能够把申请纳入权威状态。前者解决如何接触系统，后者决定什么事实进入登记簿。两者相关，却不能互相代替。

五天的暂停写入

RFC 1261 最重要的一段出现在具体日期中：9 月 26 日至 30 日，WHOIS 数据库不会更改，全部登记动作暂停。文本给出的理由非常直接：要把主数据库移交给 GSI；10 月 1 日登记活动恢复。

这并非服务故事里的小插曲，而是交接纪律的核心。一个登记系统不只是展示已有记录的窗口，它还必须控制更改如何被接纳。如果主库正从一方移交给另一方，系统就需要回答：旧方何时停止写入？新方何时拥有能够负责的完整状态？在这段之间，哪些请求只能被接收，哪些可以真正落账？RFC 1261 的回答不是假装无缝，而是把暂停写入公开写出来。

因此，几个容易被混淆的事件必须分开。有人可以提交申请；一个邮箱可以收到邮件；SRI 可以在适当情况下把邮件转给 GSI；帮助台可以解释新的联系路径；等登记恢复后，负责方才可能在主库中接受、拒绝或记录这项变更。只有最后一步说明登记状态发生了变化。前面几步分别是送达、转发和服务，不是主库写入的证据。

RFC 1261 对通道的安排也体现了这一点。从 9 月 26 日开始，纸质邮件和传真请求应转至 GSI；电子邮件请求仍发往 NIC.DDN.MIL 的 HOSTMASTER 与 REGISTRAR 邮箱，SRI 会视情况转交给 GSI。保留旧邮箱可以降低请求者迷路的风险，却不能把“邮件找到入口”升级成“变更已经被权威系统接受”。转发保存的是路径，不是决定。

平稳承诺不是完成证明

DISA 与 GSI 表示会尽最大努力使交接平稳、及时，用户受到的影响应当最小。这些话是有意义的公共承诺，但它们仍是交接前的意图，不是交接后的审计。RFC 1261 不证明每条数据都无误迁移、不证明每封邮件都及时转发、不证明每个人确实感到影响最小，也不证明某一特定登记请求在某一时刻已经成功。

这不是对资料苛刻，而是正确地使用资料。该 RFC 能够支持的，是一项被宣布的操作设计：旧服务延续到某日、主库在一段窗口内冻结、请求通道被重新安排、登记拟于交接日恢复。若要证明某个具体结果，需要另一类证据：接收记录、冻结队列、接受该变更的责任主体、所修改主库的版本，以及回给申请人的可核验结果。

如果把一个持续可用的入口当作所有这些证据的替身，责任就会消失。用户看到的是门仍然开着；审计必须知道某项变更何时、由谁、在什么主库上成为事实。RFC 1261 的价值，正在于它没有用表面连续来遮住这条界线。