2.2. Namespace Specific String (NSS, 命名空间特定字符串)

NSS 是在某个 URN namespace 内唯一的字符串, 它以一致方式分配和管理, 并符合相关 URN namespace 的定义. NID (在整个 "urn" scheme 中唯一) 与 NSS (在 URN namespace 内唯一) 的组合确保生成的 URN 具有全局唯一性.

本文档规定的 NSS 允许使用早期规范不允许的若干字符 (见附录 B). 特别是现在允许使用 "/" 字符, 这实际上使封装来自 non-URN identifier system 的层次化名称成为可能. 例如, 假设存在一个层次化 identifier system, 其中名称采用由 "/" 字符分隔的一串数字形式, 如 "1/406/47452/2". 如果此类名称的权威机构要使用 URN, 自然做法就是把现有名称放入 NSS, 从而得到类似 "urn:example:1/406/47452/2" 的 URN.

这些对 NSS syntax 的变更不会修改按照 [RFC2141] 定义的 URN namespace 的编码规则. 如果任何此类 URN namespace 的名称也在 URN 上下文之外使用 (即在 non-URN identifier system 中使用), 并且该 identifier system 的原生形式也允许使用 "/", "~" 或 "&", 则该 URN namespace 的编码规则不因本规范而改变.

根据 non-URN identifier system 及其关联 URN namespace 的规则, 在该 identifier system 中有效的名称可能包含上文引用的 "pchar" 产生式不允许的字符 (例如 ASCII 范围之外的字符, 或者与 RFC 3986 限制一致的字符 "/", "?", "#", "[" 和 "]"). 虽然这样的名称在 non-URN identifier system 内可能有效, 但在被转换为符合特定 URN namespace 规则的 NSS 之前, 它并不是有效 URN. 对于由 non-URN identifier system 中独立存在的名称形成的 URN, 将名称从其 "native" 格式转换为 URN 格式, 需要使用为一般 URN 定义的 canonicalization 和编码方法, 或使用该 URN namespace 的特定规则. 不知道 namespace-specific canonicalization 和编码规则的软件 MUST NOT 从 non-URN identifier system 中的名称构造 URN.

特别是对于 ASCII 范围之外的字符, 出现在协议中或在系统之间传递的 URN MUST 只使用以 UTF-8 编码的 Unicode 字符, 并进一步按照 RFC 3986 要求进行编码. 在可行且符合其他地方定义和标准化的名称要求以及第 1.2 节讨论原则的范围内, 用于表示名称的字符 SHOULD 限制为 ASCII 字母和数字, 或限制为某些广泛使用模型的字符和语法, 例如 Internationalizing Domain Names in Applications (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) [RFC7613], 或 Unicode Identifier and Pattern Syntax 规范 [UAX31].

为了在协议演进及周围环境变化时使 URN 尽可能稳定和持久, URN namespace SHOULD NOT 允许 ASCII 范围 [RFC20] 之外的字符, 除非特定 URN namespace 的性质使此类字符成为必要.