摘要

  • RFC 1292 是 1992 年 1 月的 FYI 11 信息性备忘录。它汇编商业与开放 X.500 实现所声称的可得性和能力；它既不规定 Internet 标准，也不认证所列软件。
  • 一次修订版中的关键字、可得方式或试点连通性，记录的是描述作者和编辑在该时点所形成的分类。它不证明后来仍可取得、能在某环境构建、能与某对端互操作，或已经完成一次有用的目录服务。

RFC 1292 的价值很容易被目录的整齐形式掩盖。表格、关键字和交叉索引会让读者感觉：世界已经被盘点，选项已经被比对，答案只差挑选一行。文档自身却给出了另一幅图景。Directory Information Services Infrastructure Working Group（DISI）收集的是实施者和供应商提交的描述；新描述和更新描述被欢迎提交；只有在收到“足够数量”的变更后，DISI 才会发布新版本，而是否足够由 DISI 主席作主观判断。

这不是编辑细节，而是目录的运行模型。现实中的实现会改变、停售、换版本、换分发地点、增加限制或获得新的功能；目录不会因为现实发生变化而自行改写。必须有人得知变化、选择提交、使描述到达编辑者、由编辑认为值得纳入下一版，并把新版本发布出去。RFC 1292 因而记录的不是“X.500 实现的状态”这个抽象整体，而是一条经人维护的信息链在特定时间冻结下来的结果。

目录有日期，软件也有不同的日期

阅读 RFC 1292 时，至少应区分四种时间。第一种是软件或产品自身的版本时间：某项功能何时写成、移除或修复。第二种是描述作者写下陈述的时间。第三种是编辑收到并分类该陈述的时间。第四种才是目录版本面向读者发布的时间。目录页上看似只有一个标签，但这些时间未必相同，也不一定被逐一记录。

这使“当前可用”成为一项需要单独验证的主张。RFC 1292 的 Potentially Unavailable 关键字定义得很克制：该实现“在本文写成时”不可得。它没有声称永远不可得，也没有解释原因。反过来，FTP、FTAM、商业可得、免费和源代码可得这些标签也只说明目录所记录的某种可得方式。它们不把目录变成实时探针，不能证明用户现在仍能访问文件、完成购买、取得许可、找到依赖项或得到维护。

这种时间边界并不意味着旧目录失去价值。恰恰相反，它让历史研究能够问得更准确：在 1992 年初，社区用哪些类别来描述选择？哪些分发方式被认为值得单列？“可能不可得”为什么需要成为一个显式状态？这些是关于信息基础设施的问题。若把目录当作今日产品清单，反而会丢掉其历史性质，并把它从未声称承担的即时性强加给它。

可得方式并不是获得结果

RFC 1292 的可得性词表展示了目录如何把一件宽泛的事情拆成不同问题。通过 FTP 可得，指向一种分发途径；它不等于读者实际下载成功，也不说明该文件是完整、正确或适配的版本。通过 FTAM 可得同样只是另一种途径。商业可得表示实现可以购买，却不回答价格、地域、合同、支持、交付周期和部署成本。免费表示没有收费，同时明确保留其他限制；它既不等于没有许可条件，也不等于有可持续维护。

“源代码”是最容易引出过度结论的词。源代码可得，最多说明源码可获取，且可能额外收费。它并不说明读者拥有合适的编译器、库、接口、平台、配置知识或修补记录；更不说明编译后能够与某个 X.500 对端建立服务关系。一段源代码是构建工作的材料，不是构建完成的证明；一个生成的二进制也不是目录查询成功或组织采用的证明。

把这些标签混成一个“可用”状态，会同时抹去获得、构建、安装、配置、互连和运维之间的分界。RFC 1292 的细分恰恰告诉读者不要这样做。目录减少的是发现候选项的成本，不是把后续工作从现实中删除。

描述作者、编辑和测试者不是同一个角色

RFC 1292 明说，实现描述由实现者和供应商书写，而不是 DISI 成员书写。DISI 协助提高可读性，却不保证描述有效，也不保证实现有价值。这一免责声明指定了信息的来源和编辑者没有接管的责任。

因此，一行目录记录至少可以拆成不同对象。其一，是作者对实现所作的描述。其二，是编辑把描述纳入文档并置于某些关键字下的行为。其三，是独立人员针对某版本、某平台、某配置和某对端作出的测试。其四，是组织考虑成本、人员、数据模式、政策和风险后作出的采用决定。目录主要包含前两者。它不代替第三者的测量，也不拥有第四者的决定权。

这种分离对 X.500 尤其重要。RFC 1292 涵盖 Directory System Agent（DSA）、Directory User Agent（DUA）以及 DUA 客户端应用。后者还可能是轻量程序：它使用非 OSI 应用层协议与一台 DUA 通信，由那台 DUA 再与 DSA 通信以支持用户服务。一个说明中出现 DSA、DUA 或轻量客户端，并不表示这些部件在同一地点安装、同时配置、共同运行，也不表示用户到目录树的整个路径有效。

目录中的部件名不是端到端服务图。它能帮助读者知道要问哪些部件存在，却不能替读者观察组件之间的版本匹配、名称表示、模式、信任、路由、访问策略和最终响应。

关键字忠实于描述，不等于忠实于运行

RFC 1292 的关键字来自实现描述本身。实现被归入一个关键字，依据是描述文本对能力作出了明确而不是暗示性的提及，或描述作者提供了相应输入。这个规则避免编辑者因为相邻功能、产品名称或猜测而擅自添加能力。它维护的是索引对文字的忠实性。

然而，文字上的明确与运行时的成立是不同命题。一个能力可以被如实描述，却只在特定版本、平台、可选模块、模式或授权条件下成立。它也可以说明设计目标而不是已观察到的部署行为。目录关键字证明的是：编辑把一项明确陈述表示为某种类别；它不执行代码，不协商协议参数，不检查远端权限，也不保存一次实际交换的记录。

实现类型的词表把这个界线展示得很清楚。API 表示有库和头文件；DSA Only 表示只有 DSA 而没有 DUA；DUA Only 则相反；DSA/DUA 表示两者均包括；轻量 DUA 客户端表示以非 OSI 协议通过 DUA 满足 X.500 请求。这些名称有助于避免把不同软件形态混为一谈，却不证明 API 稳定、DSA 含有所需数据、DUA 被授权，或轻量客户端能够输出可信而有用的结果。

空白也同样不能被误读。没有某个关键字可能意味着没有明确描述、作者没有提交输入、编辑没有如此分类，或者实现确实不具有该能力。目录规则并没有让这些可能性消失。把空白写成“缺失能力”，或把有标记写成“已经验证”，都是在文档之外添加事实。

传输标签不能自动建立一次关联

在互联环境类别中，RFC 1292 列出 CLNP、OSI Transport、RFC 1006 和 X.25。这样的类别让读者能够提出更具体的问题：某说明是否声称使用 OSI CLNP？是否说明了 OSI 传输而没有指明具体种类？是否声称通过 RFC 1006 使用 TCP/IP 传输服务？这对缩小研究范围十分有用。

但两个条目共享 RFC 1006 标签，不会自动在它们之间建立 X.500 关联。协议版本、配置文件、名称编码、目录模式、对象类、路由、对端身份验证、引用处理、访问策略和错误处理都可能不同。即使是同一个软件，在不同操作系统和本地配置下也可能表现不同。相同标签只是支持一项互操作假设的前提之一，不是该假设的实测结果。

后来的叙述很容易把这一点压缩成“当时 X.500 已经跑在 TCP/IP 上”。RFC 1292 能支持的更窄表述是：1992 年的一份目录将某些作者描述的实现归入 RFC 1006 类别。要声称一次服务运行，需要具体端点、配置、时间、操作及其结果。目录没有这些记录，也没有假装拥有它们。

试点连通性具有方向和范围

RFC 1292 对试点连通性给出两种不同定义。DUA Connectivity 表示 DUA 能连接到试点，并可查找任何试点条目的信息；它可以显示标准属性和对象类以及 COSINE 与 Internet Schema 所定义的属性和对象类。DSA Connectivity 表示 DSA 已连接目录信息树，且该 DSA 中的信息可由任意试点 DUA 访问。

这不是把“连接试点”换了两个同义词。前者围绕请求和显示，后者围绕服务和可访问的数据；两者的方向不同。能从一侧查找条目，并不使该侧成为存放或服务该条目的 DSA；被描述为可从试点 DUA 访问的 DSA，也不是每一条路径、每一个时刻、每一种查询都已成功的证据。

连通性标签还不能保证信息质量。能显示一个属性，不证明属性仍然正确；能接入目录树，不证明模式在所有对端都被同样解释；能在某版描述中被称为可达，不证明故障、政策或后来更改没有改变服务状态。目录定义了何种能力被声称，未越界宣称持续的访问结果。

不推荐是一种责任边界

RFC 1292 的范围明确排除了安装、运行和管理说明，并且不给出推荐，理由是组织的需求与计算环境差异很大。这不是因为分类没有用，而是因为推荐需要额外的责任。推荐者必须选定衡量标准、给各标准赋予权重，并为结果承担解释义务。

一所机构可能优先考虑既有传输栈、人员知识、目录模式、许可、支持、数据责任、安全需求、迁移成本或中断容忍度。另一所机构会给同一项属性完全不同的权重。DISI 所提供的是让选择更知情的信息表面，不是替任何读者作选择。整齐的交叉索引可能看似比较排名，但它只创造了可以比较的语言，并没有创造统一的价值函数。

遗漏也因此没有自动的负面意义。某实现不在目录中，可能是没有提交描述、没有被纳入该版、描述到达得太晚，或确实不符合某条件。没有原始编辑决策和提交记录，不能把缺席改写成被否定的技术结论。

目录的更新节奏也是基础设施的一部分

新描述和更新描述需要被提交；DISI 在变更数量被主席主观判断为足够后才发布新版本。这一机制表明，目录的鲜活性来自社会过程，而不是来自关键字本身。变更若没有被提交，目录就看不见它；提交若没有达到阈值，读者就仍看到旧版本；版本发布后，现实仍会继续变化。

第二版之前，一个已撤回的软件可能仍在目录中，一个新的产品可能尚未出现，一个已改变的能力可能沿用旧表述。历史上，这些延迟正是研究对象：它们揭示社区如何组织共享知识。运行上，它们是需要补充检查的条件。旧目录不因过时而变成虚假目录；它只不再足以支持一个关于当前状态的结论。

安全与用户结果不在该文档的证明范围内

RFC 1292 讨论的是可得性和能力描述，不是安全保证。它没有认证某实现的身份验证、保密性、完整性、漏洞状态或运维实践；也没有证明读者取得了许可、主机可达、试点访问被授权、目录条目正确，或组织因安装一个实现而得到结果。

正确的历史结论因而更坚实：RFC 1292 显示 1992 年的 X.500 社群如何把分散的自述转换成可发现、可初步比较的选项。它不是部署普查、兼容性认证、产品推荐或今天的目录服务状态。目录让决策的开端变得可见，并没有替代决策的证据链。

来源与证据边界

本文依据 RFC 1292 — A Catalog of Available X.500 Implementations。该来源支持其 1992 年 1 月 FYI/信息性地位、DISI 的目录目标、DSA/DUA/客户端区分、邮件列表征集、实施者和供应商的描述来源、不作保证的声明、明确能力关键字规则、可得性/传输/试点类别、不提供安装或推荐以及主观修订阈值。它不证明已安装、后来仍可得、当前支持、许可、成功构建、主机可达、试点连接、互操作性、安全性、组织适配、推荐、完成查询或用户结果。