摘要

  • RFC 3650 的全局名称空间是联邦式的：唯一命名机构加上该机构下唯一的本地名称，构成系统内唯一的 Handle；既有本地名称和取值绑定可以保留。
  • 全局 Handle 注册处（GHR）主要提供命名机构及服务信息，帮助客户端找到负责的 Handle 服务；本地 Handle 服务（LHS）通常解析其命名机构下的 Handle。

全球名称不必来自全球数据库

RFC 3650 讨论的不只是如何拼写一个持久标识符。更棘手的问题是：不同的命名空间和管理主体，怎样共享一个全局名称框架，却不必把每条资源记录交给同一个运营者？它的设计把名称、管理权威和服务发现分开处理。

一个 Handle 由命名机构（也叫前缀）和本地名称（也叫后缀）组成。命名机构在 Handle 系统中唯一；本地名称在所属机构下唯一。两者结合，才使 Handle 在该系统内具有全局唯一性。既有本地命名空间可以取得唯一机构标识加入，同时保留原来的本地名称及其取值绑定。因此，“全球”指共享的唯一性范围，而不是一个统一管理的数据库。RFC 3650

服务架构沿用了这种分工。RFC 3650 将全局 Handle 注册处（GHR）设为层级顶端，其下是本地 Handle 服务（LHS）。命名机构的 Handle 带有服务信息——包括站点和服务器接口——让客户端知道该去哪里访问“归属”服务。客户端先向 GHR 查询这份信息，再联系负责目标 Handle 的服务。注册处像一张服务责任地图；它并不因此成为所有本地值的唯一存储处。RFC 3650 · RFC 3651

这里的“本地”说的是命名空间和管理责任，不是地理位置。一项 LHS 服务可以在互联网各处部署多个站点，每个站点也可包含多个服务器。RFC 描述了复制与多站点的架构选项，但这不是任何特定部署已经达到某种可用性或容错指标的证据。

注册树并不自动构成指挥链

命名机构可以按树形登记。父级必须先注册，才能登记子级；但 RFC 3650 明确区分了登记顺序和管理权限：父子命名空间可以由不同服务提供，也可能互不共享管理权限。树形关系本身无法说明谁有权修改子级 Handle、处理争议或保障服务持续运行。RFC 3650

GHR 也不是完全不接触单个 Handle 的纯目录。RFC 3650 说它可以管理任何 Handle 命名空间；RFC 3651 也允许它管理、解析或管理某些非命名机构 Handle。更准确的表述是：GHR 的独特职责在于管理命名机构 Handle 及其服务信息；通常，本地服务负责被委托给自己的命名空间。RFC 3651

Handle 对应的值可以变化，而 Handle 本身保持不变，从而更新资源位置或其他关联信息。不过，标识符的语法并不保证永久有效。RFC 3650 指出，持久性取决于管理者是否持续维护。一个稳定字符串无法强迫机构保留记录、运行解析服务或保持目标资源可访问。RFC 3650

与其他标识体系相邻，但不等同

RFC 将 Handle 放在互联网命名体系的背景中讨论，却没有把它们混为一谈。DNS 通过区域委派组织名称与解析。URN 规范关注独立于位置的资源名称；如何发现并联系解析服务，则是另一个问题。Handle 可以用于需要持久名称或解析服务的应用，但它不会自动成为 URN；一次 Handle 查询成功，也不证明资源本身可达。RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

发布状态同样重要。RFC 3650 是 Informational 文档，不是互联网标准。IESG 注释说，IETF 与 IRTF 的多个小组曾讨论 Handle 系统，但尚未就该设计或它在 IETF 标识符架构中的位置形成 IETF 共识。这既不是认可，也不是驳回；它划出的是已发布架构提案与机构共识之间的界线。RFC 3650

这项历史设计的重点，是功能如何分布：根注册处告诉客户端每个命名机构由哪个服务负责，而相互独立管理的服务可以持有并解析各自的命名空间。这个机制能否持续发挥作用，仍取决于组成服务地图的记录、运营者和网络路径。RFC 描述了边界如何衔接，却没有证明任何名称都能被全球解析、永久可用、广泛部署，或一定能访问所指资源。

来源：RFC 3650；RFC 3651；RFC 3652；RFC 1737；RFC 2276；RFC 3406；RFC 8141；RFC 3986；RFC 1034。