Summary

  • The IDMEFv2 HTTPS transport draft says a receiver should return 2xx only after safely dealing with an alert—by durable storage or an acknowledged relay—so 204 No Content can be a substantive receipt, not merely proof that TLS carried bytes.
  • Every alert travels in a separate POST, but revision 07 does not define retry idempotency, a duplicate window or a final investigation outcome. Consortiums need a ledger keyed to sender identity and the alert's mandatory ID.

A response can vanish after the write succeeds

Consider the failure that matters most. An Analyzer sends an incident alert. The Manager commits it to a database and starts returning 204. The connection disappears before the Analyzer receives the status line. Nothing in that observation tells the sender whether it should retry, while a blind retry may insert or trigger the same alert twice.

The 27 September 2026 individual Internet-Draft Transport of IDMEFv2 Messages over HTTPS makes this ambiguity operationally important. Datatracker says revision 07 has no stream and no formal IETF standing. Its header aims at Standards Track and says it would obsolete RFC 4767 only if approved. It is a live proposal, not a standard or deployment claim.

The exact revision 07 text requires one IDMEFv2 message per HTTP request and requires POST. Requests may run in parallel. A 4xx represents a defective or unauthorized request; a receiver-side processing failure requires 5xx. Most importantly, the HTTP code is the acknowledgement: a Manager should not emit 2xx until it has safely dealt with the message, for example by storing it durably or passing it to another system that acknowledged it.

That is stronger than reading a green TLS session as success. The appendix's 204 example has no body, yet it means the alert crossed a defined safe-handling threshold. RFC 9110 supplies the generic semantics: 204 says the requested action succeeded and there is no response content. Revision 07 supplies the application-specific promise about what success must mean.

The second POST has no common meaning yet

The remaining gap is not a missing alert identifier. The companion IDMEFv2 data-model draft makes a top-level UUID ID and CreateTime mandatory. Those are good raw materials for a duplicate key. The transport draft, however, does not say how long a receiver must remember an ID, whether identical repetition receives 2xx, or how to handle the same ID with a different payload.

HTTP does not fill that policy in. RFC 9110 does not define POST as idempotent and warns against automatic retry unless the client knows the application semantics are idempotent or can prove the first attempt was not applied. RFC 9205 explains why an HTTP-based protocol must define its own application semantics rather than treating the substrate as the whole protocol.

Mutual authentication does not close the gap either. Revision 07 requires X.509 certificates on both sides, full path validation, DNS identities without wildcards and an explicit approved-peer certificate list, drawing on RFC 5280 and RFC 6125. Those rules answer which peer spoke. They do not decide whether a repeated UUID is an exact retry, a correction, a collision or abuse. Nor does a 204 prove triage, escalation, remediation or the truth of the sensor's claim.

A consortium profile therefore needs three records, not one green light. The transport receipt records who accepted which payload digest and when. The duplicate decision records first-seen and last-seen time, exact-match replay or conflicting reuse, and the action taken. A later disposition record says whether the alert was correlated, escalated, closed or rejected. The message UUID can join them without forcing every participant to share one incident-management system.

This separation follows Running-Code Primacy: the observed chain of submission, durable acceptance, replay decision and disposition is the evidence. Minimum Initial Specification, Localized Future Decision supports a narrow common receipt while leaving response authority local. On Authority, Belief, and the Internet's Addressing System offers the crucial restraint: a certificate identity, an HTTP acknowledgement and an incident judgment are representations issued by different actors. None should inherit the authority of the others.