摘要

  • RFC 1107 为互联网和国家研究网络（NRN）设想了三阶段的人名目录项目；文件明确说明，这并非社区已经承诺的研究活动。
  • 方案先比较多种目录系统，再依据试验结果开展实现，最后准备广泛部署。可信数据、名称空间管理权、访问控制和客户端建设都还要解决。

电话簿看起来像一张姓名索引，背后却有一套维护工作：谁收集号码，谁持续更正，谁可以查看或改动记录。RFC 1107 所说的 Internet “White Pages”要帮助用户找到研究网络中的人，以及用于联系他们的信息，例如电子邮箱、日历或文件服务器。“Yellow Pages”则按属性查找互联网资源。这里讨论的不是给主机 DNS 再添一份人名表，而是如何让人和可联系信息长期可查。

Karen Sollins 于 1989 年 7 月发布的 RFC 1107《互联网目录服务计划》，记录了当年 2 月一场为期两天的会议。少数来自学术、商业和政府领域的代表参与讨论。会议共识认为，若获得有力资金和支持，三年内提供 NRN 白页服务是可行的。但 RFC 的状态说明紧接着限定了这项判断：文件是征求意见的提案，不代表互联网社区已经承诺的研究活动。日历上的三年既不是获批预算，也不是已启动或交付的证明。

技术选择被安排在试验之后。X.500 因目录语义丰富、又逐渐成为国际标准而被视为最可能的基础；它的规范仍有空白，严格的层级结构也引发顾虑。第一阶段因此要比较至少一种 X.500 实现——当时较成熟的 Quipu 被列为候选——以及 Profile 和 DEC 的 DNANS。Profile 支持描述式、非层级命名；DNANS 已设计访问控制、复制与缓存机制。如果再找到第二种 X.500 实现，试验就能更清楚地分辨问题来自标准还是来自具体程序。

比较不同系统时，输入数据也需要一致。RFC 1107 建议使用共同文件格式和共享管理工具，使多个实现能处理可比的目录记录。试验要查明的不只是查询是否返回结果，还包括人员信息如何收集、更新、分发和复制，谁可以读写，记录如何保持完整，客户端是否可用，以及怎样支持多种协议。方案倾向先在规模有限、熟悉相关问题的群体中试行；DNANS 则可在原本就要使用 DECnet 的环境中观察。这样的试点有助于控制变量，但不能证明其他机构会接受同一套治理方式。

规模估算显示，单台演示服务器无法说明全部问题。RFC 1107 假设科学和研究领域约有一千万用户，每人每周进行十次左右查询，即每周 10^8 次、平均每秒约 170 次，峰值会更高；目录至少要能承载 10^7 条记录。报告据此倾向多个服务器构成的分布式服务。这些数字是设计估算，并非已部署系统的测量结果。文件还提醒，广泛搜索的成本可能随目录规模上升。缓存、服务器分布和数据更新节奏都会影响负载；如果联系信息长期过期，即便系统能正确响应，用户也不会信任它。

计划把第一年用于试验、第二年用于实现、第三年用于广泛部署，但三个阶段应尽早并行启动。实现阶段可以根据试验结果选择一套方案，也可以组合不同方案的长处；生产服务还要有可靠服务器和面向人、程序及不同设备的客户端。至于部署，会议没有具体展开。数据采集与维护、服务器放置、客户端分发和培训、日常服务管理，以及对名称空间不同部分和记录内容的授权，都还在待办清单上。

这意味着目录设计也在分配管理权：谁能给组织新建一个分支？哪个服务器对它负责？谁可以改正个人条目或查看员工资料？RFC 1107 承认，有些机构不愿把自己的名字交由外部组织管理，个人和雇主也可能希望限制人事信息的访问。但一项广域目录的价值又在于跨越组织边界寻找联系人。互操作需要共同行为，信任则需要记录能被更新、权限受到约束，并让数据提供方保有实际控制。

RFC 1107 留下的是一份严肃的规划共识，不是服务完成的历史记录。它把“互联网白页”拆成可比较的试验、实现选择和部署工作，也把数据治理与名称授权放到协议设计旁边。只有每个阶段都找到责任人、资源和可核验结果，三年目标才可能兑现；这份 RFC 本身没有给出后续执行证据。

来源