摘要

  • RFC 3368 给 go: 安排了两种用途：指向特定 CNRP 服务，或把常用名称查询交给客户端选择的服务。
  • 绑定服务器的 id= 链接可以指向一条记录，却不包含读者以为自己看到的名称。语法、注册状态和实际解析是不同证据。

2002 年 8 月，RFC 3368 为普通网页地址不容易解决的问题提出了一种链接：人们记住的是名称，而网络依靠标识符与服务来定位资源。go: 并没有让名称本身获得权威性；它规定的是客户端如何把 CNRP 查询带到某个服务。

差别就在冒号后面的字符。go://cnrp.example?Ada%20Lovelace 指定一台服务器，并向它提交查询。go:Ada%20Lovelace 不写服务器；RFC 3368 设想客户端把这种写法发送到一个或多个已配置的 CNRP 服务。同一个可见名称，因设备不同，可能会进入不同的服务集合。链接本身并不携带一份全球通用的解析服务目录。

RFC 3368 还赋予“只有服务器”的 URI 另一种含义：它标识的是 CNRP 服务，而不是某一次具体查询。客户端可以通过协议中的 servicequery 询问该服务支持什么。服务器部分为空时按本地主机处理；如果客户端不知道服务支持哪些传输方式，规范给出的默认方式是通过 1096 端口使用 HTTP。这些默认值让对话有了起点，却不能证明服务仍可访问、值得信任或仍在运行。

这种简洁是有意为之。CNRP 查询可以使用 XML 表示，但复杂 XML 放进 URI 会很快超过长度限制。RFC 3368 因此规定了更精简的名称和属性/值语法。它要求采用 UTF-8，并对不符合语法的字节进行百分号转义；示例把 ü 编码成 UTF-8 字节。正文里的短写法只是帮助理解，权威语法是 ABNF。

更重要的边界案例是 go://cnrp.example?id=5432345。这个 URI 指向特定服务器上的特定记录，却没有携带常用名称。RFC 3368 的安全章节提醒了这种错位：用户可能以为链接指的是当前映射到“BMW”的资源，但 URI 里并没有“BMW”这个名称。机器可读的标识符可以保持稳定，却仍然对被要求信任它的人不透明。

配套协议 RFC 3367 把解析服务提供方的发现与选择、名称注册、所有权和名称唯一性排除在最初范围之外。因此，RFC 3368 中客户端配置的服务集合仍是一项本地选择，并不是对“谁代表某个名称”的全球裁决。此后，IANA 的 URI 方案注册表把 go 标为 Permanent，参考文档为 RFC 3368。这证明了注册记录的状态，不证明浏览器支持、服务仍在运行、存在实际流量或获得采用。

这段历史真正划出的边界是：链接可以标识服务、查询或记录，但三者不能互换。Heng Lu 的“Reality Layers”和“Running-Code Primacy”在这里仅作为明确说明的编辑视角，用来区分语法、登记的设计和实际运行；它们不是协议要求，也不能证明 go: 曾被部署。

来源