01 — SEMANTICS
Advisory by design
A reported token is information about an action. Receiving it is not an instruction to apply a control.
OODA-HTTP / Protocol & research
Specification
Understand the advisory field, explore an illustrative response, and read the draft.
Specification reference: this overview follows draft-04. Read that revision or inspect the draft history. The draft is the reference for exact requirements.
The proposal
A small field.
A specific responsibility.
Enforcement-Action describes a reported action. Its role is observability; HTTP status, application policy, and actual enforcement retain their own responsibilities.
02 — SYNTAX
Structured representation
The draft-04 direction uses Structured Fields: a token with parameters, such as a duration. Consult the draft for the exact parsing and processing rules.
03 — BOUNDARIES
Context matters
Trust, intermediary handling, and caching affect what a response field can safely tell a recipient.
Interactive explainer
One status. Different signals.
Switch the reported token to see the visibility question. This browser-only example is illustrative, not a running engine or benchmark.
What does the observer receive?
All examples keep the status at 200 to isolate the additional information carried by the field.
A deployment should use the appropriate HTTP status for its actual response semantics.
Visible response
HTTP/1.1 200 OK
Enforcement-Action: monitorThe sender reports monitoring. The field alone does not prove that monitoring occurred.
Protocol walkthrough
Read the signal in context.
Follow the protocol question from the visibility gap to implementation and evaluation. This explanatory overview follows the HTTPAPI presentation outline; draft-04 remains the reference for exact syntax and requirements.
1. The response-path visibility gap
A component may select an action without making that selection explicit in its HTTP response. In a controlled example, several selected actions can accompany the same 200 OK status. Which actions remain compatible with an observation depends on what the observer knows about the deployment.
An explicit field lets cooperating components observe the reported selection. If the field is removed at a trust boundary, a recipient outside that boundary no longer sees that signal. Absence is not an allow decision.
2. Field design and shared meaning
Enforcement-Action: monitor
The proposed representation is a Structured Fields Item with a Token as its primary value and optional parameters. Draft-04 leaves token and parameter meanings to the deployment. A common parser alone does not establish a common operational meaning.
The field is advisory. Selection does not prove execution, and receiving a token does not authorize a control. Each recipient retains its own local policy. An open interoperability question is which shared vocabulary and attribution rules independent implementations need.
3. Trust, parsing and cache safety
Trust: distinguish the authenticated upstream sender from the component that originally selected an action. Authentication alone does not establish authority for every reported claim.
Parsing: use Structured Fields parsing. Malformed values and multiple field lines must not trigger enforcement based on this field; independent local policy still applies. Unknown tokens and parameters require the draft’s specified handling.
Boundary handling: follow the draft’s removal rules before forwarding outside a trusted boundary. Forwarding and disclosure are explicit deployment responsibilities.
Caching: a stored response can carry an action selected for an earlier request. Reuse does not establish a new decision for the current client. Context-specific values require care under the existing HTTP caching rules.
The presentation identifies 1xx responses, 304 responses and trailers as prohibited locations under draft-04. Consult the draft for the complete processing requirements. Attribution when a gateway selects another action remains a design question.
4. Existing mechanisms and the separate-field question
| Mechanism | Role in the comparison |
|---|---|
| HTTP status codes | Describe response semantics; they do not necessarily identify the selected local enforcement action. |
| Proxy-Status | Communicates intermediary handling and diagnostics, with extension parameters to consider. |
| RateLimit fields | Communicate quota policy and availability. |
| Tracing | Provides correlation and can carry instrumented action attributes. |
| Private response field | Can carry an experimental payload through a private agreement. |
| Enforcement-Action proposal | Explores a common response field for reporting a selected local action between cooperating components. |
The review question is whether a separate field provides sufficient interoperable value for this use case. The existence of a prototype alone does not settle that question.
5. Prototype evidence and evaluation
The reported prototype compares implicit signaling, explicit signaling and removal at a boundary. Observation points must be named: a gateway can observe a token that a downstream edge does not receive.
Evaluate visibility, reconstructability, token consistency, response bytes and latency separately. Parsing agreement, agreement about meaning and verified execution are different outcomes.
The project’s reported 150-request experiment and separate three-request functional check have different scopes. Independent interoperability and operational benefit remain open questions.
Read the measurement methodology → · Read the experimental evidence status →
6. Questions for technical review
- Is a separate response field justified for the selected-action visibility use case?
- What shared token meanings and attribution rules are needed?
- Are trust, parsing, forwarding and caching requirements sufficiently precise?
- Who can independently review, implement or test the proposal?
Organization adapted from the project’s HTTPAPI presentation dated 14 October 2026. This is an explanatory summary, not an IETF-endorsed interpretation or a replacement for the draft.