摘要

  • draft-deshpande-secevent-http-multi-set-push-03 允许一个 202 响应同时确认部分 SET、拒绝另一些 SET，并返回早先请求里的 jti；状态码只覆盖请求外壳，不证明每个事件已经完成。
  • 该文件是在 SECEVENT 结束后以 AD-sponsored individual submission 进入 IETF Last Call，截止日为 2026 年 9 月 23 日；它没有工作组状态、确认实现、IESG 批准、RFC 编号或完成的 IANA 登记。

设想一个 POST 携带四个 Security Event Token。接收方返回 202 Accepted，批处理看板随即变绿。但响应正文只在 ack 中列出三个 jti，第四个出现在 setErrs。同一份响应甚至还可以带回昨天请求中的标识符。至于已确认的事件是否最终触发账号停用、会话撤销或其他业务动作，202 本身没有回答。

这不是异常分支，而是 HTTP Push Delivery of Multiple Security Event Tokens 第 03 版明确设计的控制边界。草案用批量传输提高效率，却没有把多个 SET 变成一笔事务。最重要的运营结论因而是一条限制：请求级 202 不能升格为整批完成证明。

一个传输外壳，多项独立结果

拟议媒体类型 application/secevents+json 的 sets 对象以每个 token 的 jti 为键。接收方逐项验证。202 正文必须有 ack 数组，还可以有同样按 jti 索引的 setErrs 对象。草案示例就在一个成功响应里同时放入确认与错误。

响应也不一定只对应眼前这次请求。接收方可以报告早先请求的标识符；发送方还可以发送空的 sets 对象，专门轮询延迟结果。对未知 jti 的确认或错误必须忽略。因此，能够核对和闭环的单位不是 HTTP 请求，而是具名的单个 SET。

重试规则继续维持这条边界。发送方会重试未确认事件，直到收到该 jti 的确认、SET 专属错误，或者达到最大尝试次数。部署方还可能因为时间或存储限制丢弃未交付事件。这些都是本地政策，无法从最初那行 202 中复原。

收到，不代表执行完成

下游边界更为严格。草案里的确认表示接收、解析和验证成功，不表示后续业务动作已经完成。RFC 8935 早已把 SET 交付成功与之后的事件处理分开；RFC 8417 则把 SET 定义为发布者对事实的陈述，而不是命令。接收方是否采取行动、采取什么行动，属于另一层决定。

HTTP 语义也给出同样警告。RFC 9110 的 202 表示请求已接受处理，但处理尚未完成；工作可能尚未开始，最后也可能不发生。多 SET 草案在这个有意保持开放的外壳内增加了逐事件证据，并没有改写 202 的含义。

批量也不创造顺序。草案明确每个 SET 相互独立，在请求中的位置不表示时间依赖，不存在事务性要求，发送方也不能假定接收方按顺序处理。如果两个安全事件存在因果关系，证据必须来自 JSON 相邻位置之外。

Last Call 是里程碑，不是批准

Datatracker 把第 03 版列为安全领域的活跃个人 Internet-Draft，目标状态为 Proposed Standard。Last Call 于 8 月 26 日发出，在 9 月 23 日结束；Working Group state 为 None，没有安排 telechat。

shepherd 记录解释了这条路径：原 SECEVENT 工作组已经结束，社区没有足够动力重新组建，因此文件在 Deb Cooley 负责下作为 Area Director-sponsored individual submission 推进。没有被工作组接纳并不等于出现了技术争议，但这条路径也不能被写成工作组共识。

Security Directorate 评审给出 Ready，并提出一处轻微措辞建议。shepherd 记录没有确认实现，作者计划把机制纳入 OpenID Shared Signals Framework，但计划不是实现证据。IANA 动作仍以未来获批为前提。Last Call 也不是 IESG 批准、RFC 发布或 IANA 登记完成。

为每个 jti 留下证据链

Daniel Kade 提议把一次多 SET 交换记录成一组相互关联的回执。对每个 jti，保留发送请求 ID 与时间、准确的确认或错误、是否引用早先请求、重试次数、下一次尝试决定，以及最终丢弃原因；同时记录接收方配置版本、验证时间和下游系统自己的已应用、已拒绝或待处理状态。

这是一项编辑治理设计，不是 IETF 的规范要求。它的目的，是防止传输优化抹掉责任边界。管理看板可以聚合，但聚合结果必须能够下钻到单个事件。

故障发生后，这种区别最重要。绿色 202 只能证明外壳被接受，不能证明每个 token 均有效、按序处理、应用到下游并一直保留到成功。如果逐 jti 的链条已经被删除，再读 HTTP 状态行也无法补回证据。

来源