4. URI 一致性
4.1. 在 URI 协议槽位中的使用
由于 URN 在语法上是 "urn" 方案下的一种 URI, 理论上 URN 可以被放入任何允许 URI 的协议槽位中 (仅举几例: HTML 中的 "href" 和 "src" 属性, HTML 中的 base 元素, XML 中的 "xml:base" 属性 [XML-BASE], 以及 XML 中用于 XML 命名空间名称的 "xmlns" 属性 [XML-NAMES]).
然而, 这并不意味着从语义上讲, 在实践中把 URN 放入某个给定的 URI 协议槽位总是合理的; 特别是, 由于 URN 可能并不指定资源的位置, 甚至并不间接指向某个资源, 因此把 URN 放入指向资源的 URI 协议槽位 (例如前述 "href" 和 "src" 属性) 可能并不恰当.
归根结底, 关于何时适合使用 "urn" 方案 (或任何其他方案) 下的 URI 的准则, 属于各个 URI 协议槽位规范的责任 (例如, XML 中 "xml:base" 属性的规范可能会建议在该协议槽位中使用 URN 并不恰当). 本规范不可能预见到所有相关情形, 而且要求或限制各个协议槽位的用法也不是本规范的职责所在.
4.2. 语法分析
部分由于 URN 语义与更通用的 URI 语法相分离, 通用 URI 处理器需要特别注意 RFC 3986 的解析和分析规则, 尤其是必须把 URI 视为不透明的, 除非该方案及其要求被识别. 在后一种情况下, 此类处理器可以调用适合该方案的处理, 例如由 URN 解析器进行处理. URN 解析器既可以是 URI 解析器所知的外部解析器, 也可以是内建于 URI 解析器中的功能. 请注意, 这一要求可能会对恰当使用 URN 的上下文施加约束; 见第 4.1 节.
4.3. URN 与相对引用
[RFC3986] 第 5.2 节描述了一种算法, 用于把可能相对于某个给定基础 URI 的 URI 引用转换为该引用目标的 "已解析组成部分", 然后可以按 RFC 3986 第 5.3 节重新组合为目标 URI. 这一算法对 URN 而言是有问题的, 因为 URN 的语法不支持所需的路径组成部分. 然而, 如果该算法独立于特定方案来应用, 那么它应当也能对 URN 可预测地工作, 并有以下几点理解 (语法产生式术语取自 RFC 3986):
-
遇到遵循 <relative-ref> 语法的 <URI-reference> 的系统, 无论它是否显式带有 "urn" 方案, 都会按 RFC 3986 的规定将其转换为目标 URI.
-
由于 URN 的持久性和稳定性预期, 使用 URN 的文档作者等通常应当避免在任何并非严格符合 RFC 3986 所规定 <URI> 的 <URI-reference> 中使用 "urn" 方案, 特别是包括那些需要处理 <relative-ref> 的情形.
4.4. 传输与显示
在 URN 被传输和交换时, 必须 (MUST) 以本文所定义的格式表示它们. 此外, 强烈鼓励了解 URN 的应用程序提供以此规范形式显示 URN 的选项, 以便可以直接转录 (例如通过复制粘贴技术). 此类应用程序可能支持以更便于人阅读的形式显示 URN, 并可能使用包含本规范所定义的 URN 语法不允许的字符的字符集 (例如, 在向人显示 URN 时, 此类应用程序可能会用来自 Unicode [UNICODE] 等扩展字符集的字符替换百分号编码字符串).
为尽量减少用户困惑, 任何显示 URI 的应用程序都应当 (SHOULD) 显示完整的 URI (对于 URN, 包括 "urn" 方案和任何组成部分), 以确保不会在 URN NID 与 URI 方案标识符之间产生混淆. 例如, 以 "urn:xmpp:" 开头的 URI [RFC4854] 与以 "xmpp:" 开头的 URI [RFC5122] 非常不同. 类似地, 一个可能的数字对象标识符 (Digital Object Identifier, DOI) URI 方案 [DOI-URI] 与一个可能的 DOI URN 命名空间不同, 而且可能完全无关.
4.5. URI 设计与所有权
如前所述, URN 命名空间内 URN 的分配是一个受管理的过程, URN 命名空间本身的分配也是如此. 尽管本规范把某个给定 URN 命名空间内待分配 URN 的设计让渡给了该 URN 命名空间管理者, 但以受管理的方式进行设计可以避免关于 URI 设计与所有权的建议 [RFC7320] 中所述的, URI 不受管理地生成所固有的问题.