1. 引言

统一资源名称 (Uniform Resource Name, URN) 是一种统一资源标识符 (Uniform Resource Identifier, URI) [RFC3986], 它在 "urn" URI 方案和某个特定的 URN 命名空间之下被分配, 其意图是使该 URN 成为一个持久的, 与位置无关的资源标识符. URN 命名空间是此类 URN 的集合, 其中每一个 URN 都是 (1) 唯一的, (2) 以一致且受管理的方式分配的, 并且 (3) 按照共同定义分配的. (有些 URN 命名空间创建的名称仅作为 URN 存在, 而另一些则基于已经在非 URN 标识符系统中创建的名称来分配 URN, 例如 ISBN [RFC3187], ISSN [RFC3044] 或 RFC [RFC2648].)

URN 的分配由一个组织完成 (或者在某些情况下, 按照某种算法或其他自动化过程完成), 该组织已被正式授予 "urn" 方案内某个 URN 命名空间的委托 (例如, "example" URN 命名空间 [RFC6963] 中的一个 URN 可能形如 "urn:example:foo").

本文档建立在两个关键假设之上:

1. URN 的分配是一个受管理的过程.

2. URN 命名空间的空间本身是受管理的.

虽然其他 URI 方案可能允许自由选择和分配资源标识符, 但 URN 并非如此. 一个以 "urn:" 开头的名称在语法上正确, 并不足以使它成为一个 URN. 要使该名称成为有效的 URN, 命名空间标识符 (namespace identifier, NID) 必须按照此处定义的规则进行注册, 并且 URN 中 assigned-name 部分的其余部分必须按照已注册 URN 命名空间的规则生成.

为了使关于 URN 语法和 URN 命名空间的信息集中在一处, 本文档做了以下事情:

1. 总体上定义 URN 的规范语法 (以与 URI 语法一致的方式), 规定确定 URN-Equivalence 的方法, 并讨论 URI 一致性.

2. 规定一种定义 URN 命名空间并将其与特定 NID 关联的方法, 并描述向互联网号码分配机构 (Internet Assigned Numbers Authority, IANA) 注册 URN NID 的程序.

就 URN 语法和 URN 命名空间而言, 本文档对 URN 语法 [RFC2141] 以及 URN 命名空间的定义和注册 [RFC3406] 的原始规范进行了现代化并予以替代. 这些修改建立在 URN 原始功能描述 [RFC1737] 中给出的关键要求以及多年经验教训的基础之上. 在那些原始文档和本文档中, 其意图都是以一致的方式定义 URN, 以便在一切可行之处, URN 的解析 (parsing), 处理 (handling) 与解析 (resolution) 可以独立于给定 URN 被分配于其中的 URN 命名空间.

结合来自若干关键用户社区的输入, URN 的历史和经验决定了必须扩展 URN 定义以支持新功能, 包括使用 RFC 2141 中明确保留供未来标准化的语法. 所有在较早规范下有效的 URN 命名空间和 URN 仍然有效, 尽管更新某些 URN 命名空间的定义以利用新特性可能是有益的.

上述考虑, 连同 URN 与作为定位符 (locator) 的 URI (具体而言即 URL) 之间的种种差异, 以及 RFC 3986 作为 [RFC1738] 和 [RFC1808] 的最终后继者而对 URL 给予的更大关注, 可能导致对 RFC 3986 和本规范的一些解读看起来 (或者实际上确实) 并非完全一致, 尤其是在基本语法本身之外的动作或语义方面. 如果出现此类情况, 对 URN 和 URN 命名空间的讨论应当依照本文档来解释, 而不是从 RFC 3986 外推.

对 RFC 2141 和 RFC 3406 变更的摘要分别见附录 B 和附录 C. 本文档废弃 [RFC2141] 和 [RFC3406] 两者. 虽然它并未明确更新或替代 [RFC1737] 或 [RFC2276], 但引用那些文档的读者应当意识到, 本文档中 URN 的概念模型与那些较早的规范略有不同.

1.1. 术语

下列术语按下文所述相互区分:

URN: 使用 "urn" 方案的 URI (如 RFC 3986 所定义), 它具有该文档所述的 "name" 属性以及本文档所述的属性. 该术语适用于整个 URI, 包括其可选组成部分. 给读者的提示: "URN" 一词在其他上下文中曾被用来指 URN 命名空间, 命名空间标识符, assigned-name 以及不使用 "urn" 方案的 URI. 除最后一项之外, 上述各项在本文档其他地方都用更具体的术语来描述, 但鉴于那些其他用法, 使用和解释该术语时应格外谨慎.

定位符: 提供访问资源之手段的标识符.

标识符系统: 受管理的名称集合. 本文档将 URN 上下文之外的标识符系统称为 "非 URN 标识符系统".

URN 命名空间: 与某个 URN NID 关联的标识符系统.

NID: 与某个 URN 命名空间关联的标识符.

NSS: URN 中特定于 URN 命名空间的部分.

Assigned-name: "urn:" 方案, NID 和命名空间特定字符串 (namespace specific string, NSS) 的组合. 因此, 如果某个 URN (如上文所定义) 包含任何附加组成部分, 那么 "assigned-name" 就是该 URN 的一个子串 (见第 2 节).

"name" 一词在此有意不予定义, 并且应当 (实际上也确实) 仅在非常非正式的场合使用. RFC 3986 将该词用作一种与 "locator" 相区分的 URI 类别 (第 1.1.3 节), 但也在其他上下文中使用它. 如果把这些用法当作定义性的, 它们就会与诸如 URN 命名空间名称 (即 NID) 的概念以及与同非 URN 标识符系统相关联的术语发生冲突.

本文档使用术语 "resource", "identifier", "identify", "dereference", "representation" 和 "metadata", 其含义大致如 URI 规范 [RFC3986] 中所定义.

本文档使用术语 "resolution" 和 "resolver", 其含义大致等同于它们在 URN 架构原则的原始讨论 [RFC2276] 中的用法, 即 "resolution" 是提供与被标识资源相关的服务的行为, 例如把持久 URN 转换为该资源的一个或多个当前定位符, 以适当的格式交付关于该资源的元数据, 或者甚至无需进一步中间环节就交付该资源的表示 (例如一份文档). 在撰写本文时, 解析服务描述于 [RFC2483].

关于表示与元数据之间的区别, 参见 [RFC3986] 第 1.2.2 节.

若干其他与 "normalization" 操作相关且不属于 Unicode 标准 [UNICODE] 的术语, 在此也按 RFC 3986 中的用法使用.

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 [RFC2119] 中的描述进行解释.

1.2. 设计权衡

与 URN 最初被考虑并概述其用途时 (见 [RFC1737]) 相比, 如今互联网上持久标识符的问题所涉及的基本设计权衡程度要大得多, 其范围远超 URN 或 URN 方法本身, 甚至触及信息科学界的开放研究问题. 关于在整个 URN 全域中应当做什么或要求什么的理想而全面的规范, 需要对一大类此类问题达成普遍共识并给出解决方案. 虽然其中一些问题是由互联网或计算机时代对字符编码和数据抽象的处理方式带来的, 另一些问题则比互联网和计算机系统早了数百年; 近期内不太可能就全面解决方案达成一致.

因此, 尽管本规范包含一些在更完美的世界中本不会有的要求和灵活性, 但为了产生一份提供 URN 现代化定义的共识性规范, 这是必要的 (另一个不那么有吸引力的选择是, 尽管已广泛部署却仍不使定义现代化).

以下小节更详细地描述其中两个相关问题.

1.2.1. 解析

一个 URN 特有 (相对于一般命名系统而言) 的问题是 "resolution" 这一相当困难的课题, 第 1.1 节, 第 2.3.1 节, 第 6.4.6 节以及下文其他地方都有讨论.

对于传统的统一资源定位符 (Uniform Resource Locator, URL), 也就是对于大多数作为定位符的 URI 而言, 解析相对直接, 因为它被用来确定一种访问机制, 该机制进而被用来解引用该定位符, 通常是检索所关联资源的表示, 例如一份文档 (见 [RFC3986] 第 1.2.2 节).

相比之下, URN 的解析更加灵活多样.

一个重要情形涉及把一个 URN 映射到一个或多个定位符. 在这种情况下, 最终结果仍然是把映射后的定位符解引用为一个或多个表示. 这里的主要区别在于持久性: 即使某个映射后的定位符发生了变化 (例如 DNS 域名易主, 而 URL 并未被修改以指向新的位置; 或者在一个更极端且假设性的情形中, DNS 被完全替换), 只要解析器保持其 URN 到定位符的映射是最新的, URN 使用者就能够获得正确的表示 (例如一份文档). 因此, 对于那些解析为定位符, 而这些定位符又被解引用为某个表示的 URN, 相关关系可以定义得相当精确.

然而, 本规范允许若干其他 URN 解析情形, 也允许用于不涉及信息检索系统的资源的 URN. 这既可以针对特定的 URN 单独成立, 也可以 (如下文所定义) 针对整个 URN 命名空间集体成立.

考虑这样一个 URN 命名空间: 其 URN 解析为定位符, 而这些定位符只能被解引用为关于资源的元数据, 因为底层系统不包含这些资源的表示; 一个例子可能是国际标准名称标识符 (International Standard Name Identifier, ISNI) 的 URN 命名空间, 该标识符系统在相关标准 [ISO.27729.2012] 中定义, 其中默认情况下 URN 只会被解析为一条描述由 ISNI 标识的公共身份的元数据记录.

再考虑这样一些 URN: 只有当请求方被授权获得表示时, 它们才解析为表示, 而其他方只能获得关于该资源的元数据; 一个例子可能是国家图书馆法定呈缴馆藏中保存的文档.

最后, 有些 URN 可能根本不打算解析为定位符; 例子可能包括标识 XML 命名空间名称的 URN (例如 [RFC6288] 规定的 "dgiwg" URN 命名空间), 标识可在某种通信协议内支持的应用程序特性的 URN (例如 [RFC7462] 规定的 "alert" URN 命名空间), 以及标识诸如注册表中取值这类枚举类型的 URN (例如, 可以像 [IANA-URN] 中初步提议的那样, 用一个 URN 命名空间来逐一标识所有 IANA 注册表中的取值).

各种类型的 URN 以及可能为其提供的多种解析服务, 使得 "resolution" 这一概念对 URN 而言比 "解析为某个定位符, 再由该定位符解引用为某个表示" 这一直接情形更为复杂, 但也丰富得多.

1.2.2. 字符集与编码

对于字符集和编码也存在一组类似的考虑. URN, 尤其是将用作面向用户的标识符的 URN, 应当便于在本地语言和书写系统中使用, 便于用各种各样的键盘和本地惯例指定, 并且不含歧义. 这些目标之间存在权衡, 而且目前无法看出如何能够制定出一套简单易懂的规则, 使其对所有 URN 而言都是最优的, 甚至是合理的. 第 2.2 节的讨论定义了一个总体框架, 它应当使通用化的解析和处理成为可能, 同时也对各个 URN 命名空间的规则提出了建议.