摘要

  • RFC 1295 是北美目录论坛在 1992 年 1 月发布的 Informational 文档，而不是 Internet Standard。它为 Public Directory 中的条目和列名提出七项权利：不被列名、条目创建时收到通知、查阅、更正不准确信息、移除特定信息、期待符合适用的美国或加拿大隐私／访问信息法律，以及期待及时处理。
  • 这不是删除协议，也不是安全保证。文档区分公共目录和私有部分，并允许用户或代理人选择公共、私有或混合列名；1993 年废止它的 RFC 1417 又说明，竞争性服务提供者通过公共命名空间连接分别管理的私有命名空间。

读 RFC 1295《User Bill of Rights for entries and listings in the Public Directory》 时，不能把问题误读为“X.500 式目录能否保存属性”。它当然可以保存。真正的问题是：一个系统能保存、索引并返回属性，是否就因此取得了把属性展示给公共受众的资格。北美目录论坛给出的答复不是一个访问控制细节，而是一条先后关系：在目录把某人变得可检索之前，目录必须保留那个人拒绝被列名的地位。

这条关系之所以重要，是因为公开可发现性会改变同一信息的后果。电话号码、电子邮件地址或组织隶属，在一个限定关系里可以只是工作资料；进入公共索引后，它们就成为任何查询者可利用的可达性线索。RFC 1295 允许用户或其代理人选择把资料列入 Public Directory、私有目录，或两者结合。它举的例子很克制：电话或邮件地址可以公开，其他信息则保留给特定私用。这里没有把某个字段永远判为“安全”或“危险”。决定性的是受众边界，以及谁作出了把信息放到那个边界之内的选择。

创建通知不是同意

在“不被列名”之后，文档写的是：创建条目时应通知。两句话靠得很近，却不是同一件事。通知至多表明运营者就已经发生的创建动作发出了一次信息。它不证明当事人授权了创建，不证明当事人读到通知、理解了范围，也不证明其拥有有效的反对渠道。

通知的作用在于让原本无声的创建变成一个能够被追踪的事件。没有通知时，当事人可能是在第三方已经查到公开条目之后才知道自己被列名。有通知时，至少可以识别出一个动作、一个预期接收者、一个可能的时间点和一个可查阅的对象。此后的权利——查阅、更正、移除特定信息——才有了可以指向的记录与可能被行使的时点。

因此，不能把七项权利压缩成一句模糊的“隐私承诺”。运营者收到不列名指令，不证明它从未创建公开条目；公开条目存在，不证明当事人同意；发出通知，不证明同意；当事人能看见条目，不证明字段准确；提出更正，不证明可见版本已经改变；运营者更新了自己权威副本，也不证明其他副本已消失。每一句都需要单独的行为者、时间、版本和证据。前一句不会悄悄证明后一句。

更正错误，不等于撤回一个字段

RFC 1295 对查阅、更正和移除特定信息的区分，比分配一个通用“编辑资料”按钮更有历史精度。查阅让当事人知道条目究竟声称了什么。更正面对的是准确性：错误的地址、过时的隶属关系、被错误归属的资料。移除特定信息则是另一类问题：某项资料可能准确，但不适合向目前这一公共受众继续展示。

两种请求要保留的证据也不同。更正需要指出哪项主张不准确、哪一版记录替代了它。定向移除需要指出字段、受众和不再展示的指令，同时不必把围绕该人的所有身份、服务或关系都假定为一并抹除。文档没有定义分布式删除流程，也没有提供核验复制副本的机制。它的贡献更基础：准确性与暴露面并不是同一个问题。

第七项“及时处理”又把权利变成运营工作。请求如果只得到表单、政策页面或笼统的结案信息，并不会因此自动成为已处理。反过来，RFC 1295 也没有给出一个全球统一的时钟或裁定具体争议。它要求服务提供者把这些权利当作可执行的服务关系：接收请求、识别对象、作出决定、在适用时修订，并予以回应。这个过程不能被说成只是保存若干属性。

公共命名空间并不拥有私有记录

RFC 1295 把讨论放在一个计划中的北美合作式电子目录服务内，取向是 CCITT X.500 标准。它把 Directory 描述为由服务提供者和私有运营者运行的一组电子目录。条目里的信息在未受安全和隐私限制时可以被访问；用于公开传播的部分构成 Public Directory，其他部分则可能根本无意向公众开放。

命名层级、查询路由或复制关系很容易让人误以为技术结构已经回答了“谁有权决定”的问题。其实它们只说明客户端可能如何抵达一个回答。它们不决定谁选择了受众、回答是否准确、代理人是否获授权、通知是否到达，或请求是否及时完成。可见性是某个被观察界面的属性；授权是一段必须单独证明的关系。

1993 年发布并废止 RFC 1295 的 RFC 1417《NADF Standing Documents: A Brief Overview》 更清楚地呈现了这种制度处境。它描述了相互竞争的提供者试图合作提供公共目录服务，公共命名空间旁边是分别管理的私有命名空间。注册发生在 Directory 之外，实体可以选择在他人较可能搜索的位置列名。共同的地图帮助发现路径，却没有使任何一个提供者独占地图背后所有私有记录的所有权。

RFC 1417 还说，X.500(88) 缺少知识维护程序，而提供者之间的竞争使公共命名空间不可能由一方独占管理。文中描述的应对是，从公共命名空间协作地链接到私有命名空间，并让链接携带很少的载荷。这不是所有实现都如此运作的证明，也不是某一次移除已经清除每份复制品的证明。它证明的是：恰恰因为没有一个单一运营者能诚实地代表所有私有记录，一个共享的公共目录才需要责任边界。

被列举的权利不是技术担保

RFC 的状态要求我们不要扩张它的效力。RFC 1295 是 1992 年 1 月的 Informational 文档，不是 Internet Standard，并说明它是 NADF-265 的近乎逐字副本。其安全考虑明确说未讨论安全问题。因此，它不能被当作加密、每个代理人都已认证、复制被阻止、删除得到保证或规则在全球法律上具有约束力的证据。

它提到适用的美国或加拿大隐私或访问信息法律，同样不能被变成当下合规的证明。文本没有给出今天的法律测试，不能替其他司法辖区下结论，也不能让一次目录响应成为法律认证。它所做的是拒绝让运营者把自己描述成字段和查询之间的中性传递者：一旦发布条目，运营者就进入了带有程序责任的访问关系。

这也规定了观察证据时应有的节制。看见公开结果，不证明当事人同意或法律已经得到遵守；查不到结果，不证明它从未存在、没有副本或移除已经完成；请求回执，不证明更正；提供者的当前版本，不证明之后的每一个读者都得到这个版本。RFC 提供的是提问的词汇，而不是自动补全证据链的工具。

来源与证据边界

本文依据 RFC 1295 和 RFC 1417。两者共同支持 1992 年 1 月 Informational 身份、与 NADF-265 的近乎逐字关系、面向 X.500 的合作目录背景、七项明确权利、公共／私有目录的区分，以及后续对竞争性提供者和相连命名空间的说明。它们不证明当前某个目录、某位用户的请求、通知被实际接收、一次具体更正、某个副本的消失、复制状态、法律合规或安全保证。