跳到主要内容

5. URN 命名空间

URN 命名空间是遵循三项约束的名称集合: 每个名称都是 (1) 唯一的, (2) 以一致的方式分配的, 并且 (3) 按照共同定义分配的.

  1. "唯一性" 约束意味着 URN 命名空间内的某个名称绝不会被分配给一个以上的资源, 也绝不会被重新分配给另一个不同的资源 (就由该 URN 命名空间内分配的 URN 所标识的那类 "资源" 而言). 即使该名称本身被弃用或变得过时, 这一点依然成立.

  2. "一致分配" 约束意味着 URN 命名空间内的某个名称由一个组织分配, 或者按照始终被遵循的过程或算法创建.

  3. "共同定义" 约束意味着对于 URN 命名空间内名称的语法以及对于分配或创建这些名称的过程都有清晰的定义.

URN 命名空间由某个特定的 NID 标识, 以确保 URN 的全局唯一性, 并且可选地提供关于该 URN 命名空间内所分配 URN 结构的提示.

就全局唯一性而言, 为不同的名称集合使用不同的 NID 可确保对于不同的资源不会出现两个相同的 URN, 因为每个集合都被要求唯一地分配每个名称. 然而, 单个资源可以 (MAY) 被分配一个以上的 URN, 无论是在同一个 URN 命名空间内 (如果该 URN 命名空间允许) 还是在不同的 URN 命名空间内, 也无论是出于相似目的还是不同目的. (例如, 如果某出版商为一份电子出版物分配了一个 ISBN [RFC3187], 而该出版物后来被并入某国家图书馆运营的数字长期档案馆, 该图书馆可能会为该出版物分配一个国家书目编号 (national bibliography number, NBN) [RFC3188], 从而产生两个指向同一本书的 URN.) 在诸如 URI 语法 [RFC3986] 所施加的其他约束的范围内, URN 方案的规则旨在允许在把非 URN 标识符系统中规定的名称当作 URN 处理时保留其正常而自然的形式.

就 URN 命名空间内所分配名称的结构而言, 命名结构 (以及由此而来的名称集合) 的制定取决于定义这些名称的社区的要求, 名称将如何被分配和使用等等. 这些问题超出了 URN 语法和 URN 命名空间一般规则的范围, 因为它们特定于定义某个非 URN 标识符系统或某个特定 URN 命名空间的社区 (例如, 就 "ISBN" URN 命名空间 [RFC3187] 和 "ISSN" URN 命名空间 [RFC3044] 而言是书目和出版社区, 或者就 "XMPP" URN 命名空间 [RFC4854] 而言是可扩展消息与存在协议 [RFC6120] 扩展的开发者).

由于冒号字符 (":") 被用来把 "urn" 与 NID 分隔开, 并把 NID 与 NSS 分隔开, 人们很容易把整个 URN 想象成由冒号字符构建出结构, 并假定冒号在 URN 的 NSS 部分内创建了某种结构或层级. 这样的结构可以由某个特定的 NID 规范来规定, 但不存在隐含的结构. 在诸如以下的 URN 中

urn:example:apple:pear:plum:cherry

NSS 字符串整体上就是 "apple🍐plum:cherry", 除非 "example" 命名空间的规范中描述了某种含义, 否则该 NSS 字符串内的冒号字符没有特定含义.

URN 命名空间因其 URN 的性质而继承某些权利和责任, 特别是:

  1. 它们通过提供资源的持久标识, 以及按照共同定义唯一地分配名称, 来维护管理良好的 URN 命名空间的一般原则.

  2. 可选地, 它们可以在诸如 [RFC2483] 中所述的全球注册服务中注册.

URN 命名空间有两类: 正式的和非正式的. 它们的区别在于预期的服务水平, 定义该 URN 命名空间所需的信息, 以及注册程序. 由于迄今为止注册的 URN 命名空间大多数是正式的, 本文档着重讨论正式 URN 命名空间.

5.1. 正式 URN 命名空间​

正式 URN 命名空间为互联网上某一部分用户带来益处. 特别是, 如果一个正式 URN 命名空间只被未连接到互联网的社区或网络使用, 那就不合理了. 例如, 如果一个 URN 命名空间实际上强迫某人使用不向一般互联网用户开放的专有网络或服务, 那就不恰当了. 其意图是: 尽管可能主动使用该 URN 命名空间内所分配 URN 的社区可能很小, 但该 URN 命名空间内名称的潜在使用对互联网上的任何用户都是开放的. 即使某些方面并非完全开放, 正式 URN 命名空间也可能是恰当的. 例如, 某个 URN 命名空间可能使用基于收费的, 私营管理的或专有的注册表来分配该 URN 命名空间内的 URN. 然而, 如果相关联的服务公开公布了名称, 它仍可能使某些互联网用户受益.

将在某个正式 URN 命名空间内分配 URN 的组织应当 (SHOULD) 满足以下标准:

  1. 组织的稳定性以及长期维护该 URN 命名空间的能力; 如果没有此类证据, 则应当明确在该组织不再能维护该 URN 命名空间时, 该 URN 命名空间如何能够继续存续.

  2. 在 URN 分配方面的胜任能力. 这会提高持久性的可能性 (例如, 尽量减少发生冲突的可能性).

  3. 承诺不重新分配现有 URN, 并允许旧 URN 继续有效 (例如, 如果某个 URN 的受分配方不再是分配组织的成员或客户, 如果关于受分配方或所命名实体的各种信息恰好发生变化, 或者甚至如果受分配方或所命名实体本身已不复存在; 在所有这些情况下, 该 URN 仍然有效).

正式 URN 命名空间确立一个特定的 NID, 但须遵守以下约束 (这些约束是在已经规定的语法规则之外附加的):

  1. 它禁止 (MUST NOT) 是已经注册的 NID.

  2. 它禁止 (MUST NOT) 以 "urn-" 开头 (该前缀保留给非正式 URN 命名空间).

  3. 它的长度必须 (MUST) 超过两个字符, 并且禁止 (MUST NOT) 以 ALPHA ALPHA "-" 开头, 即禁止以任何由两个字母后跟一个连字符组成的字符串开头; 此类字符串保留供将来国家注册 URN 命名空间时可能用作基于 ISO alpha-2 国家代码 [ISO.3166-1] 的 NID (然而, 此类基于国家代码的 URN 命名空间的责任分配规则的定义和范围界定超出了本文档的范围). 因此, 它禁止 (MUST NOT) 以字符串 "xn--" 或任何其他由两个字母后跟两个连字符组成的字符串开头; 此类字符串保留供将来可能表示 DNS A-label 及类似字符串之用 [RFC5890].

  4. 它禁止 (MUST NOT) 以字符串 "X-" 开头, 以免与 [RFC3406] 先前允许的任何实验性 URN 命名空间相混淆或冲突.

考虑新 NID 的申请人和审查者也应当意识到, 这些 NID 可能具有语义上的影响, 从而成为冲突之源. 应当特别注意那些可能被解释为国家的标识符 (包括 ISO 3166-1 alpha-3 代码) 或在该国权威之下注册的字符串, 以及那些可能暗示与现有 URI 方案, 非 URN 标识符系统或商标有关联的字符串. 然而, 按照传统政策, 关于特定字符串 "所有权" 的争议是相关各方之间的分歧; 除响应有管辖权的法院的命令之外, IANA 和 IETF 都不会介入此类争议.

5.2. 非正式 URN 命名空间​

非正式 URN 命名空间是完全意义上的 URN 命名空间, 拥有所有相关的权利和责任. 非正式 URN 命名空间与正式 URN 命名空间的区别在于分配 NID 的过程: 对于非正式 URN 命名空间, 注册者不指定 NID; 相反, IANA 分配由字符串 "urn-" 后跟一个或多个数字组成的 NID (例如 "urn-7"), 其中数字由分配给非正式 URN 命名空间的正整数序列中的下一个可用数字构成. 因此, 非正式 URN 命名空间标识符的语法是:

InformalNamespaceName = "urn-" Number
Number                = DigitNonZero 0*Digit
DigitNonZero          = "1"/ "2" / "3" / "4"/ "5"
                      / "6" / "7" / "8" / "9"
Digit                 = "0" / DigitNonZero

对 <Number> 的唯一限制是它 (1) 严格由 ASCII 数字组成, (2) 没有前导零, 并且 (3) 不会使 NID 超出为 URN 语法定义的长度限制 (见第 2 节).