摘要

  • RFC 1862 明确区分搜索、索引和对象取回。最终访问控制仍在对象端执行，但相关限制也应传到索引，因为“对象存在”本身就可能是敏感信息。
  • 工作坊保留了一个真正的分歧：类似 DNS 的目录希望对不同查询者给出相同答案，企业文档系统却可能连受限文档的存在都不能承认。
  • 因而，一条结果只是某一目录在当时策略与覆盖范围下的有限证据；它不能证明普遍存在、访问许可、当前位置、内容同一性、真实性或完整性。

拒绝发生得太晚

设想调查部门把一份报告放在受限服务器上。未授权者无法下载正文，访问控制完全按设计工作。然而，他在全局目录输入一个名字，立刻看到报告标题、责任人和日期。服务器随后返回“拒绝访问”，但最敏感的事实也许已经泄露：调查确实存在。

RFC 1862 的搜索与索引讨论正是在这里划线。报告认为，访问控制必须由对象本身执行；与此同时，访问控制信息应沿索引传播，让索引能够在用户尝试取回对象以前就回答“无权提出这个问题”。

这不是把对象的授权交给目录。两者回答的是不同问题。对象服务器决定是否交付字节或表示；索引服务决定一次查询可以得知哪些名称、描述和位置线索。两项决定可以依赖同一策略，却不能因为共享策略而合并成同一种权力。

三十四人的工作坊，不是互联网法令

IAB 于 1994 年 10 月 12 日至 14 日在弗吉尼亚州 Tysons Corner 的 MCI 场地召开工作坊。三十四名与会者分成三个讨论组，背景涉及 Web、Gopher、WAIS、命名、搜索、索引和图书馆服务，也包括 IAB 成员与相关 IESG 领域负责人。

1995 年 11 月发布的报告记录共同意见、分歧和研究建议。RFC Editor 条目 将其归为 Informational，正文也明确说它不规定任何 Internet Standard。场地和组织条件限制了参会人数，缺席者并不意味着没有相关专业意见。

因此，这份文献能证明当时的架构师已经看见哪些问题，却不能证明建议得到部署、每名参与者赞同每句话，或一个 RFC 编号自动形成普遍义务。历史价值恰恰来自它如实保留了尚未解决的选择。

搜索是在目录中寻找，不是打开对象

报告把“搜索”描述为查找指向信息的目录，把“索引”描述为扫描信息并建立这些目录。若把多个索引合并起来，就会形成统一目录。这个定义把搜索结果放回它真正所属的证据层：结果是关于指针的记录，不是目标对象本身。

这一区分避免了三个常见跳跃。找到一条记录，不等于有权取回它；拿到一个位置，不等于那个位置仍提供同一内容；没有结果，也不等于对象不存在。目录可能未覆盖该空间、尚未更新、发生故障，或者按策略选择沉默。

报告还指出，人工建立的索引通常质量较高，却耗费人力；机器索引扩展更快，却未必有同样判断力。为了合并不同索引，参与者期待更通用的格式，包括 URN 等名称机制。这里讨论的是互操作所需的共同表示，不是宣称已经出现了一个完整、权威的世界目录。

发布者、爬取者与成本归属

谁有权建立索引，也是成本问题。工作坊的总体倾向是让信息提供者控制索引方式。与其让机器人不断“走遍网络”，提供者可以制作本地摘要，再把摘要送交索引。这能减少网络与服务器负担，也允许内容拥有者说明哪些材料适合被发现。

这只是报告中的建议，不能被改写成后来互联网已经采用的通行机制。但它揭示了一个持续存在的激励结构：爬取的收益可能归聚合者，带宽、计算、更新和泄露风险却由发布者承担。本地摘要试图让发布者在承担成本时，也保留描述和暴露范围的控制面。

控制也会带来偏差。提供者可能漏报、不及时更新或选择性呈现；外部索引可能覆盖更广，却增加陈旧记录和越权发现。RFC 1862 没有消除这组取舍，而是把它从实现细节提升为架构选择。

“搜索互联网”本身就是过度陈述

工作坊认为，把行为笼统称作“搜索 Internet”并不恰当。真实操作是在某些公共信息空间里搜索，而公共与私人空间之间的界线仍需要研究。目录的覆盖范围、更新来源与访问策略，决定了它能对世界说什么。

这意味着零结果特别容易被误读。它可能表示目标不在这个索引，也可能表示目标不可问、记录未同步、命名不同或服务暂时失灵。正结果同样有限：它说明索引返回了一条指针，不保证另一个索引也能看见，不保证查询者获准打开，更不保证目标内容自记录创建后没有改变。

所有人同一答案，还是隐藏存在

报告没有掩盖访问模型之间的冲突。一种观点希望索引像 DNS 一样，不根据提问者身份改变结果。这有利于缓存、复现和共同命名：两个人询问相同名称，理应看见相同记录。另一种经验来自公司记录系统，其中仅仅承认某份文档存在就可能违反保密要求。

若回答随身份变化，系统需要识别查询者，可能记录查询，并让缓存和审计更复杂。RFC 1862 同时强调匿名使用的价值，因此个性化授权并非没有隐私成本。若回答永远相同，系统又无法隐藏敏感对象的存在。报告留下的是张力，而不是假装一个口号能解决两端问题。

名称、位置与限制是不同记录

RFC 1737 提出的持久名称要求，帮助解释这层分离。URN 用于识别资源，URL 给出位置，URC 则可承载包括访问限制和费用在内的元数据。一个资源可能没有当前位置，也可能有一个或多个位置。名称解析因此不是许可，更不是内容保证。

RFC 1738 更直接提醒，URL 并不保证未来仍能找到同一对象；某些 NNTP URL 指向的文章还可能只在本地可用。RFC 1630 提供了通用标识语法，却明确没有因此赋予所有名称与地址相同属性，其讨论也没有覆盖安全问题。

把这些文献并读，可以建立稳妥的证据链：索引记录名称或描述，解析把名称映射到可能的位置，对象端再作最终访问决定。任何一环的成功，都不能代替下一环的证明。

查询能力只有配上更新能力才完整

RFC 1862 还说，URN 基础设施既需要查询，也需要更新。只有解析而没有维护，目录会把旧位置、旧限制或已撤回的摘要继续当作现在。更新不是后台杂务，而是决定搜索结果能否代表当前状态的组成部分。

因此，严谨的观察至少要记下索引名称、查询范围、策略上下文和时间。若结果随后变化，变化可能来自对象、映射、索引内容或访问规则，不能自动归因于“互联网删除了某物”。

一条结果究竟能证明什么

RFC 1862 最有用的历史遗产，不是一份现代产品需求表，而是一套克制语法。可以说：“在这个时间、通过这个索引、按这个查询上下文，系统返回了这条记录。”不能据此说：“该对象普遍可见、查询者一定有权读取、这个 URL 永久指向相同内容，或者没有出现的对象不存在。”

把发现、定位和取回分开，结论反而更强，因为每个判断都能指向自己的证据来源和失败方式。那道位于文档门锁之前的索引闸门，并不取代对象控制；它提醒我们，信息泄露可能早在对象控制有机会动作以前发生。

来源