跳到主要内容

6. URN 命名空间的定义与注册

6.1. 概述​

由于 URN 命名空间的空间本身是受管理的, URN 命名空间的定义应当 (SHOULD) 特别注意以下方面:

  1. 该 URN 命名空间的用途.

  2. 该 URN 命名空间内所分配 URN 的语法, 包括 r-component 或 q-component 的内部语法和预期效果. (f-component 的语法和解释在 RFC 3986 中定义.)

  3. 该 URN 命名空间内分配 URN 的过程.

  4. 在该 URN 命名空间内分配 URN 以及使用所分配 URN 的安全影响.

  5. 该 URN 命名空间内所分配 URN 的任何潜在互操作性问题.

  6. 可选地, 解析该 URN 命名空间内所分配 URN 的过程.

关于填写模板的一节 (第 6.4 节) 更详细地解释了这些事项. 尽管在所有情况下注册模板都相同, 但根据注册来源的不同, 所用的程序略有差异.

6.2. 注册政策与流程: 社区注册​

URN 命名空间的基本注册政策是 IANA 考虑事项文档 [RFC5226] 中所定义的专家评审 (Expert Review). 对于打算成为标准或标准组成部分的 URN 命名空间或其定义, 专家评审过程的输出应当是报告, 而不是指示 IANA 采取行动的指令 (见下文). 关键步骤如下:

  1. 填写 URN 命名空间注册模板 (见第 6.4 节和附录 A). 这可以作为互联网草案或另一系列的规范的一部分来完成, 尽管这并不是一项要求.

  2. 把填写完成的模板发送到 [email protected] 讨论列表进行评审.

  3. 如果有必要处理收到的意见, 重复步骤 1 和步骤 2.

  4. 如果指定专家 (Designated Expert) 批准该请求且不涉及标准化行动, IANA 将注册所请求的 NID. 如果预期会标准化, 指定专家将编写一份报告并将其转交给适当的标准批准机构 (就 IETF 而言是 IESG); 只有在收到该机构的指示以及专家评审报告的副本之后, IANA 才会注册所请求的 NID.

URN 命名空间注册可以通过更新注册模板来修订, 遵循上文为新注册所列出的相同步骤. 修订后的注册必须 (MUST) 描述与先前版本的差异, 并应当 (SHOULD) 特别说明底层技术或 URN 命名空间管理过程中的任何相关变化.

迄今为止在 URN 命名空间注册请求方面的经验表明, 注册者有时起初并不理解 URN 命名空间的一些微妙之处, 而以规范的形式定义 URN 命名空间能使注册者清晰地表述其与目标用户社区之间的 "契约". 因此, 尽管正式 URN 命名空间的注册政策是专家评审, 并且规范 (与注册模板不同) 并非严格要求, 但注册者应当 (SHOULD) 提供一份稳定的规范, 记录该 URN 命名空间的定义并展开论述本文所述的问题.

由于命名可能困难且容易引发争议, 强烈鼓励 URN 命名空间注册者和指定专家本着善意与相互理解的精神共同协作, 以就处理注册请求达成大致共识 (见 [RFC7282]). 如果在提供视角或以其他方式解决问题方面有所帮助, 也鼓励他们引入额外的专业知识参与讨论.

尤其是在注册过程中的反复迭代持续较久时, 预期指定专家会采取合理的预防措施, 以避免在所提议的 NID 上出现 "竞态", 并且如果出现此类情况, 会鼓励申请人自行解决彼此之间的任何冲突.

6.3. 注册政策与流程: 面向标准制定组织, 科学学会及类似机构的快速通道​

IETF 认识到会出现这样的情况: 创建 URN 命名空间是为了内嵌现有且已确立的标准 (尤其是标识符标准), 或者反映完全超出 IETF 范围或其指定专家可能具备的主题知识范围的知识, 术语或信息组织方法. 在注册请求来自某个被认可的标准制定组织, 科学学会或其指定代表, 或者得到其授权的情况下, 可以由该机构选择采用一种略有不同的程序:

  1. 按第 6.2 节步骤 1 和步骤 2 的方式填写并提交 URN 命名空间注册模板.

  2. 要求提供一份规范, 以体现或指向所需的外部标准或规范. 并不期望在 RFC 系列中发表或通过 IETF 流程发表 (例如作为互联网草案发布), 只有在非常特殊的情况下这样做才是恰当的.

  3. 讨论列表上的评审以及指定专家的评审严格来说只具咨询性质, 关于接受哪些建议以及为该过程分配多长时间的决策, 完全由该外部机构掌控.

  4. 当该机构认定申请已足够成熟时, 其代表将请求 IANA 完成该 NID 的注册, IANA 将照此办理.

关于是否把请求方认定为标准制定组织或科学学会的决定, 是 IESG 的责任.

对于希望注册媒体类型的被认可标准制定组织, 已经定义了一种与此类似的模式. 描述该机制的文档 [RFC6838] 提供了关于这种总体做法的更多信息.

6.4. 填写模板​

附录 A 提供了用于定义和注册 URN 命名空间的模板. 本节描述填写该模板时的考虑事项.

6.4.1. 用途​

模板的 "用途" 一节描述诸如以下事项:

  1. 由该 URN 命名空间内所分配 URN 标识的资源种类.

  2. 该 URN 命名空间内所分配 URN 的范围和适用性; 这可能包括关于使用社区的信息 (例如某个特定的国家, 行业, 技术或组织), 所分配的 URN 将用于公共网络还是私有网络等等.

  3. 目标社区 (以及整个互联网社区) 将如何从使用或解析所分配的 URN 中获益.

  4. 该 URN 命名空间如何与现有的 URN 命名空间, URI 方案和非 URN 标识符系统相关并对其形成补充.

  5. 能够使用或解析所分配 URN 的软件应用程序种类 (例如, 通过区分各不相同的 URN 命名空间, 以持久的方式标识资源, 或者有意义地解析并访问与该 URN 命名空间相关联的服务).

  6. 解析服务是否可用或将会可用 (以及如果可用, 这些服务的性质或身份). 在此提供 q-component 以及 (在它们被标准化之后) r-component 的语义和语法的例子是有帮助的, 即使详细定义在别处或稍后给出.

  7. 该 URN 命名空间或其定义是否预期会成为在 IETF 或某个其他被认可的标准机构中正在制定的某项标准的组成部分.

6.4.2. 语法​

模板的 "语法" 一节包含:

  1. 对该 URN 命名空间内 URN 结构的描述, 需符合基本 URN 语法. 该结构可以用形式化定义 (例如使用 ABNF [RFC5234]), 生成符合规范 URN 的算法, 或用于把名称解析为各构成部分的正则表达式来描述; 或者, 该结构也可能是不透明的.

  2. 对所分配 URN 的任何特殊字符编码规则 (例如, 引号应当始终使用哪个字符).

  3. 用于确定该 URN 命名空间中两个名称之间 URN-Equivalence 的规则. 此类规则应当始终具有消除本来可能由比较产生的假阴性的效果. 如果恰当且有帮助, 可以引用 URI 规范 [RFC3986] 中定义的特定等价规则或本文档第 3 节. URN-Equivalence 规则的例子包括 NSS 中大写与小写字符之间的等价, 名称中带连字符与不带连字符的分组之间的等价, 或单引号与双引号之间的等价. 也可能存在命名空间特定的特殊编码考虑, 尤其是对于包含来自非 URN 标识符系统的名称内嵌形式的 URN. (请注意, 这些并不是关于一般字符间关系处理之任何最佳实践的规范性陈述; 此类陈述仅限于某一个特定的 URN 命名空间.)

  4. 为符合 URN 语法所需的任何特殊考虑. 这尤其适用于在 URN 上下文中使用的现有非 URN 标识符系统. 例如, 如果某个非 URN 标识符系统在 URN 之外的上下文中使用, 它可能会使用 URN 语法中保留的字符. 本节应当指出任何此类字符, 并概述为符合 URN 语法所需的映射. 通常, 这会通过按 URI 规范 [RFC3986] 第 2.1 节所述以及本规范第 1.2.2 节所讨论的方式对该字符进行百分号编码来处理.

  5. 在本 URN 命名空间的上下文中, 关于 q-component (例如关键词) 或 f-component (例如预定义术语) 含义的任何特殊考虑.

6.4.3. 分配​

模板的 "分配" 一节描述诸如以下事项:

  1. 把 URN 分配给资源的机制或权威机构. 它应当明确分配是完全开放的 (例如遵循先到先得 (first-come, first-served, FCFS) 这样的特定程序), 完全封闭的 (例如针对某个私营组织), 还是以各种方式受限的 (例如委托给由某个特定组织认可的权威机构); 如果受限, 它应当解释如何成为名称的分配者, 或者如何向现有的分配权威机构请求分配名称.

  2. 确保该 URN 命名空间内 URN 唯一性的方法. 例如, 名称可能由单一权威机构按顺序或按照某种定义良好的过程分配; 分配可能被划分给多个被委托的权威机构, 各自负责遵守唯一性规则; 或者 URN 可能按照某种本身即保证唯一性的算法独立创建.

6.4.4. 安全与隐私​

模板的 "安全与隐私" 一节描述与该 URN 命名空间内名称的分配, 使用和解析有关的任何潜在安全与隐私问题. 此类问题的例子包括:

  • 在为 URN-Equivalence 进行比较时产生假阴性和假阳性的后果 (见本规范第 3.1 节以及 "Issues in Identifier Comparison for Security Purposes" [RFC6943]).

  • 在公共互联网上传递名称时私有信息的泄露.

  • 目录采集 (directory harvesting) 的可能性.

  • RFC 中的安全考虑编写指南 [RFC3552] 以及互联网协议的隐私考虑 [RFC6973] 中讨论的各种问题. 特别要注意全球移动通信系统协会 (Global System for Mobile Communications Association, GSMA) / 国际移动台设备标识 (International Mobile station Equipment Identity, IMEI) 命名空间 [RFC7254] 的隐私考虑文本, 它可能为此类情况提供一个有用的范例.

6.4.5. 互操作性​

"互操作性" 一节必须 (MUST) 说明与互操作性有关的任何已知潜在问题. 例子包括由于语法 (例如某些字符的百分号编码) 或范围 (例如关注领域重叠) 而可能与其他 URN 命名空间, 非 URN 标识符系统或 URI 方案产生的混淆. 如果完全可行, 在注册某个 URN 命名空间期间出现的关切 (例如由于某个非 URN 标识符系统的语法或范围) 应当作为注册过程的一部分或与注册过程并行地加以解决.

6.4.6. 解析​

"解析" 一节必须 (MUST) 说明是否为该 URN 命名空间内所分配的 URN 打算采用或预期采用解析机制.

如果打算采用解析, 那么本节应当 (SHOULD) 说明在该 URN 命名空间内分配 URN 的组织是否打算运营或推荐针对该 URN 命名空间内 URN 的任何解析服务. 此外, 如果该分配组织打算为公开宣传的解析服务实现注册 (例如使用本着 URN 解析的原始架构原则和服务描述 [RFC2276] [RFC2483] 的精神而开发的系统), 那么本节应当 (SHOULD) 列出或引用被该分配组织公开宣传的要求. 此外, 本节应当 (SHOULD) 描述在本 URN 命名空间的上下文中处理 r-component 的任何特殊考虑.

6.4.7. 附加信息​

"附加信息" 一节包含对试图理解本注册或其与其他注册之关系的人有用的信息, 例如与可能看似重叠的现有 URN 命名空间进行的比较.

模板的这一节是可选的.