摘要

  • RFC 3406 要求 URN 命名空间申请者说明注册人、语法、唯一性、持久性、分配权限、等价规则、验证方式以及是否解析。IANA 登记的是命名制度，并不承诺始终存在一个可用解析器。
  • RFC 8141 后来更新了流程，却保留了制度核心：名称不得重新分给别的资源，分配必须一致，定义必须共同遵守，原管理机构无法继续时还要有接续安排。解析成功只是带时间戳的服务证据。

页面还在，名称却可能已经变了

坏链接通常很诚实：它告诉访问者当前位置已经不可用。更难察觉的是另一种失败——旧地址仍然返回内容，但内容已经换成无关对象。屏幕显示成功，历史引用却被悄悄改写。

统一资源名称（URN）要解决的正是这种长期引用问题。1994 年的 RFC 1737 把持久、与位置无关的识别列为目标，并把两个角色分开：命名机构负责发出名称，解析或定位服务负责把名称映射到某个可访问位置。解析服务可以有一个或多个，也可以由第三方提供，权威性、可用性和更新速度都可能不同。

这意味着 urn: 前缀不是信用来源。字符串即使语法正确，也还需要回答：它属于哪个被认可的命名空间？谁被授权分配？如何避免碰撞？名称能否在机构消失后继续保持原意？

Leslie Daigle 参与把这些问题变成登记程序。IETF Datatracker 把 RFC 2611 和 RFC 3406 列在她的作者记录中。2002 年 10 月发布为 BCP 66 的 RFC 3406 由 Daigle、Dirk-Willem van Gulik、Renato Iannella 和 Patrik Faltstrom 共同署名。本文讨论的是她在集体标准成果中的作用，不把 URN 的全部思想归给一人，也不暗示她今天管理所有命名空间。

两层“有人负责”

RFC 3406 先立下两个前提：URN 的分配是受管理的，URN 命名空间的集合本身也受管理。第一层防止任何人凭合规外观自造正式名称；第二层为每套制度分配命名空间标识符（NID），避免不同社群争用同一全局前缀。

NID 指向一套解释规则。出版编号、科研编号和协议参数都可能出现相同数字，只有放进各自命名空间，才能知道剩余字符串受哪套分配制度约束。它解决跨制度的区分，却不自动证明某个具体名称确实被发出。

空间内部的唯一性还带着时间方向。一个名称最多分给一个资源，并且以后不能转给别的资源；同一资源拥有多个不同标识符则可以接受。前者一旦破坏，旧文档、目录、合同和审计记录都会同时变得含糊。解析器再强，也无法向已经散布出去的副本解释哪一次含义才是真的。

所以，持久性首先是一项克制：不重分配。它不等于全年无休的服务可用率。合法 URN 可以在解析器故障时仍保持身份；被重用的 URN 即使每次查询都秒回，也已经失去历史可信度。

一张模板公开了整套权力结构

RFC 3406 的登记模板要求公开注册组织和联系人、字符串结构、支撑文档、唯一性与持久性安排、分配流程、解析流程、词法等价规则、验证机制、适用范围和安全问题。它看似罗列技术字段，实际是在拆分不同权力。

语法只判断形状。分配流程决定谁能发号。唯一性机制说明多个授权方怎样不重复。等价规则决定大小写、连字符或编码差异是否仍代表同一名称。验证机制说明检查能走到哪一步。解析流程则描述怎样从名称获得结果。一次成功访问无法替代任何前面的证明。

正式命名空间还要说明为何既有空间不够、对特定社群及一般互联网用户有什么益处，并明确请求 IANA 的登记动作。负责机构需要考虑自身寿命：是否长期稳定、是否具备分配能力、是否承诺旧名称永不重用，以及自己无法继续时命名空间如何存续。

这套流程没有假装评审能预测机构未来。技术审查可以发现注定损害持久性的设计，却不能保证企业或协会永远存在。登记的价值在于形成公开承诺、版本和责任线，而不是让 IANA 代替每个命名空间运营内部账本。

解析回答的是窄问题

RFC 3406 把全局解析放在另一项流程里。想提供这项能力的命名空间，需要进入解析发现系统，并说明怎样成为获认可的解析服务；模板也允许直接声明并未加入、解析并不相关。

这符合长期名称的用途。一个解析器可以返回当前 URL，另一个可以返回元数据、本地镜像、不同格式或不可用状态。地区、许可和时间都会改变结果。若唯一地址与 URN 绑死，位置的易变性就重新侵入了名称。

因此，解析结果的准确表述应当是：某运营者在某个时刻按某种策略返回了某个答案。它不能证明原始分配合法，也不能证明其他解析器同意，更不能担保目标明天仍在。即使目标返回成功，也只证明有服务器响应，不证明内容就是被命名的资源。

RFC 3406 对旧名称给出了重要边界：它们不一定永远可以解析，但不得被重分配，也不得被引向虚假或陈旧信息冒充原资源。对于历史完整性，一次清楚的“无结果”可能胜过一次看起来顺畅的错误跳转。

RFC 8141 把接班问题写得更明白

2017 年，Peter Saint-Andre 与 John Klensin 的 RFC 8141 取代 RFC 2141 和 RFC 3406，并明确感谢 Daigle 等四位作者留下的命名空间基础。社群登记改用专家评审，但三个约束没有变化：名称唯一、分配一致、遵循共同定义。

新版对组织稳定性的要求更具体。正式空间的分配机构应当证明能够长期维护；如果做不到，就要说明如何让空间继续有效。它还应具备分配能力，并承诺即使被分配者或所指资源消失，旧 URN 仍保持有效。

RFC 8141 把稳定规范称作注册人与使用社群之间的契约。模板覆盖目的、语法与等价、分配与唯一性、安全隐私、互操作、解析及补充信息；修订时要说明与旧版的差异，特别是技术和管理过程的变化。这样，登记就有历史，而不是一张脱离时间的许可证。

解析栏必须说明是否打算或预期提供解析。如果答案为是，还应描述运营或推荐的服务，以及公开发布服务的要求。必须公开的是控制安排，不是必须让每个名称永远能点开。

今天的 IANA 登记表同时容纳 ISBN、DOI、协议和行业类空间。它们共用登记框架，不共用一种解析架构。本次抓取的 XML 中有 97 个正式记录、8 个非正式记录；数字会继续变化，值得长期保存的是每条记录对应的模板、参考文档和版本。

把一次查询拆成四张收据

命名空间收据记录 NID、登记模板和规范版本。分配收据证明获授权的一方按规则发出了该名称，并且没有回收再用。解析收据保存解析器、时间、策略和原始答案。资源收据说明最终取得了什么，以及为何判断它就是目标资源。

语法通过不产生分配收据；分配合法不保证解析存在；解析成功不保证目标真实；资源可访问也不能倒推名称合法。四张收据分别失败，才可能选对修复动作。

Daigle 参与建立的机制因此不是关于某个前缀的趣闻，而是一堂管辖权课程。谁有权命名、什么绝不能做、记录如何传给继任者，决定名称能否穿过机构与软件的寿命。解析器很重要，但它只能帮助寻找，不能替名称守住过去。

资料来源