Summary

  • IETF CoRE 工作组 2026 年 11 月 2 日更新的第 22 版草案设计了 CoAP 发布订阅代理：发布者向主题数据资源 PUT，订阅者用 Observe 接收变化，或 GET 最新状态。草案仍在 IESG 评估阶段。
  • 草案第 3.3 节只定义取得最新主题数据；读取旧版本与规定保存多少历史，均留待未来规范。断线终端看到恢复正常的读数，不能靠它找回中间的告警。
  • 主题存在、代理接受更新、订阅成功、订阅端收到通知各有不同证据。成功响应没有 Observe 选项，就不能算订阅已建立。

设想一台厂区温度计在中午报出高温，一小时后又报出常温。维修终端在这段时间离线，重新连接时只读到常温。它对“现在”的报告没有错；对“刚才是否出过险情”却没有答案。这个场景是检验协议边界的假设，不是草案记载的真实事故。

CoRE 草案为这类不总在线的设备安排了一个代理。代理管理主题集合、主题配置资源，以及独立的主题数据资源。发布者把数据 PUT 到后者。订阅者向同一数据资源发出带 Observe: 0 的 GET，沿用 RFC 7641 的观察机制。也可以不保持订阅，直接 GET 当前数据。配置主题的网址与取主题数据的网址未必长得相似，客户端要读 topic-data 属性。

“没有数据”至少有三种意思

一个主题刚创建时，主题数据资源已经存在，却还没有任何表示；草案用拟议的 2.06 No Content 表达这种状态。资源不存在时通常是 4.04 Not Found。资源已有发布内容时，GET 返回最新表示，通常是 2.05 Content。监控台若把这些响应都涂成“暂无告警”，连主题是否存在都分不清。

更重要的是第 3.3 节的边界。它只定义获取最新表示；旧表示的检索办法、代理应留多少份历史，是未来工作的例子。代理在断线期间收到过两次 PUT，并不意味着重连的订阅者可以向它索取那两次的时间线。要追溯“异常何时升起、持续多久、何时解除”，运营者需要另设持久事件日志，并验证它确实接收了每次需要保存的变化。

订阅也不能凭成功码猜。带 Observe: 0 的请求若得到含 Observe 选项的 2.05，客户端取得当前数据并建立订阅。尚未有数据的主题可回 2.06 加 Observe，第一条发布稍后通知。若响应没有 Observe，客户端应认定订阅失败；即便收到 2.05 或 2.06，结论也一样。主题设置了 max-subscribers 且名额已满时，代理会省去 Observe。只检查响应码的程序，会把一次普通读取错当成持续监视。

主题本身也会消失。删除主题会同时移除配置资源和数据资源，观察者收到最终 4.04；可选的到期日期还能自动触发删除。调查断线时，必须分清终端睡着了、订阅没成立、资源空着，还是主题已被删除。只看最后一个温度数值，四种原因都被抹平。

代理收稿回执不是维修端的签收单

发布者 PUT 成功通常收到 2.04 Changed，这是 RFC 7252 的 CoAP 请求响应语义下代理接受更新的结果。它不证明每个订阅者收到，更不证明应用发出警报。若发布过快，草案允许代理返回 4.29 Too Many Requests，并用 Max-Age 指定重试时刻。事件日志需要记录被拒绝的发布，否则传感器“发过”和代理“存下”又会混为一谈。

安全边界同样分层。草案要求客户端到代理的通信受到保护；发布内容还应端到端保护，并让订阅者核验来源。与代理建立安全连接，不等于订阅者已验证传感器身份。即使来源真实，也还需证明终端收到、应用判断、人员或设备采取了动作。

这个设计的好处很清楚：设备长时间休眠后仍可取到最新状态。草案没有提供完整历史保证，也没有给出部署中告警丢失率。改变运营判断的事实是一条按时间排序的记录：高温更新何时被代理接受、何时发给订阅者、订阅者何时确认并处理。缺了这条记录，常温读数只能说明代理最新收到的是常温，不能替消失的一小时作证。

CoRE 发布订阅草案 · RFC 7641 · RFC 7252