摘要

  • Who-Provides? 适合在不知道服务地址时广播，只要求匹配者回答，因此沉默不能成为“没有服务”的证明。
  • Do-You-Provide? 发给一台明确的主机，要求它即使不提供任何目标资源也返回空清单；第三方给出的地址则通常还需直接核实。
  • 资源名沿着协议解复用路径逐层展开，支持 UDP、某个端口或基础应用，并不自动等于支持其上的每一种专门功能。

RFC 887 给出的 DNS 示例有一个值得反复读的转折。已知的“聪明主机”说 S 提供域名服务，查询方没有立即使用 S，而是直接询问。S 返回空清单。查询方把 S 排除，再去问第三方，最后得到 T，并从 T 本身收到确认。

这段来回不是协议多余的繁琐。它承认名录记忆与端点现状属于两个观察者、两个时间点。第一条线索可以有用，却不能冒充最后一句话。

资源名本身是一条解复用路径

RLP 没有从便于人读的服务名称起步。一个资源说明先写访问它所需的最低层 Internet 协议号，再写标识长度与上层自然使用的解复用字段。UDP 域名服务的示例是协议号 17 和端口 53；更具体的功能还可继续添加成分。

显式长度有一个重要作用：接收方即使不认识某种资源的内部结构，也能跳过它，继续读取清单中的下一项。协议不让一次未知类型破坏整份问题。

匹配则逐层进行。如果底层成分不支持，结论是不提供；如果请求名称恰好在成功检查后结束，结论是提供；如果主机已经走到自己理解范围的尽头，请求却还有额外成分，基础协议的支持不能覆盖这项专门化。

因此，“我提供 TFTP”与“我提供通过 TFTP 传送崩溃转储的特定资源”是两句话。传输、端口、应用族与应用功能不能被压成一个笼统的“支持”。

向所有人提问，只让肯定者开口

Who-Provides? 通常向本地 IP 网络广播。能提供清单中至少一项资源的主机用 I-Provide 回答；没有匹配的主机可以不说话。

这个设计控制了答复数量，却保留了沉默的歧义。可能确实没有提供者，也可能请求或答复丢失，可能有服务的主机没有实现 RLP，或者它没有参与回答。RFC 919 后来明确指出，IP 广播不可靠、无顺序、可能重复，而且每一台听到广播的主机都要付出处理成本。

广播让主机在不知道地址时找到候选者，代价是占用公共注意力。它没有产生全网否定结论的权力。

向一台主机提问，空清单才成为明确的“不”

Do-You-Provide? 面向一个已经知道地址的对象。接收方无论匹配与否都必须回答。空的 I-Provide 清单由此成为一项范围清楚的否认：这台主机对这次请求没有声明所列资源。

RFC 887 禁止广播这类问题。若每台收到请求的主机都必须返回否定答复，一个问题便会引发答复洪水。协议依据受众规模分配发言义务：面对人群，只让肯定者回答；面对指定对象，肯定与否定都要返回。

明确否认仍然不是永久事实，也不能替其他主机作答。它的价值来自边界更窄、更可归责，而不是声音更响。

第三方可以指路，却不能替端点作证

Who-Anywhere-Provides? 与 Does-Anyone-Provide? 可以询问一台已知的聪明主机，让它提供其他网络上可能的服务地址。这对没有广播能力的网络尤其有用。

答复名为 They-Provide。RFC 887 特意说明，查询方不必无条件相信这类间接信息，通常应向被提名的主机发送 Do-You-Provide? 进行确认。

第三方说 S 可用，而 S 说不可用，不一定有人撒谎。第三方知识可能已经过期，S 也可能改变配置。只要保存谁在何种角色下说了什么，矛盾就能被解释为时序差异；若把两种答复都写成“发现成功”，这种差异便无法追溯。

Local-Only 标志又为问题添加地理范围。答复只能列出与查询方处于同一 IP 网络的地址，多宿主主机也要选用正确的本地源地址。范围不是结果页面上的筛选项，而是请求语义的一部分。

关联编号没有变成身份凭据

16 位 Message-ID 只是帮助把答复对应到请求。它不认证发送者，不授权服务使用，也不阻止伪造。UDP 校验和能发现部分偶发错误，却不是密码学签名。

即使服务主机直接返回 I-Provide，它也只是在这个时刻声明自己提供所命名的资源。后续事务是否成功、实现是否完整符合规范、查询方是否有权使用，以及服务能否持续健康，都需要别的证据。

后来的发现协议重新安排了名称、范围与信任

后续标准可用于比较，但不能据此声称直接继承。RFC 2608 的 SLPv2 使用服务类型与属性，区分用户代理、服务代理和目录代理，并设置管理范围。它还为服务 URL 与属性定义认证，同时明确不提供机密性。

RFC 6762 让本地链路在没有传统单播 DNS 服务器时执行类似 DNS 的操作。RFC 6763 则利用 DNS 记录，按服务类型和域发现有名称的服务实例。表达方式改变了，但答复由谁发出、在哪个范围有效、产生于何时，仍是不同问题。

端口登记保存的是协调，不是运行状态

RFC 887 为 UDP 分配端口 39。今天的 IANA 服务名称与传输协议端口登记表 仍在 TCP 和 UDP 的 39 端口保留 rlp。这证明登记关系延续至今，不证明还有多少实现正在监听。

RFC 6335 说明，服务名或端口分配不构成对应用的认可，端口上的流量甚至未必属于登记的服务。号码能协调名称冲突，却不能替主机回答。

来源与边界

本文依据 RFC 887、RFC 919、RFC 2608、RFC 6762、RFC 6763、RFC 6335 与 IANA 登记表。它们不证明 RLP 的历史部署比例，不证明后续发现协议直接源自 RLP，也不证明任何具名产品或当前网络的行为。