Summary

  • draft-deshpande-secevent-http-multi-set-push-03 can return HTTP 202 while acknowledging some SET identifiers, rejecting others and referring to earlier requests. The status code covers the envelope, not completion of every event.
  • The draft is an Area Director-sponsored individual submission in IETF Last Call through 23 September 2026. It has no working-group state, confirmed implementation, IESG approval, RFC number or completed IANA registration.

One POST arrives with four Security Event Tokens. The receiver returns 202 Accepted. A batch dashboard turns green. Yet the response body acknowledges three jti values and places the fourth under setErrs. It may also mention an identifier sent in yesterday's request. Nothing in the status line says whether any acknowledged event has produced the account suspension, session revocation or other downstream result that its recipient might choose to perform.

That is not a corner case. It is the control model in revision 03 of HTTP Push Delivery of Multiple Security Event Tokens, whose IETF Last Call ends on 23 September. The draft makes batching more efficient without converting a group of SETs into a transaction. Its most important operational lesson is therefore negative: a request-level 202 cannot be promoted into a batch-level completion receipt.

One envelope, independent outcomes

The proposed media type, application/secevents+json, carries a sets object keyed by each token's jti. The receiver validates the members independently. Its 202 response contains a required ack array and can contain a setErrs object, also keyed by jti. The draft's own example puts successful acknowledgements and an error in the same accepted response.

The protocol also decouples a response from the request that happens to carry it. A receiver can report identifiers from previous requests, and a transmitter can send an empty sets object to poll for deferred results. An acknowledgement or error for an unknown identifier must be ignored. The unit that can be reconciled is therefore not the HTTP request but the named SET.

Retries preserve the distinction. A transmitter retries an event until its identifier is acknowledged, receives a SET-specific error or reaches a configured attempt limit. Time and storage policy may eventually cause an undelivered SET to be discarded. Those decisions are deployment policy, not facts recoverable from the original 202.

Receipt is still not execution

The boundary is even sharper downstream. Under the draft, acknowledgement means receipt, parsing and validation. RFC 8935 already separates successful SET delivery from later event processing, while RFC 8417 describes a SET as a statement of fact rather than a command. The recipient decides what action, if any, follows.

HTTP itself supplies the same warning. RFC 9110 defines 202 as acceptance for processing, not completed processing. Work might not yet have started and might not ultimately occur. Multi-SET Push adds useful per-event evidence inside that deliberately noncommittal envelope; it does not change the meaning of 202.

Nor does batching create order. The draft says every SET is independent, that placement in a request does not imply chronological dependence, and that there are no transactional requirements. Acknowledgement order cannot be used to reconstruct business order. If two events have a causal relationship, that relationship needs evidence outside their adjacency in one JSON object.

The standards milestone is bounded

Datatracker records revision 03 as an active individual Internet-Draft in the Security Area, intended for Proposed Standard. The Last Call began on 26 August and ends on 23 September. Working Group state is None and no telechat is scheduled.

The shepherd record explains why. SECEVENT had concluded, and the community did not have enough energy to recharter it, so the work moved forward as an Area Director-sponsored individual submission under Deb Cooley. That route is not evidence of a technical rejection. It is also not a working-group consensus claim.

The Security Directorate review marked the draft ready with a minor wording suggestion. The shepherd found no confirmed implementations, although the authors intend to incorporate it into the OpenID Shared Signals Framework. IANA actions remain contingent on approval. These are useful process signals, but they do not amount to IESG approval, RFC publication or deployment proof.

Preserve the event-level chain

Daniel Kade proposes treating a Multi-SET exchange as a set of linked evidence records. For every jti, retain the transmitter's request identifier and timestamp, the exact acknowledgement or error, any reference to an earlier request, retry count, next-attempt decision and terminal discard reason. Add the receiver configuration version, validation time and the downstream system's own applied, rejected or pending state.

This receipt is an editorial governance design, not an IETF requirement. Its purpose is to prevent a transport optimization from erasing accountability. A summary dashboard may aggregate the records, but the aggregate must remain drillable to each event.

The distinction matters most after a failure. A green 202 proves that an envelope was accepted. It does not prove that every token was valid, processed in order, applied downstream or retained until success. If the jti chain has already been discarded, that gap cannot be repaired by rereading the HTTP status line.

Sources