摘要

  • RFC 9176 中的资源登记记录端点名称、基础 URI、链接与生命周期；它不是端点当前存在或资源当前可用的证明。
  • 登记成功、目录查询、网络可达、身份验证、资源响应和应用侧效果各自需要独立、带时间的证据。

资源目录解决的是受限网络中的发现问题，而不是替运营者观察设备。设备可能休眠，直接发现可能依赖成本很高的多播，因此客户端需要一个能存放资源链接的共同地点。RFC 9176 为此定义 Resource Directory（RD）：端点或调试／部署工具可以登记、更新和移除资源信息，查询者可以取得这些已登记的链接。这个机制让信息可发现，却没有把记录变成端点的心跳。

一条登记的结构本身已经说明它的范围。它关联一个端点，并带有端点名称、基础 URI、生命周期、RD 内的登记资源位置、一组链接、可选的 sector 和其他属性。RD 在创建时返回一个位置，创建者凭它更新生命周期、维护链接或删除登记。该返回值证明的是 RD 接受了自己的登记资源；它不能证明登记所指的设备在几分钟、几小时或下一次查询时仍有电、仍接入网络或仍运行相同服务。

生命周期尤其不应被忽略。RFC 9176 将登记定义为软状态，需要定期刷新。生命周期到期后，RD 不应再对该端点提供发现查询结果；但它可以保留登记资源，让迟到的端点还能刷新，也可以在以后垃圾回收。于是，到期后仍能看到某个管理对象，不能被解读为端点复活、服务恢复或资源仍可调用。那只是目录自身状态机留下的恢复入口。

查询结果也有明确边界。RD 返回的是登记时提交的链接，并按基础 URI 解析相对引用。它说明登记者曾怎样描述资源，却不从查询者所在网络发起连通性测试。它不验证路径是否仍通、传输是否协商、凭证是否获接受、特定客户端是否有权限、资源是否处理请求，或某个物理设备是否完成动作。URI 可以仍然正确，设备却已离线；资源可以返回格式正确的响应，应用侧承诺却仍未完成。

身份与权限同样不能从目录字段中自动取得。RFC 9176 说明端点不能仅用协议、端口或 IP 地址识别，因为这些可在生命周期内变化。谁能使用端点名称或 sector，取决于具体安全策略；登记接口和查询接口的访问控制也应分开。能看到链接的人不因此获得操作资源的授权；能写入登记的人也不因此让其内容成为持续有效的事实。

因此，任何“资源可用”的结论都应保留分层记录：登记请求和 RD 回应、RD 分配的位置、名称和 sector 的授权规则、基础 URI、链接、生命周期和刷新历史；然后是带时间和观察位置的查询结果。若要宣称服务实际可用，还需单独保留直接可达测试、传输和认证结果、资源请求与响应，以及应用侧的效果记录。Peter van der Stok 作为共同作者并不拥有这些运行环节；RD 运营者、登记者、端点运营者和客户端分别承担不同控制面。

这与 Lu Heng 所强调的证据纪律相容：共同记录可降低协调成本，但不能夺取运行者的决策，也不能替代对运行事实的观察。RD 的价值是让已登记链接可被检查；把它说成端点在线或业务成功，反而会破坏这种价值。

来源