摘要

  • RFC 3305 记录了一个分类观念的转变：URI 方案才是可扩展的基本单元；URL 可以继续作为有用描述，却不必占据 URI 空间里的独立类别。
  • 这份 2002 年备忘录属于 Informational，并非强制实施的命令。RFC 3986 后来引用其建议，证明文字进入了后续标准文本，却不能证明它是唯一原因或所有人都遵从了建议。

分类标签开始添乱

早期万维网的术语像一条简单的分拣规则：统一资源定位符（URL）通过描述主要访问方式来指向资源；统一资源名称（URN）则希望不依赖位置来标识资源。按经典说法，URI 不是 URL 就是 URN。这个区分容易讲清楚；难处在于，规范文档开始交替使用“URL 方案”“URI 方案”和“URN 方案”，仿佛它们处在不同层级。

RFC 3305留下了这场澄清尝试的记录。W3C 于2000年10月组建规划小组，评估 URI 领域还需要哪些工作。小组由 W3C 成员和受邀参与的 IETF 专家组成。2002年8月的报告把所谓“经典观点”与“当代观点”并列：一般而言，网络标识方案都是 URI 方案，而每种方案可以定义自己的子空间。http: 是 URI 方案；urn: 也属于 URI 方案，只是在其下定义了命名空间。

在这种理解里，“URL”不是一个必须把每种方案装进去的正式隔间。它仍是有用但非正式的说法，描述那些通过主要访问机制帮助定位资源的 URI。变化看起来细微，实则改变了提问方式：与其争论某种方案天生是“定位符”还是“名称”，不如看具体标识符及其分配者如何赋予它功能。一个方案可能支持命名、定位，或两者兼有。

这针对的是规范文本之间的摩擦，并不意味着 RFC 证明了所有用户都以同一种方式困惑。RFC 3305举出此前文件用词不一致的例子，包括定义通用 URI 语法的 RFC 2396，以及标题仍写“URL 方案”注册程序的 RFC 2717。邻近的规范对同一类扩展使用不同称呼，作者、实现者和注册表维护者就得先处理术语转换，才能讨论扩展本身。

建议不是命令

报告建议 W3C 与 IETF 共同制定 URI、URL、URN 模型；修订 RFC 2717 和 RFC 2718，把“URL 方案”改称“URI 方案”；说清替代注册树的规则；并改善 IANA 对公开、已废弃和待处理方案的记录。报告还记下了2002年的注册表概况。官方列表中的34个方案、十个正式 URN 命名空间标识符，都是当年的快照，不是今天的数量。

文件的状态非常重要。RFC 3305 是 Informational：它向互联网社区提供信息，不是标准轨道上的协议，也不是可以要求 W3C 项目、IETF 作者或方案维护者改写代码和用词的表决。它把协调问题说清楚，提出可能的路径；真正的控制仍分散在定义方案的规范、提交注册的人、由 IANA 维护的清单，以及解析或分配标识符的实现者手中。

三年后，RFC 3986留下了措辞进入正式标准文本的有力证据。它说明 URL 是一类通过主要访问机制来定位资源的 URI；也指出同一方案中的标识符不必只能是名称或定位符，并建议今后的规范使用一般术语“URI”，而不是限制更强的“URL”或“URN”——文中还明确引用 RFC 3305。这证明该建议被后来的 Standards Track 文件吸收，却不证明早期备忘录是唯一原因、所有标准作者都遵循了它，或日常用语中的“URL”因此消失。

注册工作沿着相关但独立的轨道继续。RFC 7595后来把 URI 方案的指引和注册程序写成 Best Current Practice。RFC 8820又从另一个方向讨论方案权限：URI 的结构由其方案定义；外部标准若规定 URI 内部结构，可能制造问题。后来的文件说明，术语改革并不能单独决定所有权、语法或注册流程。

这份记录能说明什么

RFC 3305 最适合被读成一段有限的标准史：联合规划小组识别出术语冲突，提出用词和注册表建议，然后把改变交给后续规范和参与者。RFC 3986 的明确引用让我们可以追踪一条建议进入更正式文本。现有证据却不能量化混乱减少了多少，不能证明所有人都采用了新说法，也不能把现代 URI 处理方式全部归功于 RFC 3305。

这种克制本身就是机制的一部分。协调备忘录可以让共同问题变得可见，却未必拥有执行答案的权力。发布形成一个可供他人采用的参照；实际发生什么，仍由后续规范、注册程序和实现来决定。