摘要

  • IDMEFv2 HTTPS 第 07 版要求接收方只有在告警已安全落盘、入库，或被一个明确确认的下游接管之后才应返回 2xx；因此 204 No Content 可以是一张真实的接收凭证。
  • 每条告警都通过独立 POST 传输，但草案没有定义重试幂等性、重复记忆窗口或调查结论。联盟应以发送方身份和告警必填 ID 建立独立账本。

最难判断的失败发生在成功之后

设想分析器交出一条告警，管理器完成数据库提交，准备返回 204；就在这时连接断开。分析器不知道写入已经完成。如果再次 POST，接收方可能把同一信号入库两次、关联两次，甚至触发两套自动处置。不重试也有风险，因为发送方无法证明第一次请求是否真正应用。

2026 年 9 月 27 日更新的个人草案 Transport of IDMEFv2 Messages over HTTPS 正好把这类模糊性推到控制面。Datatracker 明确标注它没有 stream，也没有 IETF 标准流程中的正式地位。文件页眉写的是拟议 Standards Track，且只有在获批后才会替代 RFC 4767。第 07 版是可变更的提案，不是标准或部署事实。

第 07 版原文 规定每条 IDMEFv2 消息使用一次 POST，同时允许并行发出多个请求。消息不合格应返回 4xx；接收端自身无法处理则必须返回 5xx。更关键的是，HTTP 状态码就是确认：未能安全处理消息时不应发出 2xx，所谓安全处理包括写入磁盘或数据库，或者转交给一个已经确认接收的下游系统。

所以，示例中的 204 不只是“TLS 把字节送到了”。RFC 9110 给 204 的通用含义是请求已成功履行、没有额外响应内容；这份草案再加上一层应用承诺，明确成功至少跨过了哪一道持久接收门槛。

告警有 UUID，重试仍然没有共同语义

问题不是缺少标识符。配套的 IDMEFv2 数据模型第 08 版 要求顶层告警携带 UUID 形式的 ID 和 CreateTime。联盟完全可以用发送方证书身份加告警 ID 形成去重键。但传输草案没有规定要记多久、完全相同的重复是否继续返回 2xx，也没有规定相同 ID 搭配不同内容时究竟是修订、冲突还是滥用。

HTTP 不会自动补上答案。RFC 9110 没有把 POST 定义为幂等方法，并告诫客户端：除非它知道应用语义本身幂等，或能证明原请求从未应用，否则不应自动重试。RFC 9205 的设计纪律也在于此——采用 HTTP 仍须明确应用协议自己的状态变化。

双向认证解决的则是准入。草案依据 RFC 5280 和 RFC 6125 要求两端使用 X.509、完成路径验证、禁止通配 DNS-ID，并支持显式批准的对端证书清单。这能说明是哪一个获准成员发言，却不能证明告警内容真实、UUID 唯一，更不能证明告警已研判、升级或关闭。

一套可执行的联盟规则应拆成三张记录。第一张是接收凭证，绑定对端身份、告警 ID、内容哈希、首次收到时间和持久写入时间。第二张是重复判断，记录完全一致的重放、同 ID 冲突和采取的动作。第三张才是后续处置，写明关联、调查、驳回、升级或关闭。它们可以互通，同时不要求所有成员交出自己的响应系统。

Running-Code Primacy 要求把证据放在实际发生的接收、落盘、去重和处置链上，而不是只看合规宣称。Minimum Initial Specification, Localized Future Decision 支持把共同层压缩成一张可互操作的凭证，同时保留本地决策权。On Authority, Belief, and the Internet’s Addressing System 则提醒我们：证书身份、HTTP 确认和事件判断由不同主体签发，彼此不能借用权威。