摘要

  • RFC 3367 将语言、地理位置和类别纳入通用查询属性，但把它们定义为“提示”，而非必须满足的筛选条件。
  • 协议统一了问题的表达方式；匹配规则、结果排序和相关性的实际含义仍由每个服务掌握。

名称并不等于唯一答案

普通名称是词语或短语，不是全球唯一标识。“Mercury”可以指行星、企业、个人或产品；同一服务也可能为一个名称返回多条记录。RFC 3367 处理的是一个有限问题：客户端如何向服务查询与某个普通名称相关的记录。它没有规定服务发现与选择、名称注册、所有权或唯一性。因此，CNRP 是查询协议，不是命名权威。

共享词汇，不共享判断

协议提供的不只是一个名称字符串。核心查询属性包括普通名称、语言、地理位置、类别和结果范围。客户端可以先发送 ServiceQuery，了解服务支持哪些属性；服务也能公布自己的扩展数据类型。

但 RFC 3367 没有把这些字段变成全球统一的判定规则，而称它们为“提示”：由客户端提供的偏好和上下文。字段顺序可以表示优先级，服务仍可忽略这些提示，并尝试给出最匹配的结果。不同属性之间按逻辑 AND 组合，同一属性的多个值按 OR 组合。即便如此，返回结果也不必满足全部条件。“英语”和“伦敦”可以影响搜索，却不必排除所有不完全符合的记录。

最关键的设计边界正在这里：查询格式可以互操作，答案却仍由各服务分别决定。有的服务可能高度看重语言，有的可能只把它当作弱信号。RFC 没有规定统一权重公式，也没有定义通用的并列结果裁决方式。

编码解决不了语义

UTF-8 让文本能够交换，语言标签则提供结构化语言标识。但两者都不能决定不同拼写、文字体系、转写或名称是否指向同一对象。RFC 3367 把普通名称的等价与匹配规则留给具体服务和语言。字符编码保留字符串，却不会替字符串决定含义。

排序同样属于服务本地。一个服务可以依自己的相关性判断排列结果；不同服务的结果不会仅仅因为使用 CNRP 就拥有可比较的统一顺序。配套的 RFC 3368 定义了 go: URI，可指向特定服务或记录，也可表达更宽泛的查询，但并未消除这种职责划分。

互操作性的边界

RFC 3367 统一了偏好的表达、能力查询和字段组合的大体逻辑，把语义等价与最终排序留给服务运营者。这不是藏在脚注里的疏漏，而是协议的设计边界。共用词汇可以让系统对话，却无法让它们的判断自动一致。

借用 Lu Heng 关于运行代码优先的分析视角，这一区分很有帮助，但范围有限：规范描述实现可以交换什么，用户实际遇到的行为仍取决于服务如何实现。RFC 本身不能证明部署规模或商业影响。这里值得记录的历史变化更窄：偏好可以跨服务传递，相关性却仍留在服务本地。

来源