摘要

  • RFC 3404 把 URI 解析定义为带类型的请求：I2L、I2R、I2C 与 I2N 分别索取位置、资源实例、描述与持久名称；单数与复数形式还保留了结果数量的差别。
  • S、A、U 表达 DDDS 结束后下一步使用什么表示；P 则把控制权交给 DDDS 之外的应用专属过程。发现解析器不等于认证解析器，也不等于验证返回资源。

解析器最危险的状态有时不是报错，而是没有说明含义的“成功”。如果调用者要一份作品的描述，系统却给出一个可能下载到副本的位置，传输没有失败，但问题已经被替换。如果调用者要资源本身，返回的元数据再准确也不是同一件事。

RFC 3404 于 2002 年 10 月以标准轨规范发布，定义 DDDS 中的 URI 与 URN 解析应用。它属于五份相互分工的文件：RFC 3401 介绍体系，RFC 3402 给出算法，RFC 3403 把规则装进 DNS NAPTR，RFC 3404 规定解析应用，RFC 3405 则安排 uri.arpa. 与 urn.arpa. 的管理结构。

流程从应用唯一字符串开始。通用 URI 解析先把绝对 URI 规范化并编码，再以 scheme 作为 First Well Known Key，把它接到 uri.arpa. 下查询。URN 解析用 Namespace Identifier 作为键，并进入 urn.arpa.。NAPTR 规则随后反复改写或委派，直到产生终端结果，或者把处理交给另一个系统。

URI 与 URN 两个应用在技术上相同，运行上却刻意分开。URN 已经拥有捷径式解析模型，不应把自身部署成败绑定在通用 URI 解析是否被所有 scheme 接受上。分别设置已知键，使一个命名空间可以先提供实际能力，而不用等待全网达成更大的采用决定。

真正保存答案类型的是 Services 字段。I2L 返回一个位置 URI，I2Ls 可以返回一个或多个。I2R 与 I2Rs 返回一份或多份资源实例。I2C 返回描述，I2N 返回 URN。最后一种还附带警告：两个 URN 是否相等，可能要经过命名空间专属规则，而非简单字符串比较。

这些服务不是“给我任何相关信息”的同义写法。位置说明可从哪里尝试取得对象；资源实例是协议真正交付的内容；描述是关于对象的陈述；持久名称要在位置改变后仍维持身份。一个标识符可以支持全部操作，但证明位置存在，不能替代证明资源内容；描述真实，也不保证后来下载的对象就是被描述者。

结果数量也是合同的一部分。I2Ls 与 I2Rs 末尾的小写 s 允许集合。如果客户端悄悄取第一项，就把复数答案改造成单数，并自行增加了选择政策。可审计收据必须保存所求服务、单复数预期、完整返回集合，以及消费者最后采用哪一项。

Services 前可以带可选协议名，但协议名本身不构成 URI 解析合同。RFC 3404 要求另行定义请求如何编码具体服务、响应如何表示结果。写下 HTTP 只说明协议家族，没有说明怎样区分位置请求与资源请求，内容类型怎样对应描述，或多个结果如何封装。

这条限制划清了发现与互操作的边界。服务发现可以找到声称具备某种能力的端点，却不能凭一个传输标签创造应用协议。能力声明、网络请求与可观察响应必须对同一种服务具有一致语义。

Flags 描述另一个维度。S、A 与 U 是 DDDS 终端标志。S 表示输出域名要继续查询 SRV；A 表示用输出域名查询地址；U 直接产生 URI。所谓终端，只表示 DDDS 循环在此停止，不表示下游解析、连接、认证或内容验证已经完成。

P 看似与前三个字母并列，性质却完全不同。它表示后续处理属于应用专属体系，不再遵守 DDDS 概念。它不是 DDDS 内部的第四种终端结果，而是一条系统边界。若把 P 写成普通终端，审计记录会漏掉权威规则已经换手。

2002 年规范中的四个标志互相排斥，但实现不得假设 Flags 永远只有零个或一个字符。未来版本可能定义组合。遇到未知标志，客户端必须忽略这条记录并继续处理；这项检查还要先于普通排序，因为新标志可能改变其余字段的解释方法。

Services 也可以为空。在委派链较早的位置，发布者可能还不知道终点解析器将提供哪种协议与服务。空值不等于格式错误，也不等于支持一切；它表示服务选择被推迟到下一层。

RFC 3404 允许一项严格受限的优化：在同一 ORDER 的记录集合内，客户端可以寻找自己更能使用的服务，而不必机械服从首个 preference。但是替代规则必须保持基础 DDDS 算法同样的输入与输出，不能跨越委派路径，也不能在已经匹配后转向更高 ORDER。

界线保护的是“本地能力”与“发布权威”的区别。客户端可以在权威等价的选项之间选择熟悉协议，却不能把另一层中较方便的端点提拔为等价结果。否则，所谓优化就是客户端私自重写区域管理员安排的委派。

响应可以在 Additional 区附带 SRV 或地址记录，减少网络往返。但它们只是优化，应用必须在权威服务器完全不提供这些记录时仍能运行。“发现下一个名称”“同时收到旁路数据”“下游连接成功”是三项证据，不能合并成一次成功。

安全责任沿着相同边界分开。找到解析器并不定义如何与它安全通信，这要由具体解析协议说明。uri.arpa. 与 urn.arpa. 的 DNS 管理面临可用性、伪造与委派风险。即使 DNS 路径通过验证，也没有自动认证应用层对端，没有证明资源来自预期发布者，更没有证明描述仍然最新。

正则表达式还带来本地执行风险。实现应先做合理性检查，不能把表达式盲目交给拥有危险能力的环境。一条经过签名、委派正确的规则，仍可能被不安全地解释；来源真实性与执行安全是两种证据。

RFC Editor 当前列出三条编辑性勘误。已验证的 282 与 787 把“Additional Information”处理的引用从 RFC 3404 改为真正定义它的 RFC 3403；Held for Document Update 的 2923 修正第 4 节中的引用编号。三者都不改变 Flags、解析服务类型或单复数语义。

完整运行收据因此应保存规范化输入、scheme 或命名空间、首个键、DNS 查询、完整 NAPTR 集合、已知/未知标志判断、协议、所求服务与数量、同 ORDER 内的选择、选中规则、S/A/U/P 交接、下一次查询或 URI、解析请求编码、已认证对端、响应内容类型、返回对象类别，以及消费者真正使用的结果。

Lu Heng 的最小初始规范原则解释了这种设计：只把不同实现必须共享的边界写精确，把各协议的详细机制留给本地演进。运行代码优先给出验证办法：对同一标识符分别索取位置、资源与描述；删除 Additional；加入未知标志；改变同一 ORDER 内的能力；观察结果是否只在合同允许之处变化。

RFC 3404 没有保证每个 URI 都能回答所有问题。它要求系统先说清在问什么，再说清控制权怎样交接。这样，“解析成功”才从一盏含义模糊的绿灯，变成可以复核的事实主张。

来源