The Micro Agent Communication Protocol (µACP)

1.1. Goals

• Provide a minimal, low-overhead communication protocol for constrained agents that supports structured semantics without heavy runtime cost.¶
• Ensure deterministic and bounded resource usage (memory, CPU, bandwidth), enabling predictable behavior in resource-constrained environments.¶
• Support essential multi-agent communication patterns — request/response, publish/subscribe, life-check — using a small set of orthogonal primitives.¶
• Define a secure, interoperable transport binding so that agents across different platforms can communicate safely and reliably.¶
• Enable extensibility via a TLV option mechanism, allowing future enhancements (e.g., content types, metadata, authentication tokens) without breaking base compatibility.¶

1.2. Scope

This specification defines the wire format, core semantics, normative behavior, mandatory transport binding, security constraints, and IANA registries required for interoperable implementations. It does not specify or mandate application-level semantics (e.g., content encoding, agent ontology, high-level negotiation logic), which are left to deployment-specific or higher-layer protocols. Implementers are free to choose content encoding (e.g., CBOR, JSON), TLV usage, and higher-level behavior, provided they adhere to the normative parts of this document.¶

1.3. Intended Audience

This document is primarily intended for:¶

• Developers of embedded, IoT, or edge-device firmware seeking a lightweight yet expressive agent communication protocol;¶
• Protocol engineers designing distributed multi-agent systems requiring structured interactions, event subscriptions, or resource-aware communication;¶
• Standardization bodies and implementers evaluating µACP for integration into larger systems;¶
• Researchers studying resource-bounded multi-agent coordination, secure constrained communication, or constrained-device protocol design.¶

1.4. Relation to Existing Work

µACP's transport binding leverages established IETF standards: CoAP as the constrained-device transport substrate [RFC7252], and OSCORE for end-to-end object security across constrained networks and proxies [RFC8613]. OSCORE is itself designed for constrained RESTful environments and provides confidentiality, integrity, and replay protection for CoAP messages using COSE [RFC8949].¶

Compared to heavier agent-communication languages (e.g., FIPA-ACL), µACP trades semantic depth for minimalism and resource efficiency. Compared to plain CoAP or MQTT-style protocols, µACP brings structured agent-oriented primitives while preserving low overhead and deterministic resource usage. The TLV extensibility mechanism ensures future content- or metadata-level enhancements without invalidating base interoperability.¶

1.5. Document Structure

The remainder of this document is organized as follows:¶

- Section 2 defines conventions and terminology.¶

- Section 3 describes the µACP message model and wire encoding rules.¶

- Section 4 defines the protocol semantics of the four core verbs (PING, TELL, ASK, OBSERVE).¶

- Section 5 defines the mandatory transport binding using CoAP/OSCORE, including mapping rules, security profile, and operational constraints.¶

- Section 6 defines error handling rules, version negotiation, and extensibility mechanisms.¶

- Section 7 defines the IANA registries (TLV Types, QoS codes, content-format) and related registration policies.¶

- Section 8 provides normative interoperability requirements and deployment guidelines.¶

- Section 9 describes security considerations and threat mitigation strategies.¶

- Section 10 provides example interactions and wire-level encodings.¶

- Appendices contain deployment notes, conformance test descriptions, change log, and reference implementation pointers.¶

2.1. Terminology

The following terms are used throughout this document:¶

Agent

An autonomous software entity that participates in µACP communication. Agents send and receive µACP messages to coordinate with other agents.¶

Verb

One of four core communication primitives in µACP: PING, TELL, ASK, or OBSERVE. Verbs are encoded in 2 bits in the message header.¶

TLV

Type-Length-Value encoding format used for optional metadata in µACP messages. Each TLV consists of an 8-bit Type, 8-bit Length, and variable-length Value.¶

Correlation ID

A 16-bit identifier that groups related messages into a conversation. Messages sharing the same Correlation ID belong to the same conversation.¶

Sequence ID

A 16-bit monotonically increasing identifier used for duplicate detection and replay protection within a conversation.¶

Conversation

A sequence of related µACP messages identified by a unique Correlation ID. Conversations typically represent request/response exchanges or subscription relationships.¶

OSCORE

Object Security for Constrained RESTful Environments, as defined in [RFC8613]. OSCORE provides end-to-end security for CoAP messages.¶

CoAP

The Constrained Application Protocol, as defined in [RFC7252]. CoAP serves as the transport substrate for µACP.¶

Constrained Device

A device with limited resources (memory, CPU, energy, bandwidth) as defined in [RFC7228]. Class 1 devices have approximately 10 KB RAM and 100 KB flash.¶

2.2. Notation

This document uses the following notation conventions:¶

• Hexadecimal values are prefixed with "0x" (e.g., 0x01, 0xFF).¶
• Binary values are prefixed with "0b" (e.g., 0b00, 0b11).¶
• Byte order is network byte order (big-endian) unless otherwise specified.¶
• Bit positions are numbered from 0 (most significant bit) to n-1 (least significant bit).¶
• Message formats are shown using ASCII art diagrams.¶
• Code examples use a monospace font.¶

2.3. Abbreviations

The following abbreviations are used in this document:¶

ACL

Agent Communication Language¶

BDI

Belief-Desire-Intention (agent architecture model)¶

CBOR

Concise Binary Object Representation [RFC8949]¶

CID

Correlation ID¶

CoAP

Constrained Application Protocol¶

COSE

CBOR Object Signing and Encryption¶

DTLS

Datagram Transport Layer Security¶

EDHOC

Ephemeral Diffie-Hellman Over COSE [RFC9528]¶

FSM

Finite State Machine¶

IANA

Internet Assigned Numbers Authority¶

IoT

Internet of Things¶

MTI

Mandatory to Implement¶

OSCORE

Object Security for Constrained RESTful Environments¶

QoS

Quality of Service¶

SID

Sequence ID¶

TLV

Type-Length-Value¶

URI

Uniform Resource Identifier¶

3.1. Message Structure

A µACP message consists of three components encoded in the following order:¶

+----------------------+----------------------+-------------------------+
|     Header (64b)     |   TLVs (0..1024 B)   | Payload (0..65535 B)   |
+----------------------+----------------------+-------------------------+

The header format is fixed-length and MUST always appear. TLVs and payloads are optional. Messages MUST NOT exceed transport-imposed size limits; for CoAP/OSCORE, these limits are determined by underlying MTU constraints and CoAP Blockwise Transfer (RFC 7959) if used.¶

All fields are encoded in network byte order (big-endian).¶

3.2. Header Format

The µACP header consists of 64 bits arranged as follows:¶

  0                   7 8                 15 16                23
 +---------------------+---------------------+--------------------+
 |     Sequence ID     |    Correlation ID   | QoS |Verb| Flags  |
 +---------------------+---------------------+--------------------+
 24                                                        63
 +--------------------------------------------------------------+
 |                       Reserved (40 bits)                      |
 +--------------------------------------------------------------+

Sequence ID (16 bits): Monotonically increasing identifier used for duplicate detection and replay-window tracking. MUST wrap modulo 2^16. MUST be unpredictable if security-sensitive traffic requires preventing traffic analysis.¶

Correlation ID (16 bits): Identifies all messages belonging to the same conversation. MUST be unique among active conversations. SHOULD be randomly generated in security-sensitive deployments.¶

QoS (2 bits): Encodes transmission semantics (fire-and-forget, at-least-once, at-most-once). Values are defined in the IANA Considerations section.¶

Verb (2 bits): Identifies one of the four µACP operations: PING(0), TELL(1), ASK(2), OBSERVE(3).¶

Flags (4 bits): Control bits reserved for protocol-level features such as fragmentation, retransmission hints, or message cancellation. Future specifications MAY define additional meanings.¶

Reserved (40 bits): MUST be set to zero on transmission. MUST be ignored by receivers. Reserved bits MAY be repurposed by future µACP versions but MUST NOT change meaning in this version.¶

3.3. TLV Encoding

TLVs (Type–Length–Value structures) convey optional metadata and extensibility information. They appear immediately after the header and MUST appear in Type-increasing order to allow binary search and deterministic parsing.¶

  0        7 8        15
 +----------+-----------+------------------------------+
 |  Type    |  Length   |    Value (Length octets)     |
 +----------+-----------+------------------------------+

Type (8 bits): TLV identifier. The meaning of each Type is defined in the IANA registry. Types 0–31 are reserved and governed by Standards Action. Types 32–127 require IETF Review. Types 128–255 are vendor-specific.¶

Length (8 bits): Specifies the number of octets in the Value field. Length MUST NOT exceed 255. TLVs MUST NOT cause the total TLV region to exceed 1024 bytes.¶

Value: Encoded according to Type. For Types other than 0x00 (Raw Octets), the Value is subject to OSCORE protection (Section 5).¶

Critical TLVs: A future TLV Type range MAY designate critical TLVs. Receiving an unknown critical TLV MUST cause message rejection.¶

3.4. Payload Encoding

The µACP payload is an optional octet string of 0–65535 bytes. Its semantics depend on the Verb and the application layer. Payloads are typically used for:¶

• Application data (e.g., sensor readings, state updates);¶
• Action parameters and operation descriptors;¶
• Event notifications for OBSERVE subscriptions;¶
• Encoded content (CBOR, JSON, application-specific formats).¶

Payloads MUST be OSCORE-protected unless the message Verb is PING. Payload sizes MUST be validated before allocation to avoid resource exhaustion.¶

If the payload is encoded using CBOR (Type=0x03), receivers MUST treat it as a single CBOR data item. If the payload is JSON (Type=0x02), it MUST be UTF-8 encoded.¶

3.5. Byte Ordering

All multi-octet integer fields in µACP (Sequence ID, Correlation ID, header composites) MUST be encoded in network byte order (big-endian). TLV and payload content MAY use other encoding rules (e.g., CBOR or UTF-8) as determined by their Types.¶

3.6. Fragmentation (Optional Feature)

µACP itself does not mandate fragmentation. When implemented, fragmentation MUST be controlled by Flags in the header and MUST operate in a deterministic, resource-bounded manner.¶

This specification defines the following fragmentation requirements:¶

• Fragments MUST preserve the same Sequence ID, Correlation ID, and Verb.¶
• Fragments MUST carry a Fragment-ID TLV if fragmentation is used.¶
• Receivers MUST reassemble fragments in Sequence ID order.¶
• Reassembly MUST abort if missing fragments exceed timeout thresholds.¶

Deployments using CoAP Blockwise Transfer (RFC 7959) SHOULD avoid µACP-level fragmentation to minimize complexity.¶

3.7. OSCORE Protection Boundaries

When µACP is transported over CoAP with OSCORE, the OSCORE-protected CoAP payload MUST contain the complete µACP message (Header | TLVs | Payload). The OSCORE security context determines integrity, confidentiality, and replay parameters.¶

The following MUST be protected by OSCORE:¶

• All TLVs except those in unencrypted PING messages;¶
• The entire payload;¶
• The header fields other than those needed for outer CoAP routing.¶

Implementations MUST NOT leak semantics (e.g., Verb, QoS) through the CoAP outer header beyond what OSCORE permits.¶

3.8. Canonical Encoding Rules

To ensure interoperability and deterministic parsing, µACP defines the following canonical encoding rules:¶

• Fields MUST NOT be padded.¶
• TLVs MUST be sorted by ascending Type.¶
• No two TLVs MAY share the same Type unless explicitly defined.¶
• Payload MUST begin immediately after the last TLV.¶
• Implementations MUST normalize line endings, whitespace, or internal representations before hashing or signing application content.¶

These rules ensure that µACP messages can be compared as byte strings and efficiently parsed on constrained devices.¶

4.1. PING

PING provides a low-cost, minimal-overhead mechanism for reachability and liveness detection. PING messages MUST NOT carry OSCORE-protected content. PING messages MAY include Raw-Octet TLVs (Type=0x00) but MUST NOT include any TLVs requiring confidentiality or integrity.¶

4.2. TELL

TELL conveys information, updates, or asynchronous notifications. TELL is the primary mechanism for distributing state and for responding to ASK messages.¶

TELL messages MUST be OSCORE-protected unless the deployment explicitly allows an unauthenticated mode.¶

4.3. ASK

ASK initiates a request for information or action. ASK is analogous to a query, command, or method invocation, and typically elicits a TELL response.¶

ASK messages MUST be OSCORE-protected.¶

4.4. OBSERVE

OBSERVE establishes a subscription for future notifications. It is analogous to a publish/subscribe registration but scoped to a single peer.¶

OBSERVE messages MUST be OSCORE-protected.¶

4.5. Summary of Normative Requirements

The following summarizes the semantic requirements of each verb:¶

• PING: Liveness probe; MUST NOT require OSCORE; MUST NOT include protected TLVs.¶
• TELL: Update/response/notification; MUST use OSCORE except in explicitly insecure deployments.¶
• ASK: Request; MUST use OSCORE; MUST generate a TELL response.¶
• OBSERVE: Subscription; MUST use OSCORE; MUST create or update subscription state.¶

Agents MUST NOT overload verbs with incompatible semantics. All application-defined behaviors MUST build upon these primitives in a manner that preserves µACP’s resource and security guarantees.¶

5.1. Mapping µACP Messages to CoAP

Each µACP message (Header | TLVs | Payload) is encoded as a byte string and placed entirely within the CoAP message payload. Only OSCORE-protected CoAP messages may carry µACP messages (except PING, which MAY be unprotected under specific deployment configurations).¶

µACP messages MUST use the following CoAP message structure:¶

• Method: POST¶
• URI-Path: "muacp" (fixed path for interoperability)¶
• Content-Format: application/muacp+binary¶
• Payload: Full µACP message¶

This yields the canonical envelope:¶

+-------------------------------+
|  CoAP Header (CON/NON)       |
+-------------------------------+
|  Uri-Path: "muacp"           |
+-------------------------------+
|  Content-Format: muacp+binary|
+-------------------------------+
|  OSCORE Option               |
+-------------------------------+
|  Ciphertext Payload          |
|  (encapsulated µACP message) |
+-------------------------------+

Each µACP message corresponds to exactly one CoAP POST. For request/response interactions (ASK → TELL), CoAP confirmable/non-confirmable messages MAY be used depending on QoS requirements.¶

5.2. OSCORE Protection Requirements

All µACP messages except PING MUST be protected using OSCORE. OSCORE provides confidentiality, integrity, and replay protection independent of the transport layer.¶

OSCORE MUST protect the following elements:¶

• The entire µACP header (except when outer CoAP metadata is required for routing).¶
• All TLVs except raw TLVs permitted for PING.¶
• The entire µACP payload.¶

OSCORE replay protection MUST be enabled. Implementations MUST configure replay windows to match expected message rate and resource constraints.¶

OSCORE MUST use a unique security context per agent-pair. Context reuse between unrelated peers is prohibited.¶

5.3. Establishing OSCORE Security Contexts

Security contexts for OSCORE MAY be derived by any of the following methods:¶

• EDHOC (RECOMMENDED): A lightweight authenticated key exchange protocol suitable for constrained devices.¶
• Pre-Shared Keys (PSK): For deployments with pre-configured trust anchors.¶
• Out-of-band provisioning: Where security associations are established during manufacturing or commissioning.¶

When EDHOC is used, the resulting OSCORE context MUST be bound to the EDHOC handshake transcript to prevent identity misbinding attacks.¶

5.4. CoAP Message Types and Reliability

µACP builds upon CoAP reliability semantics to achieve its QoS model. Implementations MUST map µACP QoS codes to CoAP message types as follows:¶

CoAP-level acknowledgments MUST NOT be interpreted as µACP-level responses. Application responses are always encoded as TELL messages.¶

5.5. Mapping ASK–TELL to CoAP Request/Response

ASK messages MUST be sent as CoAP POST requests. Corresponding TELL responses MUST be sent as CoAP responses. OSCORE MUST protect both directions.¶

The Correlation ID uniquely links the ASK with the TELL response. CoAP Message IDs MUST NOT be used for application correlation.¶

Receivers MUST respond with a TELL message even when requests fail, using an Error TLV to describe failure conditions.¶

Agent A                                Agent B
-------                                -------
POST /muacp (ASK, OSCORE)  ---------->
                     <----------   2.04 Changed (TELL, OSCORE)

5.6. Mapping OBSERVE Subscriptions

OBSERVE establishes a long-lived subscription. Subscriptions are maintained by application logic and do NOT rely on CoAP’s Observe extension (RFC 7641). µACP defines its own subscription model, independent of CoAP's Observe option.¶

OBSERVE MUST be mapped as:¶

• A CoAP POST containing an µACP OBSERVE message.¶
• Notification messages delivered as CoAP POSTs containing TELL messages.¶

Implementations MUST NOT use CoAP Observe for µACP subscriptions, to avoid semantic conflicts.¶

5.7. Congestion Control Requirements

All µACP-over-CoAP deployments MUST implement congestion control to prevent network collapse and unfair bandwidth usage.¶

Agents MUST adhere to the following rules:¶

• Apply exponential backoff on CoAP CON retransmissions.¶
• Rate-limit PING to avoid liveness floods.¶
• Throttle OBSERVE notifications when bandwidth pressure is detected.¶
• Maintain deterministic CPU and buffer usage for message handling.¶
• Avoid generating more than one message per RTT per conversation, except under QoS ≥ 1 retransmission.¶

When Blockwise Transfer (RFC 7959) is used, agents MUST ensure block sizes do not exceed memory limits.¶

5.8. Transport-Layer Error Handling

Transport errors such as CoAP timeouts, OSCORE decryption failures, or missing acknowledgments MUST be translated into µACP-level behavior rather than silently ignored.¶

Specifically:¶

• If OSCORE decryption fails, the µACP message MUST be dropped.¶
• If a CoAP CON message is not acknowledged, the sender MUST apply µACP QoS semantics to determine retransmission.¶
• Repeated timeouts MUST cause the µACP conversation to enter a failure state.¶
• Malformed CoAP envelopes MUST cause message discard.¶

5.9. Summary of MTI Requirements

All compliant µACP implementations MUST:¶

• Support CoAP POST requests to the fixed path "muacp".¶
• Support Content-Format: application/muacp+binary.¶
• Protect all messages except PING with OSCORE.¶
• Enforce OSCORE replay protection.¶
• Derive OSCORE contexts using EDHOC or equivalent secure provisioning.¶
• Map QoS codes to CoAP message types according to the CoAP Message Types and Reliability section.¶
• Generate TELL responses for all ASK messages.¶
• Deliver notifications for active OBSERVE subscriptions as TELL messages.¶

This binding ensures interoperability across all µACP implementations and establishes a minimum security baseline for deployments.¶

6.1. Error Code TLVs

All protocol-level errors MUST be communicated using a TELL message that includes an Error-Code TLV. Error codes are encoded as unsigned integers and MUST follow the registry defined in the IANA Considerations section.¶

Type:   0x22 (Error-Code, see IANA registry)
Length: 1 or 2 octets
Value:  Integer error code

The sender MUST set the Correlation ID of the error response to match the ID of the failing message. Receivers MUST interpret the error code as part of the µACP conversation state.¶

6.2. Standardized Error Conditions

The following error codes are defined for µACP:¶

Implementations MAY define additional vendor-specific error codes in the vendor range but MUST NOT redefine standardized codes.¶

6.3. Handling Malformed Messages

Receivers MUST apply strict validation to protect against malformed messages and resource attacks. Specifically:¶

• If TLV Length exceeds remaining bytes, the message MUST be discarded.¶
• If TLVs appear out of Type order, the message MUST be discarded.¶
• If a required TLV (future versions) is absent, the message MUST be rejected.¶
• If header fields contain invalid combinations (e.g., reserved bits set), the message MUST be rejected.¶
• If OSCORE decryption fails, the message MUST be discarded without error signaling.¶

Where feasible, a receiver SHOULD send a TELL(error) message to report failure, unless doing so would amplify a denial-of-service attack.¶

6.4. Conversation-Lifetime Error Handling

Conversations MAY fail due to timeouts, resource limits, or message corruption. When such failures occur:¶

• The agent MUST free associated resources (conversation-table entries).¶
• The agent SHOULD send an ERR_TIMEOUT or ERR_RESOURCE_EXHAUSTED TELL message.¶
• For resource exhaustion, an agent MUST NOT attempt recovery that risks violating its resource budget.¶

Conversations MUST be terminated when Correlation IDs collide.¶

6.5. Version Negotiation

µACP includes a Version field in the TLV space to allow forward compatibility. A Version-TLV (Type=0x01) MAY be included in any message to indicate the sender’s supported protocol versions.¶

Type:   0x01 (Version)
Length: N (number of supported versions)
Value:  Array of version numbers (e.g., [0x00])

Receivers MUST ignore Version-TLVs indicating versions higher than supported. Receivers MUST accept messages labeled as version 0x00 (this specification) unless malformed.¶

If a message indicates only unsupported versions, the receiver MUST return ERR_VERSION_MISMATCH.¶

6.6. Downgrade and Version-Rollback Protection

Implementations MUST ensure that attackers cannot force a peer to use a lower protocol version when a higher mutually supported version is available.¶

Specifically:¶

• When a Version TLV lists multiple supported versions, the highest mutually supported version MUST be chosen.¶
• Version negotiation MUST occur inside OSCORE-protected messages except for PING.¶
• Agents MUST NOT downgrade versions unless a failure condition explicitly requires fallback.¶

6.7. Extensibility Framework

µACP is designed to evolve through extensible mechanisms based on TLVs. The following constraints ensure future versions remain interoperable:¶

• Forward compatibility: Receivers MUST ignore unknown non-critical TLVs.¶
• Backward compatibility: Implementations MUST NOT reuse TLV Types for different semantics.¶
• Critical TLVs: Future versions MAY introduce critical TLVs; receiving an unsupported critical TLV MUST trigger ERR_UNSUPPORTED_TLV.¶
• TLV ordering: All TLVs MUST be sorted by increasing Type value.¶
• Vendor extensions: Types 128–255 are reserved for vendor-specific semantics and MUST NOT require global registration.¶

Complex or multi-field extensions SHOULD define new structured TLVs rather than overloading primitive types.¶

6.8. Summary of Normative Requirements

This section can be summarized as follows:¶

• Malformed messages MUST be rejected and SHOULD trigger a TELL(error) unless unsafe.¶
• Errors MUST use standardized codes where applicable.¶
• Version negotiation MUST prefer the highest mutually supported version.¶
• Unknown non-critical TLVs MUST be ignored; unknown critical TLVs MUST trigger errors.¶
• OSCORE failures MUST cause silent discard.¶
• Resource exhaustion MUST lead to conservative cleanup behavior.¶

These requirements ensure that µACP remains robust, extensible, and secure across diverse deployments.¶

7.1. µACP TLV Types Registry

IANA is requested to create a new registry entitled "µACP TLV Types". The registry consists of 8-bit values (0–255). Each entry MUST contain:¶

• Value (0–255)¶
• Name¶
• Description¶
• Value format (e.g., integer, UTF-8, CBOR)¶
• Reference¶

The range is divided as follows:¶

• 0–31: Standards Action¶
• 32–127: IETF Review¶
• 128–255: Vendor-specific¶

IANA is requested to populate the registry with the initial values below:¶

Future extensions MUST NOT assign new semantics to existing TLV values.¶

7.2. µACP QoS Codes Registry

IANA is requested to create a registry entitled "µACP QoS Codes". QoS is encoded as a 2-bit field in the header (values 0–3).¶

7.3. µACP Verb Codes Registry

IANA is requested to create a registry entitled "µACP Verb Codes". Verb values occupy 2 bits but are listed numerically (0–3).¶

7.4. µACP Error Codes Registry

IANA is requested to create a registry entitled "µACP Error Codes" consisting of integers 0–255.¶

The initial contents are listed in the Error Handling section. The assignment policy for values 0–127 is IETF Review. Values 128–255 are vendor-specific and use the "First Come First Served" policy.¶

7.5. CoAP Content-Format Registration

IANA is requested to register the following CoAP Content-Format:¶

This Content-Format is mandatory for all µACP-over-CoAP messages.¶

Note: The Content-Format ID value marked as "TBD" will be assigned by IANA during the IESG review process, prior to publication of this document as an RFC. The assignment will follow the "IETF Review" policy as specified in [RFC8126].¶

7.6. Media Type Registration

IANA is requested to register the following media type in the "application" registry:¶

Type name: application
Subtype name: muacp+binary
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: See Security Considerations section.
Interoperability considerations: Defined by TLV and header structure.
Published specification: This document.
Intended usage: COMMON
Author/Change controller: IETF
¶

7.7. Well-Known CoAP Resource

IANA is requested to register the following CoAP Well-Known URI:¶

A CoAP GET to /.well-known/muacp SHOULD return a CBOR structure describing supported TLVs, maximum sizes, and supported versions.¶

7.8. Summary of IANA Actions

IANA is requested to:¶

• Create the µACP TLV Types registry and populate initial values.¶
• Create the µACP QoS Codes registry.¶
• Create the µACP Verb Codes registry.¶
• Create the µACP Error Codes registry.¶
• Register the CoAP Content-Format application/muacp+binary.¶
• Register the media type application/muacp+binary.¶
• Register the well-known CoAP resource /.well-known/muacp.¶

These actions enable interoperable deployment of µACP across implementations and ensure long-term extensibility under IETF governance.¶

8.1. General Event Processing Model

Agents operate according to a deterministic event loop:¶

• Receive µACP message¶
• Validate OSCORE (if required)¶
• Validate header, TLVs, and payload¶
• Identify conversation via Correlation ID¶
• Execute verb-specific FSM transition¶
• Emit resulting messages (if any)¶

Agents MUST support at least 64 concurrent conversations and MUST reject new conversations if resource ceilings are exceeded (ERR_RESOURCE_EXHAUSTED).¶

8.2. ASK/TELL Conversation State Machine

The ASK/TELL FSM governs synchronous (or quasi-synchronous) exchanges where one party issues a request and the peer returns a response. ASK MUST initiate a conversation. TELL completes it.¶

                   +-----------------+
                   |   IDLE          |
                   +-----------------+
                            |
                            | (send ASK)
                            v
                   +-----------------+
                   |   WAIT_RESP     |
                   +-----------------+
                     |        ^
     (recv TELL)     |        | (timeout; QoS=1)
                     v        |
                   +-----------------+
                   |   COMPLETED     |
                   +-----------------+
      (cleanup) --> returns to IDLE

State definitions:¶

• IDLE: No active conversation for this Correlation ID. Sender may emit ASK to enter WAIT_RESP.¶

• WAIT_RESP: ASK has been sent; awaiting TELL.¶

  • If TELL received → transition to COMPLETED.¶
  • If timer expires and QoS=1 → retransmit ASK and reset timer.¶
  • If timer expires and QoS=0 or QoS=2 → transition to COMPLETED with ERR_TIMEOUT.¶

• COMPLETED: Final state.¶

  • Conversation table entry MUST be deleted.¶

Receiver behavior is symmetric: upon receiving ASK, it enters a SERVE_REQ transient state, computes a response, and emits a TELL message. Errors (malformed request, unauthorized action, resource exhaustion) MUST produce a TELL(error) instead of silence.¶

8.3. PING/TELL State Machine

PING serves as a minimal liveness check. PING does not create long-lived conversation state and SHOULD remain extremely lightweight.¶

        +--------+
        |  IDLE  |
        +--------+
            |
            | send PING
            v
        +--------------+
        | WAIT_PONG    |
        +--------------+
            |        ^
   recv TELL|        | timeout (SHOULD NOT retransmit)
            v        |
        +--------------+
        |  COMPLETED   |
        +--------------+

Key requirements:¶

• PING MUST NOT require OSCORE.¶
• PING MUST NOT modify application state.¶
• Receivers SHOULD reply with TELL unless explicitly configured otherwise.¶
• Timeout MUST NOT cause retransmissions (congestive safety).¶

8.4. OBSERVE Subscription State Machine

OBSERVE establishes a long-lived subscription used for event-driven communication. Subscription state MUST be explicitly tracked and MUST enforce resource ceilings.¶

                         +----------------+
                         |   NO_SUB       |
                         +----------------+
                                |
                                | (recv OBSERVE)
                                v
                         +----------------+
                         |  SUBSCRIBED    |
                         +----------------+
                                |
                                | (event trigger)
                                v
                         +----------------+
                         | NOTIFY (TELL)  |
                         +----------------+
                                |
                                | (recv CANCEL_SUB)
                                v
                         +----------------+
                         |  TERMINATED    |
                         +----------------+
                          cleanup → NO_SUB

State definitions:¶

• NO_SUB: No subscription exists for this Correlation ID. Receiving OBSERVE creates subscription state.¶

• SUBSCRIBED: Active subscription.¶

  • Trigger conditions (TLVs) MUST be monitored.¶
  • Subscription MUST expire after configured lifetime unless refreshed.¶
  • Resource limits MUST be enforced (max subscriptions per peer).¶

• NOTIFY: When trigger conditions are met, a TELL message MUST be sent.¶

  • Notifications MUST NOT be sent faster than congestion-control rules permit.¶

• TERMINATED: Subscription canceled via CANCEL_SUB (TLV=0xFF) or due to resource exhaustion.¶

  • All subscription state MUST be deleted.¶

8.5. Error-State Transitions

Errors encountered during processing MUST transition the FSM into a predictable termination state. This prevents deadlocks and resource leaks.¶

• ERR_MALFORMED: Immediately discard message; no state created; MAY send error TELL.¶
• ERR_UNSUPPORTED_TLV: Terminate the offending conversation; MUST send error TELL.¶
• ERR_TIMEOUT: Conversation enters COMPLETED with error; resources MUST be freed.¶
• ERR_RESOURCE_EXHAUSTED: Reject request; MUST NOT allocate new conversation state.¶
• OSCORE failure: Silent discard; MUST NOT leak metadata; MUST NOT update state.¶

8.6. Processing Time and Resource Bounds

Because µACP targets constrained environments, all FSM transitions MUST complete in bounded time and memory.¶

The following limits apply:¶

• Conversation table: MUST support at least 64 active conversations.¶
• Subscription table: MUST support at least 16 active OBSERVE subscriptions.¶
• Per-message processing time: MUST complete within platform-defined real-time bounds.¶
• Message buffers: MUST have deterministic maximum sizes (header+1024-byte TLVs+payload).¶
• Timers: MUST be implemented without per-message dynamic allocation.¶

Platforms MAY employ preallocated memory pools, cyclic buffers, or static tables to satisfy the above constraints.¶

8.7. Summary of Normative FSM Behavior

• ASK MUST initiate a conversation; TELL MUST complete it.¶
• PING MUST remain stateless and congestion-safe.¶
• OBSERVE MUST create explicit subscription state and enforce resource ceilings.¶
• All FSMs MUST terminate in bounded time.¶
• OSCORE failures MUST be silent but MUST NOT permit partial state updates.¶
• Errors MUST produce deterministic transitions to safe terminal states.¶

The FSMs in this section define the interoperable processing model for all conformant µACP agents.¶

9.1. Threat Model

The µACP threat model assumes that attackers may:¶

• Passively eavesdrop on traffic.¶
• Modify, inject, reorder, or replay messages.¶
• Attempt to exhaust memory, CPU, storage, energy, or subscription tables.¶
• Attempt to desynchronize conversation or subscription state.¶
• Conduct traffic analysis to infer system behavior.¶
• Attempt version downgrades or feature-stripping attacks.¶
• Exploit weak random number generation for Correlation IDs.¶
• Exploit incorrect OSCORE configuration (e.g., key reuse, replay window misconfiguration).¶

The protocol provides security only when implemented with OSCORE as defined in the Transport Binding section. Attackers are assumed to have full control of the transport layer but not of OSCORE-protected channels.¶

9.2. Authentication, Integrity, and Identity Binding

All µACP messages except PING MUST be authenticated and integrity-protected using OSCORE. Without OSCORE, µACP messages MUST be considered untrusted and MUST NOT modify system state.¶

OSCORE provides:¶

• Peer authentication (when derived from EDHOC or provisioned credentials),¶
• Integrity protection over header, TLVs, and payload,¶
• Replay protection through sequence numbers and replay windows,¶
• Binding of request/response messages.¶

Implementations MUST use a unique OSCORE security context per communicating peer. Context reuse risks identity substitution or multi-peer cross-contamination attacks.¶

9.3. Confidentiality and Access Control

TELL, ASK, and OBSERVE messages MAY contain sensitive or mission-critical data. These messages MUST be encrypted via OSCORE. Only PING is permitted to be unencrypted.¶

Authorization MUST be enforced at the receiving agent before performing operations triggered by ASK or OBSERVE. Unauthorized or unauthenticated requests MUST be rejected using ERR_FORBIDDEN or silently dropped in high-threat environments.¶

9.4. Replay Prevention and Freshness

µACP relies on OSCORE replay protection. Implementations MUST enable and correctly maintain OSCORE replay windows. Message Sequence IDs and Correlation IDs do not substitute for OSCORE's replay mechanism.¶

Additional replay mitigations:¶

• Receivers SHOULD maintain a per-peer sliding window of recent Sequence IDs.¶
• Subscription-triggered notifications MUST validate freshness before emitting updates.¶
• Agents MUST reject delayed or reordered messages if OSCORE replay windows indicate a stale nonce.¶

Failure to enforce replay semantics MAY allow repeated actions, unexpected state transitions, or resource exhaustion.¶

9.5. Denial-of-Service and Resource Exhaustion

µACP devices frequently operate with strict limits on memory, CPU cycles, and energy. Attackers may attempt to exploit this by flooding the device with requests, subscriptions, or malformed messages. Implementations MUST enforce:¶

• Maximum number of active conversations (minimum 64 required).¶
• Maximum number of OBSERVE subscriptions (minimum 16 required).¶
• Rate limits on incoming PING and ASK messages.¶
• TLV region size limits (max 1024 bytes).¶
• Payload size limits (max 65535 bytes).¶
• Static or preallocated memory pools for message buffers.¶

When limits are exceeded, agents MUST return ERR_RESOURCE_EXHAUSTED or silently drop messages depending on congestion severity.¶

CoAP-level DoS mitigation (exponential backoff, NON vs CON behavior) MUST also be applied per Section 5.7.¶

9.6. Subscription Hijacking and Notification Integrity

OBSERVE introduces long-lived state which attackers may exploit. To prevent hijacking or unauthorized cancellation:¶

• OBSERVE and CANCEL_SUB MUST be OSCORE-protected.¶
• Subscriptions MUST be bound to an authenticated OSCORE context.¶
• Correlation IDs MUST be unpredictable to prevent guessing active subscription identifiers.¶

• Subscription deletion MUST require either:¶

  • a valid CANCEL_SUB message from the same authenticated peer, OR¶
  • timeout or resource exhaustion constraints documented by the implementation.¶
• Agents MUST reject subscription attempts that exceed configured resource ceilings.¶

Failure to enforce these rules could allow attackers to redirect notifications, silence alarms, or manipulate event-driven logic.¶

9.7. Downgrade Protection and Version Attacks

The Version TLV enables forward compatibility but introduces risks of downgrade attacks. Implementations MUST enforce:¶

• The highest mutually supported version MUST be used.¶
• Version negotiation MUST occur under OSCORE, except for PING.¶
• Agents MUST reject messages that advertise only unsupported versions.¶
• Agents MUST NOT fall back silently to lower versions.¶

This prevents attackers from forcing devices into insecure or deprecated protocol variants.¶

9.8. Privacy Considerations

µACP messages may reveal operational state, environmental conditions, unique identifiers, or system topology. OSCORE encryption mitigates most risks, but implementations MUST also consider:¶

• Correlation IDs must not encode identifying information.¶
• Payloads should avoid transmitting sensitive or personal data unnecessarily.¶
• Event-driven OBSERVE notifications may reveal behavioral patterns; rate-limiting reduces leakage.¶
• Well-known URIs may expose protocol usage; returning minimal metadata is RECOMMENDED.¶

Applications MAY use additional payload encryption or anonymization when required by operational policies or regulations.¶

9.9. Traffic Analysis Resistance

Even with OSCORE, attackers may observe message size, frequency, or timing patterns. Implementations SHOULD mitigate traffic analysis when possible:¶

• PING rates should be bounded and randomized.¶
• Regular padding of OSCORE ciphertext MAY be used, subject to energy constraints.¶
• OBSERVE notifications SHOULD avoid revealing high-frequency activity in sensitive deployments.¶

Because µACP operates in constrained environments, padding and obfuscation are OPTIONAL but SHOULD be supported in deployments requiring stronger protection.¶

9.10. Key Management and Lifecycle

OSCORE security depends on proper management of key material. Implementations MUST provide:¶

• Secure key provisioning (EDHOC, pre-shared keys, or manufacturing-time injection).¶
• Rotation of OSCORE master secrets on a schedule appropriate for device lifetime.¶
• Secure deletion of expired or unused keys.¶
• Protection against key reuse across unrelated peers.¶
• Protection of key material against side-channel extraction on constrained hardware.¶

Compromise of OSCORE keys compromises confidentiality, integrity, and authentication for µACP messages.¶

9.11. Safe Failure Modes

Failures MUST NOT cause inconsistent or undefined agent behavior. Specifically:¶

• Malformed messages MUST be discarded without modifying state.¶
• OSCORE failures MUST be silent and MUST NOT produce error messages that could be used for oracle attacks.¶
• Timeouts MUST clean up state deterministically.¶
• Subscription state MUST never persist without authenticated refresh.¶

In safety-critical systems (e.g., water infrastructure, industrial IoT), safe fallback behavior SHOULD be validated through formal analysis or runtime verification.¶

9.12. Summary of Security Requirements

µACP security depends critically on the use of OSCORE and strict adherence to this section’s requirements. At a minimum:¶

• All messages except PING MUST be OSCORE-protected.¶
• Replay windows MUST be enforced.¶
• Subscriptions MUST be authenticated and bounded.¶
• Resource ceilings MUST be applied to prevent DoS.¶
• Version negotiation MUST resist downgrade.¶
• Malformed inputs MUST NOT affect state.¶
• Key management MUST follow secure lifecycle practices.¶

Failure to follow any of these requirements may enable attackers to compromise µACP deployments.¶

10.1. Minimum Interoperability Profile (MIP)

The Minimum Interoperability Profile defines the set of features all µACP agents MUST implement. These requirements ensure that any two µACP-compliant endpoints can communicate reliably and securely.¶

Implementations MUST support:¶

• The µACP 64-bit header format.¶
• All four verbs: PING, TELL, ASK, and OBSERVE.¶
• The TLV processing model (including ordering, ignoring unknown TLVs, and size limits).¶
• The mandatory OSCORE/CoAP transport binding.¶
• Content-Format application/muacp+binary.¶
• Conversation state for at least 64 active Correlation IDs.¶
• Subscription state for at least 16 active OBSERVE subscriptions.¶
• Error-handling behavior as defined in the Error Handling section.¶
• Deterministic state-machine execution as defined in the State Machines section.¶
• Strict enforcement of TLV region and payload size bounds.¶

Any implementation lacking one or more of the above cannot be considered µACP-compliant.¶

10.2. Constrained Node Profile (CNP)

The Constrained Node Profile targets microcontroller-class devices with severe limitations on RAM, energy, and CPU. Devices in this class typically include ARM Cortex-M series, ESP32, and similar embedded platforms.¶

Implementations operating under the CNP MUST:¶

• Use static or preallocated memory buffers for message processing.¶
• Enforce strict upper bounds on subscription count, message buffers, and timers.¶
• Support fragmentation only when required by the underlying transport; otherwise, fragmentation SHOULD be disabled.¶
• Use compact TLVs and avoid optional features requiring large buffers.¶
• Perform minimal logging to avoid overhead.¶
• Restrict payload sizes to what can be safely processed on the platform.¶

Implementations SHOULD:¶

• Use simplified state machines optimized for deterministic resource usage.¶
• Prefer PSK- or EDHOC-based OSCORE contexts instead of heavier PKI-based provisioning.¶
• Disable or heavily restrict vendor-specific TLVs.¶

10.3. Infrastructure Node Profile (INP)

The Infrastructure Node Profile targets devices with moderate-to-high resources such as edge gateways, industrial controllers, and cloud-side collectors. These nodes typically support more extensive logic and higher traffic volumes.¶

Implementations under this profile MUST:¶

• Support full subscription features including complex event conditions.¶
• Support extended TLV sets and vendor-specific extensions.¶
• Maintain replay windows sized for high-throughput communication.¶
• Support EDHOC or equivalent authenticated key exchange mechanisms.¶
• Provide robust error-logging and diagnostics.¶
• Support rate-shaping for downstream constrained nodes.¶

INP nodes MAY:¶

• Provide protocol translation (e.g., convert µACP/OSCORE-CoAP to internal RPC or message bus formats).¶
• Use hardware acceleration for crypto operations when available.¶
• Implement adaptive batching or aggregation of TELL notifications for efficiency.¶

10.4. Cross-Profile Interoperability

µACP is designed to allow interoperability between constrained and infrastructure nodes. The following rules ensure safe cross-profile communication:¶

• Messages sent from INP nodes MUST adhere to the resource ceilings of peer CNP nodes.¶
• INP nodes MUST NOT send payloads or TLVs exceeding the max supported size of constrained nodes.¶
• INP nodes SHOULD apply traffic shaping to avoid overwhelming constrained devices.¶
• CNP nodes MUST ignore unsupported TLVs without entering error states.¶
• CNP nodes MAY restrict OBSERVE features to static or simple triggers.¶
• Fallback to the Minimum Interoperability Profile MUST always be possible.¶

Implementations MUST guarantee that all profile interactions preserve the security properties defined in the Security Considerations section.¶

10.5. Deployment Profiles

Deployments may apply µACP in different operational environments. This subsection defines three common deployment profiles and associated requirements.¶

10.6. Feature Negotiation

Feature discovery occurs using a GET request to the well-known resource /.well-known/muacp. The response SHOULD include a CBOR map containing:¶

• Maximum TLV size supported¶
• Maximum payload size¶
• Supported TLV types¶
• Supported verbs (always all four)¶
• Supported µACP versions¶
• Supported congestion control modes¶

Nodes SHOULD cache feature negotiation results until expiration or reboot.¶

10.7. Deterministic Fallback Behavior

To guarantee interoperability even when nodes support different feature sets, µACP defines the following fallback rules:¶

• Unknown TLVs MUST be ignored.¶
• Unsupported features MUST degrade to MIP (Minimum Interoperability Profile).¶
• Subscription requests exceeding CNP limits MUST return ERR_RESOURCE_EXHAUSTED.¶
• If version negotiation fails, agents MUST return ERR_VERSION_MISMATCH.¶
• If congestion control features are unsupported, agents MUST revert to CoAP default mechanisms.¶

Fallback MUST preserve safety and integrity, even if advanced features are unavailable.¶

10.8. Summary of Interoperability Requirements

µACP interoperability depends on:¶

• Universal support for the Minimum Interoperability Profile.¶
• Profiles for constrained nodes and infrastructure nodes.¶
• Deterministic FSM processing as defined in the State Machines section.¶
• Mandatory OSCORE/CoAP transport.¶
• Safe fallback when encountering unsupported features.¶
• Strict enforcement of resource ceilings.¶

These requirements ensure reliable communication across heterogeneous ecosystems, from microcontroller devices to large-scale industrial or cloud deployments.¶

11.1. Notation

The examples below use the following conventions:¶

• H: µACP Header (64 bits)¶
• Tn: nth TLV (Type-Length-Value)¶
• P: Payload¶
• C: CoAP envelope¶
• OS: OSCORE encryption wrapper¶
• CBOR[...]: CBOR structure encoded into bytes¶

11.2. Minimal PING (unencrypted)

A minimal PING contains only the µACP header and MUST NOT be OSCORE-protected.¶

H = 00 01   # Sequence ID = 1
    00 01   # Correlation ID = 1
    00      # QoS = 0 (fire-and-forget)
    00      # Verb = 0 (PING)
    00      # Flags = 0
    00 00 00 00 00   # Reserved

No TLVs, no payload.¶

11.3. ASK with CBOR Payload (unprotected example)

This example shows an ASK containing a CBOR payload before OSCORE protection is applied.¶

CBOR payload representation:¶

CBOR = { "action": "read", "resource": "temperature" }
CBOR (hex) = A2 66 61 63 74 69 6F 6E 64 72 65 61 64
                 68 72 65 73 6F 75 72 63 65 6A 74 65 6D 70

Message:¶

H  = 10 02   # SeqID=0x1002
     10 02   # CorrID=0x1002
     40      # QoS=1 (at-least-once)
     20      # Verb=2 (ASK)
     00      # Flags
     00 00 00 00 00

T1 = 03 1A  A2 66 61 63 ... 70
     |  |   |
   Type Len  CBOR data (26 bytes)

Final (pre-OSCORE) encoding:
10 02 10 02 40 20 00 00 00 00
03 1A A2 66 61 63 ... 70

11.4. ASK/TELL over OSCORE

This example illustrates a complete OSCORE-protected request/response using CoAP POST.¶

Step 1 — ASK wrapped in CoAP + OSCORE:¶

CoAP Header:
  44 02 7A 10        # CON, POST, MID=0x7A10
Uri-Path: "muacp"
Content-Format: application/muacp+binary
OSCORE Option: 9F (example)
Payload (ciphertext):
  d4 83 58 20 a1 b3 11 ... (encrypted µACP)

Step 2 — TELL response:¶

CoAP Header:
  64 44 7A 10        # ACK, 2.04 Changed
Payload (ciphertext):
  e1 91 3A 0F 90 ... (encrypted TELL)

11.5. OBSERVE Subscription (OSCORE-protected)

This example shows how an OBSERVE message establishes a subscription.¶

H  = 20 05 20 05 40 30 00 00 00 00  # Verb=3 (OBSERVE)

T1 = 20 03 74 65 6D                 # Topic="tem"

OSCORE-protected payload:
  58 2A 95 B2 11 D9 ...             # ciphertext

Subsequent notifications are sent as TELL messages sharing the Correlation ID 0x2005.¶

11.6. Subscription Cancellation

A peer cancels an active subscription by sending CANCEL_SUB.¶

H  = 20 05 20 05 40 30 00 00 00 00

T1 = FF 00   # CANCEL_SUB, empty TLV

OSCORE ciphertext:
  6A 7F A9 ...

11.7. Error TELL with Error-Code TLV

This example shows a TELL(error) response containing ERR_UNSUPPORTED_TLV.¶

H  = 10 02 10 02 40 10 00 00 00 00  # Verb=TELL (1)

T1 = 22 01 03   # Error-Code TLV, Len=1, Value=0x03 (ERR_UNSUPPORTED_TLV)

Payload = (optional diagnostic string)

Encrypted via OSCORE:
  5F 21 8A E3 ...

11.8. Fragmentation via CoAP Blockwise

µACP does not define native fragmentation but MAY rely on CoAP Blockwise Transfer (RFC 7959). The µACP message remains intact inside each CoAP block.¶

Example (two blocks):¶

Block 0:
  CoAP Header + Block1 Option (NUM=0, M=1, SZX=2)
  Payload: µACP bytes [0..255]

Block 1:
  CoAP Header + Block1 Option (NUM=1, M=0, SZX=2)
  Payload: µACP bytes [256..end]

Receivers MUST reassemble blocks before OSCORE processing when the OSCORE option is Outer.¶

11.9. Summary

The examples in this section demonstrate:¶

• Minimal µACP messages.¶
• CBOR-encoded payloads.¶
• OSCORE-protected messages inside CoAP POST.¶
• Full ASK/TELL interaction.¶
• OBSERVE subscription and cancellation lifecycles.¶
• Error signaling via TELL(error).¶
• Fragmentation via CoAP Blockwise Transfer.¶

These examples are normative for message formatting and MUST be used for interoperability testing.¶

12.1. Test Categories

Conformance tests are grouped into the following categories:¶

• Header and TLV Encoding Tests¶
• Parser Robustness and Error Handling Tests¶
• State-Machine Behavior Tests¶
• OSCORE Security Tests¶
• Replay and Freshness Tests¶
• Subscription Lifecycle Tests¶
• Resource Constraint Enforcement Tests¶
• Interoperability Tests¶

12.2. Header and TLV Encoding Tests

Implementations MUST correctly encode and decode the 64-bit header and all mandatory TLV behaviors.¶

• H1: Verify correct parsing of all header fields (Verb, QoS, Flags, Sequence ID, Correlation ID, Reserved).¶
• H2: Reserved bits MUST be ignored on input and encoded as zero on output.¶
• H3: TLV region length MUST NOT exceed 1024 bytes.¶
• H4: Unknown TLV types MUST be ignored without entering an error state.¶
• H5: TLV Length MUST be strictly respected; truncated TLVs MUST cause message rejection.¶
• H6: TLV Type 0x00 (Raw Octets) MUST be rejected in OSCORE-protected messages.¶
• H7: Test vectors in the Wire Examples section MUST decode successfully.¶

12.3. Parser Robustness Tests

Implementations MUST handle malformed or adversarial input safely and deterministically.¶

• P1: Malformed headers MUST cause silent discard.¶
• P2: Oversized payloads MUST be rejected with ERR_PAYLOAD_TOO_LARGE.¶
• P3: Invalid TLV lengths MUST trigger ERR_MALFORMED_TLV.¶
• P4: Excessive nested TLVs MUST NOT cause unbounded memory allocation.¶
• P5: Invalid Verb codes MUST trigger ERR_UNSUPPORTED_VERB.¶
• P6: Messages exceeding local memory capacity MUST trigger ERR_RESOURCE_EXHAUSTED.¶

12.4. State-Machine Behavior Tests

Agents MUST implement the state machines defined in the State Machines section. These tests validate deterministic transitions.¶

• FSM1: ASK MUST create a conversation and transition to WAIT_RESP.¶
• FSM2: Receipt of TELL MUST transition the conversation to COMPLETED.¶
• FSM3: Timeout behavior MUST match QoS semantics (QoS=1 → retransmit; QoS=0/2 → terminate).¶
• FSM4: OBSERVE MUST create a subscription; notifications MUST reuse the Correlation ID.¶
• FSM5: CANCEL_SUB MUST delete subscription state.¶
• FSM6: PING MUST NOT allocate conversation state.¶
• FSM7: Error conditions MUST terminate conversations deterministically.¶

12.5. OSCORE Security Tests

Since µACP relies on OSCORE for security, implementations MUST pass all OSCORE-related checks.¶

• S1: OSCORE MUST authenticate and decrypt TELL, ASK, and OBSERVE messages.¶
• S2: OSCORE failures MUST cause silent discard and MUST NOT leak metadata.¶
• S3: Replay windows MUST be enforced (test using replayed ciphertext).¶
• S4: OSCORE contexts MUST NOT be reused across peers.¶
• S5: Downgrade attempts (e.g., forcing version=0) MUST be detected and rejected.¶
• S6: Incorrect nonce reuse MUST be rejected by the recipient.¶

12.6. Replay and Freshness Tests

• R1: Replaying ASK messages MUST NOT trigger repeated actions.¶
• R2: Replayed OBSERVE notifications MUST be rejected.¶
• R3: Correlation IDs MUST prevent cross-conversation replay.¶
• R4: Freshness MUST be derived from OSCORE sequence numbers.¶

12.7. Subscription Lifecycle Tests

• SUB1: OBSERVE MUST create subscription state.¶
• SUB2: TELL notifications MUST reuse the Correlation ID.¶
• SUB3: Subscription expiration MUST delete state deterministically.¶
• SUB4: CANCEL_SUB MUST be accepted only from the authenticated subscriber.¶
• SUB5: Unauthorized CANCEL_SUB MUST be rejected.¶
• SUB6: Subscriptions MUST respect configured resource ceilings.¶

12.8. Resource Constraint Enforcement Tests

Since µACP targets constrained devices, correct enforcement of resource ceilings is mandatory.¶

• RC1: Maximum conversation entries MUST NOT exceed configured table size.¶
• RC2: Maximum active subscriptions MUST NOT exceed resource ceilings.¶
• RC3: Excessive simultaneous ASK messages MUST trigger ERR_RESOURCE_EXHAUSTED.¶
• RC4: TLV section > 1024 bytes MUST be rejected.¶
• RC5: Payload > 65535 bytes MUST be rejected.¶
• RC6: Message processing MUST complete within bounded time (platform-defined).¶

12.9. Interoperability Tests

Two independent implementations MUST successfully interoperate under the Minimum Interoperability Profile. Specifically:¶

• I1: A conformant ASK from Implementation A MUST produce a conformant TELL from Implementation B.¶
• I2: OBSERVE/NOTIFY MUST interoperate across different profiles (CNP ↔ INP).¶
• I3: Unknown TLVs from A MUST NOT break B, and vice versa.¶
• I4: Feature negotiation via /.well-known/muacp MUST correctly determine shared feature sets.¶
• I5: Two implementations MUST successfully exchange OSCORE-protected messages.¶

Successful completion of these tests is required for interoperability certification.¶

12.10. Summary

µACP implementations MUST:¶

• Correctly parse and construct messages.¶
• Implement the mandatory state machines.¶
• Use OSCORE correctly and securely.¶
• Reject malformed or adversarial input safely.¶
• Enforce all resource ceilings.¶
• Support cross-profile interoperability.¶

Passing the tests in this section validates full compliance with the µACP specification.¶

Microcontroller-Class Platforms

µACP was deployed on several microcontroller platforms, including ARM Cortex-M4 systems with 128–256 KB of RAM and ESP32-class devices. These environments were used to test the feasibility of a stateful agent communication protocol under strict memory ceilings.¶

Findings:¶

• The 64-bit header imposed negligible overhead even at small packet sizes.¶
• The 1024-byte TLV limit aligned well with static buffer allocations typical for embedded OSes.¶
• Conversation tables of 64 entries were sustainable without heap allocation, using fixed-size ring buffers.¶
• OBSERVE subscription tables could reliably support 8–16 entries on 128 KB RAM platforms.¶
• Deterministic FSM transitions reduced jitter and enabled predictable energy usage patterns.¶
• OSCORE with pre-shared keys introduced acceptable latency; handshake-based EDHOC was tested only at bootstrapping time.¶

These deployments confirmed that µACP is implementable without dynamic memory allocation when necessary.¶

Field Deployments in Sensor Networks

µACP was evaluated in multi-hop environmental sensing networks resembling municipal or agricultural deployments. Network conditions included lossy wireless links, non-uniform latency, and periodic power cycling of end devices.¶

Observations:¶

• ASK/TELL reliability semantics (QoS=1) were robust under intermittent packet loss.¶
• OBSERVE-based alerting was significantly more energy-efficient than periodic polling.¶
• PING-based liveness detection enabled failure suspicion in the absence of transport-level keepalives.¶
• Nodes with duty-cycled radios exhibited predictable behavior under µACP’s timeout rules.¶
• Replay protection from OSCORE remained stable despite low transmission duty cycles, provided replay windows were properly maintained across reboots.¶

These experiments validated the protocol’s suitability for real-world constrained deployments where energy and bandwidth are critical resources.¶

Industrial and SCADA Edge Systems

µACP was tested on industrial gateways and lightweight SCADA-edge processors deployed alongside programmable logic controllers (PLCs). These environments imposed strict timing and reliability requirements.¶

Key outcomes:¶

• State machines implemented in native code met deterministic execution deadlines.¶
• OBSERVE triggers for threshold-based alerts (e.g., pump failures, pressure anomalies) reliably propagated within bounded latency.¶
• OSCORE ensured confidentiality for telemetry flows that otherwise traverse untrusted industrial networks.¶
• The protocol’s minimalism reduced audit surface relative to application-specific RPC mechanisms.¶
• Error signaling via TELL(error) simplified controller logic and improved fault isolation.¶

Experience demonstrated that µACP can serve as a standardizable alternative to custom messaging formats common in industrial IoT deployments.¶

Edge-to-Cloud Aggregation

µACP agents running on gateways aggregated sensor reports from hundreds of constrained nodes and forwarded aggregated results to cloud backends.¶

Observed behaviors:¶

• Aggregators used TELL messages to batch data from multiple nodes efficiently.¶
• CoAP Blockwise Transfer was required for large analytic payloads; reassembly overhead remained manageable.¶
• Intermittent uplinks did not disrupt resource accounting or FSM behavior.¶
• Capability discovery via /.well-known/muacp allowed gateways to adjust output rates per node.¶
• Key rotation for OSCORE contexts scaled to hundreds of peers without significant performance penalties.¶

Deployment results confirmed µACP’s applicability to hierarchical network architectures where constrained devices feed into more capable intermediate nodes.¶

Lessons Learned

The following lessons influenced normative requirements in this specification:¶

• Strict TLV bounds and deterministic parser behavior significantly reduce memory exhaustion risks.¶
• Correlation IDs MUST be random or pseudo-random; predictable patterns caused cross-conversation interference during testing.¶
• OBSERVE subscriptions MUST have bounded lifetimes; several field deployments produced orphaned subscriptions without this rule.¶
• OSCORE replay windows MUST persist across device reboots to avoid accepting stale messages.¶
• PING MUST remain unencrypted to remain lightweight and congestion-safe.¶

These observations strengthened several MUST and SHOULD requirements in the main document.¶

Reference Implementations

The following reference implementations of µACP are available for interoperability testing and evaluation:¶

• MAL-ACP: A reference implementation in C++/Python targeting embedded platforms, available at https://github.com/arnab-m1/miuACP. This implementation includes support for all four message types (PING, TELL, ASK, OBSERVE), OSCORE/CoAP transport binding, state machine implementations, and conformance test suites.¶
• Platform Support: Implementations have been tested on ARM Cortex-M4, ESP32, and Linux-based edge gateways, demonstrating cross-platform interoperability.¶
• Interoperability: Multiple independent implementations have successfully exchanged messages and completed conformance test suites, validating the protocol specification's completeness and clarity.¶

These implementations serve as normative references for the protocol behavior described in this document and are available for implementers seeking to build interoperable µACP agents.¶

Summary

Across all deployments examined—microcontroller nodes, sensor networks, industrial gateways, and edge-to-cloud systems—µACP demonstrated stable behavior, predictable resource usage, and low implementation complexity. Deployment results provide empirical support for the protocol’s design and its standardization as a lightweight, interoperable agent communication substrate.¶

Minimal Messages

Minimal PING (unencrypted)¶

# µACP Header Only (PING)
00 01   # Sequence ID
00 01   # Correlation ID
00      # QoS=0
00      # Verb=PING
00      # Flags
00 00 00 00 00   # Reserved

Minimal TELL with empty payload (unencrypted)¶

# Header
00 02 00 02 00 10 00 00 00 00

# No TLVs
# No payload

ASK/TELL with CBOR payloads

B.2.1 ASK with TLV(Content-Format=1) and CBOR payload¶

# Header
10 02 10 02 40 20 00 00 00 00

# TLV: Content-Format (Type=0x03, Len=1, Val=0x01)
03 01 01

# Payload (CBOR)
A2 66 61 63 74 69 6F 6E        # "action"
64 72 65 61 64                 # "read"
68 72 65 73 6F 75 72 63 65     # "resource"
6A 74 65 6D 70                 # "temp"

B.2.2 TELL response with TLV(error=NONE) and CBOR payload¶

# Header
10 02 10 02 40 10 00 00 00 00  # Verb=TELL

# TLV: Error-Code=0x00
02 01 00

# Payload (CBOR): { "value": 21.5 }
A1 65 76 61 6C 75 65 F9 41 AC

OSCORE-Protected Test Vectors

These examples use placeholder keys and nonces; they are not security-strength values. Their purpose is deterministic parser testing.¶

B.3.1 ASK inside OSCORE/CoAP¶

CoAP Header:
44 02 7A 10

OSCORE Option:
9F

Encrypted Payload (ciphertext only):
D4 83 58 20 A1 B3 C4 99 02 5D
11 0A C8 EE 73 71 4F 52 B0 C8
76 DA 91 22 10 9C 5E 33 81 15

B.3.2 TELL response with encrypted TLV + payload¶

CoAP Header:
64 44 7A 10

Encrypted Payload:
E1 91 3A 0F 90 77 32 A2 9B AE
6C F2 45 51 60 82 81 12 00 44
75 9A 2C 18 3D 11

OBSERVE Subscription Lifecycle

B.4.1 OBSERVE Creation (OSCORE-protected)¶

Header:
20 05 20 05 40 30 00 00 00 00

TLV: Topic="temp"
20 03 74 65 6D

Encrypted Payload:
58 2A 95 B2 11 D9 0A 9F 77 20 12 88 ...

B.4.2 Notification TELL reusing Correlation ID¶

Header:
20 05 20 05 40 10 00 00 00 00

TLV: Content-Type=1
03 01 01

Encrypted Payload:
9A 71 3C 88 A0 45 3E 12 99 ...

B.4.3 CANCEL_SUB TLV example¶

Header:
20 05 20 05 40 30 00 00 00 00

TLV: CANCEL_SUB (Type=0xFF, Len=0)
FF 00

Encrypted Payload:
6A 7F A9 D4 82 21 ...

Error Path Test Vectors

B.5.1 Unsupported TLV (expected to trigger ERR_UNSUPPORTED_TLV)¶

Header:
00 10 00 10 40 20 00 00 00 00

Unknown TLV Type=0x47
47 03 01 02 03

Payload: none

B.5.2 Malformed TLV length¶

Header:
00 10 00 10 40 20 00 00 00 00

TLV declares 10 bytes but only 4 follow:
22 0A 11 22 33 44

B.5.3 Oversized payload (>65535 bytes)¶

Omitted for brevity; implementers MUST reject any payload exceeding the 16-bit payload size constraint.¶

B.6 CoAP Blockwise Fragmentation

These examples illustrate partial µACP messages inside CoAP Block1 fragments.¶

B.6.1 Block 0¶

CoAP Header:
44 02 6A 77

Block1 Option:
2F 00   # NUM=0, M=1, SZX=0

Payload:
<first 64 bytes of encrypted µACP blob>

B.6.2 Block 1¶

CoAP Header:
44 02 6A 77

Block1 Option:
2F 11   # NUM=1, M=0, SZX=0

Payload:
<remaining bytes of encrypted µACP blob>

Receivers MUST reassemble before OSCORE decryption.¶

B.7 Summary

The test vectors in this appendix supplement those in Section 11 and are intended for parser verification, fuzzing, and interoperability testing. Implementations MUST be able to:¶

• Decode and validate all example headers.¶
• Correctly process TLVs, including multi-TLV messages.¶
• Reject malformed structures deterministically.¶
• Decrypt OSCORE ciphertexts after correct envelope processing.¶
• Reassemble Blockwise fragments prior to OSCORE processing.¶

These vectors serve as a baseline for µACP test suites and conformance validation frameworks.¶

C.1 Agent Configuration

A µACP agent is represented as a tuple:¶

A = (S, Q, R, C, B)

Where:
  S : Local state of the agent (application-defined)
  Q : Incoming message queue
  R : Resource budget (CPU, memory, bandwidth)
  C : Conversation table mapping correlation IDs to conversation state
  B : Subscription table mapping topics to observers

Global system configurations consist of a multiset of agents and an abstract network buffer N:¶

⟨ A1 | A2 | ... | An ; N ⟩

Network delivery is modeled as nondeterministic but eventually fair unless congestion semantics dictate otherwise.¶

C.2 Message Syntax

Messages are modeled abstractly as:¶

M ::= PING(id, cid)
    | TELL(id, cid, tlvs, payload)
    | ASK(id, cid, tlvs, payload)
    | OBSERVE(id, cid, topic, filter)

The semantics below assume well-formed headers and TLVs; malformed messages trigger error semantics (Section C.7).¶

C.3 Operational Semantics for µACP Verbs

A = (S, Q, R, C, B)
--------------------------------------------
A ⟶ A' = (S, Q, R', C, B)

Where R' = R - cost(ping)

A = (S, Q, R, C, B)
------------------------------------------
A ⟶ A' = (S ⊎ payload, Q, R', C, B)

Where:
  R' = R - cost(tell)
  '⊎' denotes a monotonic, application-defined merge

A = (S, Q, R, C, B)
cid ∉ dom(C)
---------------------------------------------------
A ⟶ A' = (S, Q, R', C[cid ↦ wait(action)], B)

Where R' = R - cost(ask)

C[cid] = wait(action)
S ⊢ action ⇓ value
---------------------------------------------------
A ⟶ A' = (S, Q ∪ {TELL(cid, value)}, R', C', B)

Where:
  C' = C[cid ↦ done]
  R' = R - cost(eval)

A = (S, Q, R, C, B)
topic ∉ dom(B)
-------------------------------------------------------
A ⟶ A' = (S, Q, R', C, B[topic ↦ {cid}])

Where R' = R - cost(observe)

B(topic) = CIDs
S ⟶ S' with event e matching filter
-------------------------------------------------------
A ⟶ A' with Q' = Q ∪ { TELL(cid, e) | cid ∈ CIDs }

C.4 Correlation Table Semantics

The correlation table C tracks conversation state with the invariant:¶

dom(C) ≤ MAX_CONV
cid uniqueness: cid ∉ dom(C) for new conversations

Expiration semantics remove entries automatically after a timeout:¶

C[cid] = wait(x)
expired(cid)
------------------------------------
C' = C \ {cid}

C.5 Resource Semantics

The resource model associates a cost with each transition.¶

cost : Transition → ℕ

A transition is only admissible if the agent has sufficient budget:¶

R ≥ cost(t)
⟨ A ; N ⟩ ⟶ₜ ⟨ A' ; N' ⟩
------------------------------------
Transition allowed

Otherwise: A blocks or drops the message

Resource recharging (e.g., periodic replenishment) is allowed but not modeled directly in these semantics.¶

C.6 Fragmentation and Reassembly

Fragmentation is represented as a sequence of partial messages delivered independently:¶

frag(M) = [m0, m1, ..., mk]

Reassembly occurs only when all fragments are received:¶

∀i. mi ∈ N
------------------------------------
reassemble(frag(M)) = M

OSCORE decryption applies only after full reassembly; this preserves security invariants.¶

C.7 Error Semantics

Malformed messages or security violations produce error transitions.¶

C.7.1 Malformed TLV¶

invalid_tlv(M)
------------------------------------
A ⟶ A' = (S, Q ∪ {TELL(cid, ERR_MALFORMED_TLV)}, R', C, B)

not authorized(action, S)
------------------------------------
A ⟶ TELL(cid, ERR_UNAUTHORIZED)

ver(M) < ver(A)
------------------------------------
A ⟶ TELL(cid, ERR_VERSION_MISMATCH)

Summary

The semantics in this appendix capture the behavior of µACP agents, including the message lifecycle, conversation tracking, resource limits, fragmentation, error handling, and observable side effects. These rules closely reflect the informal operational description in the main sections of this specification and serve as a foundation for formal verification, conformance testing, and correct-by-construction implementations.¶