摘要

  • THTTP 将 URN 解析服务的请求与回复放进 HTTP 1.0 或 1.1 的常规交换中。
  • 一个 HTTP 回复可以给出位置或字节，但它本身不证明命名空间分配、解析器授权、内容完整性、访问许可或长期可取得性。

RFC 2169 的“Trivial”并非轻视解析，而是在限定协议责任。1997 年的实验文本让已有 HTTP 服务器通过 CGI 等扩展处理一个 URN 和所请求的服务。这样做降低了部署门槛，也保留了替换更复杂解析协议的空间。

文中区分 N2L（从 URN 得到 URL）与 N2R（得到被命名资源）。状态码、格式协商和缓存仍采用 HTTP 的普通规则。这一机制最多说明：客户端选择的端点在某个时间以某种方式回应了请求。它不把端点变成命名空间的管理者，也不把 Location 头变成名称所有权凭证。

RFC 2141 已经把语法和词法等价与功能等价分开。URN 可被规范化；两个名称是否真正指向同一对象，由各命名空间的规则决定。RFC 2169 要求词法等价的 URN 得到同样结果，却没有指定全球唯一解析器或资源权威。

因此，一次可见的 HTTP 交易必须按层解释。200 仅证明该服务器作出了成功回应；重定向仅提供一个位置；N2R 可能交付内容。它们都不能单独证明名称已被正当分配、端点仍受委托、内容未被篡改、客户端享有访问权，或其他解析器会作出相同回答。

后来的 RFC 3406 把 URN 分配描述为受管理过程，并指出全球解析需要独立注册机制。IANA 依据 RFC 8141 维护的 URN 命名空间登记表，是命名空间管理的证据，而不是对某台历史 HTTP 解析器的持续背书。

RFC 2169 留下的历史价值，是让熟悉的传输方式服务于一个边界清晰的角色，而不假装解决其外部的权威问题。

来源与证据限度

事实依据为 RFC 2169、2141、1737、3401、3406、8141 及 IANA 登记表。它们不能证明 THTTP 的普遍部署，也不能证明任何今天端点对某个 URN 的权威性。