Centre for Development of Advanced Computing (CDAC)

Hyderabad IN arnabm@cdac.in

Centre for Development of Advanced Computing (CDAC)

Hyderabad IN indravenik@cdac.in

Internet Independent Submission This document specifies the Micro Agent Communication Protocol (µACP), a resource-efficient messaging protocol for autonomous agents operating on resource-constrained Edge and IoT devices (including Class 1 and Class 2 devices per ). Existing agent communication protocols assume unbounded computational and energy resources; µACP provides bounded resource consumption guarantees with deterministic memory bounds (8-byte header, up to 1024-byte TLV region, up to 65535-byte payload) and bounded processing time per message, while maintaining expressiveness sufficient for finite-state coordination patterns. The protocol defines four core message types, a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE security binding for operation in adversarial environments. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

The Micro Agent Communication Protocol (µACP) is a compact, resource-efficient communication protocol designed for distributed autonomous agents operating on resource-constrained Edge and IoT devices (including Class 1 and Class 2 devices per ). It aims to bridge the gap between resource-light IoT protocols and semantically rich agent communication languages, by offering minimal overhead yet expressive interaction semantics. Modern IoT, edge, and embedded environments involve devices with limited RAM, CPU, energy, and unreliable networks. Distributed applications require coordination, state sharing, event subscriptions, and request/response semantics. Traditional agent-communication languages impose heavy overhead unacceptable on microcontroller-class platforms, while standard IoT protocols provide minimal semantics. µACP addresses this by defining a wire-efficient, fixed-header, TLV-extensible protocol with four core verbs (PING, TELL, ASK, OBSERVE) sufficient for request/response, publish/subscribe, and liveness checking. The protocol enables lean, deterministic implementations suitable for microcontroller-class devices while supporting structured multi-agent interactions. Formal foundations including resource bounds and safety verification are established in . This specification mandates CoAP with OSCORE as the mandatory-to-implement transport binding, ensuring end-to-end confidentiality, integrity, and replay protection for constrained devices.

µACP aims to: provide minimal, low-overhead communication for constrained agents with structured semantics; ensure deterministic and bounded resource usage; support essential multi-agent patterns (request/response, publish/subscribe, liveness) using four orthogonal primitives; define a secure, interoperable transport binding; enable extensibility via TLV options without breaking compatibility.

This specification defines the wire format, core semantics, normative behavior, mandatory transport binding, security constraints, and IANA registries. It does not specify application-level semantics (content encoding, agent ontology, high-level negotiation), which are left to deployment-specific or higher-layer protocols.

Sections 2-3 define conventions, terminology, and message encoding. Sections 4-5 define protocol semantics and the mandatory CoAP/OSCORE transport binding. Sections 6-7 cover error handling, version negotiation, and IANA registries. Sections 8-9 define state machines and security considerations. Sections 10-11 cover interoperability profiles, wire examples, and conformance tests.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when they appear in ALL CAPS. These words may also appear in lowercase or mixed case as plain English words, absent their normative meanings.

Key terms: Agent—autonomous software entity participating in µACP communication; Verb—one of four primitives (PING, TELL, ASK, OBSERVE) encoded in 2 bits; TLV—Type-Length-Value encoding (8-bit Type, 8-bit Length, variable Value); Correlation ID—16-bit identifier grouping messages into a conversation; Sequence ID—16-bit monotonically increasing identifier for duplicate detection; Conversation—sequence of related messages identified by Correlation ID; OSCORE—Object Security for Constrained RESTful Environments ; CoAP—Constrained Application Protocol ; Constrained Device—device with limited resources per (Class 1: ~10 KB RAM/100 KB flash; Class 2: ~50 KB RAM/250 KB flash).

Notation: hexadecimal values prefixed with "0x"; binary values prefixed with "0b"; network byte order (big-endian) unless otherwise specified; bit positions numbered from 0 (MSB) to n-1 (LSB); message formats shown using ASCII art diagrams.

Abbreviations: CBOR (Concise Binary Object Representation ), CID (Correlation ID), CoAP (Constrained Application Protocol), COSE (CBOR Object Signing and Encryption ), EDHOC (Ephemeral Diffie-Hellman Over COSE ), 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).

This section defines the normative wire-level encoding of µACP messages, including the fixed header, TLV format, payload processing rules, byte ordering, and OSCORE protection boundaries. All compliant implementations MUST follow these encoding rules exactly unless otherwise specified.

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

Figure 1: µACP Message Layout

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 if used. All fields are encoded in network byte order (big-endian).

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

Figure 2: µACP Header Bit Layout

Sequence ID (16 bits, bytes 0-1): Monotonically increasing identifier used for duplicate detection and replay-window tracking. Sequence ID is per-sender (per OSCORE security context) and monotonically increases within each sender's message stream. MUST wrap modulo 2^16. Sequence ID SHOULD be initialized to a random value (not 0) to prevent predictability and traffic analysis. Initialization to 0 is acceptable only when: (1) establishing a new OSCORE security context, (2) no prior communication history exists with the peer, and (3) the initialization is synchronized with the establishment of the new OSCORE context. In all other cases, Sequence IDs MUST be initialized to a random value. Sequence IDs MUST be unpredictable if security-sensitive traffic requires preventing traffic analysis. Correlation ID (16 bits, bytes 2-3): Identifies all messages belonging to the same conversation. Correlation ID MUST be unique among active conversations from the same sender (same OSCORE security context). Different senders may independently use the same Correlation ID values, as conversations are scoped per OSCORE security context. SHOULD be randomly generated in security-sensitive deployments. QoS (2 bits, byte 4 bits 0-1): Encodes transmission semantics (fire-and-forget, at-least-once, at-most-once). Values are defined in the IANA Considerations section. Verb (2 bits, byte 4 bits 2-3): Identifies one of the four µACP operations: PING(0), TELL(1), ASK(2), OBSERVE(3). Flags (4 bits, byte 4 bits 4-7): Control bits reserved for protocol-level features such as fragmentation, retransmission hints, or message cancellation. Future specifications MAY define additional meanings. Reserved (24 bits, bytes 5-7): MUST be set to zero on transmission and ignored by receivers. Reserved bits MAY be repurposed by future µACP versions but MUST NOT change meaning in this version.

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.

Figure 3: TLV Encoding

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 (0-255). The Length field MUST NOT exceed 255. Receivers MUST validate that the declared Length does not exceed the remaining message buffer before reading the Value field. Each individual TLV's Value field MUST NOT exceed 255 octets. The total TLV region (sum of all TLV lengths plus their Type and Length fields) MUST NOT exceed 1024 bytes. Implementations MUST validate both constraints: individual TLV length ≤ 255 and total TLV region ≤ 1024 bytes. Value: Encoded according to Type. For Types other than 0x00 (Raw Octets), the Value is subject to OSCORE protection (). Critical TLVs: A future TLV Type range MAY designate critical TLVs. Receiving an unknown critical TLV MUST cause message rejection.

Receivers MUST apply the following rules when processing TLVs:

• TLVs MUST be parsed strictly in order.
• If Length exceeds remaining buffer size, the message MUST be discarded.
• Unknown TLV Types MUST be ignored unless they are designated critical.
• TLV order MUST be strictly increasing by Type; violating this is a format error.
• TLV Type 0x00 (Raw Octets) MUST NOT appear in encrypted messages; its use is restricted to unencrypted PING messages.

The µACP payload is an optional octet string of 0–65535 bytes used for application data, action parameters, event notifications, or encoded content (CBOR, JSON). Payloads MUST be OSCORE-protected unless the message Verb is PING. Payload sizes MUST be validated before allocation. If encoded using CBOR (Type=0x03), receivers MUST treat it as a single CBOR data item. If JSON (Type=0x02), it MUST be UTF-8 encoded.

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.

µACP does not mandate fragmentation. TLV Type 0x10 is reserved for future fragmentation specification but MUST NOT be used until fully specified. Deployments using CoAP Blockwise Transfer SHOULD avoid µACP-level fragmentation.

When µACP is transported over CoAP with OSCORE, the OSCORE-protected CoAP payload MUST contain the complete µACP message (Header | TLVs | Payload). OSCORE MUST protect: all TLVs except those in unencrypted PING messages, the entire payload, and 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.

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.

This section defines the normative semantics of the four µACP verbs: PING, TELL, ASK, and OBSERVE. Each verb represents a fundamental communication primitive intended to support higher-level agent behaviors, including liveness detection, request/response interactions, state dissemination, and event-driven notification. Agents MUST implement all four verbs. Agents MUST apply OSCORE protection to all messages except PING, unless an application explicitly operates in an unauthenticated environment. For each verb, this section defines sender behavior, receiver behavior, state-machine interactions, mandatory error cases, and expected processing-time bounds.

PING provides low-cost reachability and liveness detection. PING messages SHOULD be sent unencrypted by default to remain lightweight. Implementations MAY support OSCORE-protected PING for authenticated deployments, but unencrypted PING MUST be accepted by all receivers. Sender: MAY emit PING at any time; MUST increment Sequence ID; SHOULD use unique Correlation ID; MUST rate-limit (≤1 per 10 seconds per peer). Receiver: SHOULD reply with TELL; MUST NOT require OSCORE for unencrypted PING; MUST accept both unencrypted and OSCORE-protected PING; SHOULD rate-limit PING processing. Unencrypted PING may leak topology/presence information; implementations SHOULD use rate limiting and randomization. For authenticated liveness, use ASK/TELL with OSCORE or OSCORE-protected PING.

TELL conveys information, updates, or asynchronous notifications, and responds to ASK messages. TELL messages MUST be OSCORE-protected unless deployment explicitly allows unauthenticated mode. Sender: MUST include payload or meaningful TLV set; MUST increment Sequence ID; when responding to ASK, MUST use same Correlation ID. Receiver: MUST validate OSCORE; MUST associate via Correlation ID; MUST incorporate content per application policy. Errors: TELL without OSCORE MUST be rejected (unless non-secure mode); malformed TLVs MUST cause discard.

ASK initiates a request for information or action and typically elicits a TELL response. ASK messages MUST be OSCORE-protected. Sender: MUST allocate new conversation entry indexed by Correlation ID; MUST increment Sequence ID; MUST start request timer (default timeout of 30 seconds is RECOMMENDED for constrained devices, with exponential backoff for retransmissions when QoS=1); MUST enforce conversation limits. Receiver: MUST validate OSCORE; MUST associate ASK with Correlation ID; MUST generate TELL response with result or error TLV. Errors: malformed TLVs → TELL(error); security validation failure → silent discard; correlation-table limits exceeded → resource exhaustion error.

OBSERVE establishes a subscription for future notifications, scoped to a single peer. OBSERVE messages MUST be OSCORE-protected. Sender: MUST allocate/update subscription state indexed by Correlation ID; MUST validate subscription limits; MUST increment Sequence ID; MAY include subscription parameter TLVs (topic, conditions); MUST send periodic TELL notifications while active. Receiver: MUST validate OSCORE; MUST establish/refresh subscription state; MUST enforce expiration and resource ceilings; when conditions met, MUST send event notifications as TELL. Cancellation: TELL or OBSERVE with Cancel-Subscription TLV (Type=0xFF) → receiver MUST delete state, stop notifications. Errors: subscription limits exceeded → TELL(error); OSCORE validation failure → drop.

Summary: PING—liveness probe, SHOULD NOT require OSCORE (unencrypted by default), implementations MAY support OSCORE-protected PING; TELL—update/response/notification, MUST use OSCORE except in explicitly insecure deployments; ASK—request, MUST use OSCORE, MUST generate TELL response; OBSERVE—subscription, MUST use OSCORE, MUST create or update subscription state. Agents MUST NOT overload verbs with incompatible semantics.

This section defines the mandatory-to-implement (MTI) transport binding for µACP: the combination of the Constrained Application Protocol (CoAP) as the transport substrate and OSCORE as the end-to-end object security mechanism. All compliant µACP implementations MUST support this binding. Deployments MAY support additional bindings (e.g., DTLS/UDP as specified in or QUIC) but such bindings are outside the scope of this specification and MUST NOT weaken or replace the OSCORE/CoAP MTI profile.

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). µACP messages MUST use: Method=POST, URI-Path="muacp" (fixed), Content-Format=application/muacp+binary, Payload=Full µACP message. Each µACP message corresponds to exactly one CoAP POST.

Figure 4: CoAP Envelope Carrying a µACP Message

All µACP messages except unencrypted PING MUST be protected using OSCORE , which uses COSE for cryptographic operations. OSCORE MUST protect: the entire µACP header (except outer CoAP routing metadata), all TLVs except raw TLVs permitted for PING, and the entire µACP payload. OSCORE replay protection MUST be enabled with replay windows configured to match expected message rate and resource constraints. OSCORE MUST use a unique security context per agent-pair.

Security contexts for OSCORE MAY be derived by: EDHOC (RECOMMENDED), Pre-Shared Keys (PSK), or out-of-band provisioning. When EDHOC is used, the resulting OSCORE context MUST be bound to the EDHOC handshake transcript to prevent identity misbinding attacks. If a device exhausts its available context storage, it MUST reject new context establishment requests with ERR_RESOURCE_EXHAUSTED. If all OSCORE contexts are active and a new context establishment request arrives, implementations MUST reject it with ERR_RESOURCE_EXHAUSTED. Implementations SHOULD implement context eviction policies (e.g., least-recently-used) for inactive contexts but MUST NOT terminate active conversations. For Class 1 devices, implementations SHOULD limit concurrent OSCORE contexts (e.g., 8-16 contexts).

µACP builds upon CoAP reliability semantics to achieve its QoS model. Implementations MUST map µACP QoS codes to CoAP message types as follows: µACP QoS Meaning CoAP Message Type 0 fire-and-forget NON (Non-confirmable) 1 at-least-once delivery CON (Confirmable) 2 at-most-once delivery NON (Non-confirmable, no retransmission) QoS Semantics: QoS=0 (fire-and-forget) provides best-effort delivery. QoS=1 (at-least-once) ensures delivery through CoAP retransmissions. QoS=2 (at-most-once) provides a single delivery attempt without retransmission, suitable for idempotent operations. Both QoS=0 and QoS=2 use CoAP NON messages. Implementations MUST NOT retransmit QoS=2 messages at the µACP layer. CoAP-level acknowledgments MUST NOT be interpreted as µACP-level responses. Application responses are always encoded as TELL messages.

ASK messages MUST be sent as CoAP POST requests; TELL responses as CoAP responses. OSCORE MUST protect both directions. The Correlation ID uniquely links ASK with TELL response. CoAP Message IDs MUST NOT be used for application correlation. Receivers MUST respond with TELL even when requests fail, using an Error TLV.

Figure 5: ASK/TELL Over OSCORE-CoAP <---------- 2.04 Changed (TELL, OSCORE) ]]>

OBSERVE establishes a long-lived subscription. µACP defines its own subscription model, independent of CoAP's Observe extension . OBSERVE MUST be mapped as: CoAP POST containing µACP OBSERVE message; notifications delivered as CoAP POSTs containing TELL messages. Implementations MUST NOT use CoAP Observe for µACP subscriptions.

All µACP-over-CoAP deployments MUST implement congestion control to prevent network collapse and unfair bandwidth usage. Implementations MUST follow CoAP congestion control mechanisms as specified in Section 4.7. Agents MUST adhere to: exponential backoff on CoAP CON retransmissions (initial timeout ≥2s, max 247s per ); PING rate limiting (≤1 per 10 seconds per peer); OBSERVE throttling when bandwidth pressure is detected; deterministic resource usage; message rate limits per conversation. When Blockwise Transfer is used, agents MUST ensure block sizes do not exceed memory limits.

Transport errors (CoAP timeouts, OSCORE decryption failures, missing acknowledgments) MUST be translated into µACP-level behavior. OSCORE decryption failures → drop message. Unacknowledged CoAP CON → apply µACP QoS semantics for retransmission. Repeated timeouts → conversation enters failure state. Malformed CoAP envelopes → discard.

All compliant µACP implementations MUST: support CoAP POST to fixed path "muacp"; support Content-Format application/muacp+binary; protect all messages except unencrypted PING with OSCORE; enforce OSCORE replay protection; derive OSCORE contexts using EDHOC or equivalent; map QoS codes to CoAP message types; generate TELL responses for all ASK messages; deliver OBSERVE notifications as TELL messages. This binding ensures interoperability and establishes a minimum security baseline.

This section defines normative error-handling rules, version-negotiation mechanism, downgrade protection requirements, and the extensibility framework provided by the TLV architecture.

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.

Figure 6: Error-Code TLV

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.

The following error codes are defined for µACP: Code Name Description 0x00SUCCESS No error; operation completed successfully. This code is OPTIONAL. If omitted, successful completion is indicated by the absence of an Error-Code TLV. Receivers MUST treat the absence of an Error-Code TLV as equivalent to SUCCESS (0x00). 0x01ERR_MALFORMED Malformed header, TLV, or payload. 0x02ERR_UNSUPPORTED_VERB Verb not recognized or not supported by receiver. 0x03ERR_UNSUPPORTED_TLV Critical TLV not understood. 0x04ERR_FORBIDDEN Operation not permitted due to policy or authorization. 0x05ERR_RESOURCE_EXHAUSTED Memory, CPU, or subscription/conversation limits exceeded. 0x06ERR_VERSION_MISMATCH Message uses unsupported protocol version. 0x07ERR_TIMEOUT Sender or receiver timed out while waiting for a response. 0x08ERR_INTERNAL Internal failure not covered by other error categories. Implementations MAY define additional vendor-specific error codes in the vendor range but MUST NOT redefine standardized codes.

Receivers MUST apply strict validation: if TLV Length exceeds remaining bytes, discard; if TLVs appear out of Type order, discard; if required TLV (future versions) is absent, reject; if header fields contain invalid combinations (e.g., reserved bits set), reject; if OSCORE decryption fails, discard without error signaling. Where feasible, receivers SHOULD send TELL(error) unless doing so would amplify a denial-of-service attack.

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.

If a Correlation ID collision is detected (a new message arrives with a Correlation ID matching an active conversation from the same sender, as identified by the OSCORE security context), the receiver MUST apply the following deterministic strategy in order:

1. If the conversation table is full (all entries occupied), reject the new message with ERR_RESOURCE_EXHAUSTED and maintain the existing conversation.
2. If the new message's Sequence ID (from the same sender) is greater than the existing conversation's last observed Sequence ID from that sender, terminate the existing conversation (free its resources), accept the new message, and create a new conversation entry. This handles legitimate Correlation ID reuse after conversation completion or timeout. Note: Sequence IDs are per-sender and monotonically increase within each sender's message stream. To handle Sequence ID wrap-around (modulo 2^16), implementations MUST use sequence number comparison as defined in Section 3.1: given two Sequence IDs S1 and S2, S1 is considered greater than S2 if (S1 > S2 and S1 - S2 < 2^15) or (S1 < S2 and S2 - S1 > 2^15). This ensures correct ordering even when Sequence IDs wrap from 0xFFFF to 0x0000.
3. If the new message's Sequence ID is less than or equal to the existing conversation's last observed Sequence ID from the same sender, reject the new message as a potential replay or out-of-order delivery. The receiver MUST NOT modify the existing conversation state and SHOULD silently discard the new message (or MAY send ERR_MALFORMED if the message appears valid but out-of-order).

This deterministic strategy ensures interoperability while preventing resource exhaustion and replay attacks. Correlation ID collisions are rare when Correlation IDs are randomly generated with sufficient entropy. Collisions from different senders (different OSCORE contexts) are handled separately, as each OSCORE context maintains its own conversation state. The Sequence ID comparison is secure because Sequence IDs are authenticated and integrity-protected by OSCORE. Example: If an active conversation exists with Correlation ID=0x1234 and last observed Sequence ID=0x0010 from sender A (identified by OSCORE context A), and a new message arrives with Correlation ID=0x1234 and Sequence ID=0x0015 from the same sender A, the receiver terminates the old conversation and accepts the new one. If the new message has Sequence ID=0x0005 from sender A, it is rejected as a potential replay. If a message arrives with Correlation ID=0x1234 from sender B (different OSCORE context), it is treated as a separate conversation, as conversations are scoped per OSCORE security context.

µACP includes a Version-TLV (Type=0x01) that MAY be included in any message to indicate supported protocol versions. If no Version-TLV is present, receivers MUST assume version 0x00 (this specification). Version negotiation follows these rules:

• If a message includes a Version-TLV that indicates only unsupported versions (i.e., all versions listed in the Version-TLV are higher than the receiver's maximum supported version), the receiver MUST return ERR_VERSION_MISMATCH in a TELL error response.
• If the Version-TLV contains at least one supported version, the receiver MUST use the highest mutually supported version for subsequent messages in the conversation.
• When both parties send Version-TLVs (e.g., in ASK and TELL), each party MUST independently select the highest mutually supported version from the union of both Version-TLV lists. If no common version exists, the receiver MUST return ERR_VERSION_MISMATCH.
• The selected version applies to all messages in the conversation identified by the Correlation ID. Once a version is selected, it MUST NOT be changed for that conversation.
• Version negotiation MUST occur under OSCORE protection. PING messages (which are typically unencrypted) SHOULD NOT carry Version-TLV to maintain lightweight operation. If version negotiation is required before OSCORE context establishment, implementations SHOULD use ASK/TELL with OSCORE or establish the OSCORE context first, then negotiate versions in subsequent messages.

Figure 7: Version TLV

Encoding: The Value field of the Version TLV is a sequence of N unsigned 8-bit integers (where N is the Length field value). Each integer represents a protocol version number. For example, a Version TLV indicating support for versions 0x00 and 0x01 would have Length=2 and Value=[0x00, 0x01]. Implementations MUST encode version numbers as single octets (0-255). Receivers MUST parse the Value field as a sequence of Length octets, each interpreted as an unsigned 8-bit version number.

Implementations MUST ensure attackers cannot force a peer to use a lower protocol version when a higher mutually supported version is available. The highest mutually supported version MUST be chosen. Version negotiation MUST occur inside OSCORE-protected messages (except PING). Agents MUST NOT downgrade versions unless a failure condition explicitly requires fallback.

µACP evolves through TLV-based extensibility. Constraints: receivers MUST ignore unknown non-critical TLVs; implementations MUST NOT reuse TLV Types for different semantics; future versions MAY introduce critical TLVs (unsupported critical TLVs trigger ERR_UNSUPPORTED_TLV); all TLVs MUST be sorted by increasing Type value; Types 128–255 are vendor-specific and require no global registration. Complex extensions SHOULD define new structured TLVs rather than overloading primitive types.

Malformed messages MUST be rejected and SHOULD trigger TELL(error) unless unsafe. Errors MUST use standardized codes. 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.

This section requests the creation of new registries and assignments required for µACP to function as an interoperable Internet protocol. All registries use the policies defined in . Unless otherwise stated, values are allocated using the "IETF Review" policy.

IANA is requested to create a new registry entitled "µACP TLV Types" (8-bit values 0–255). Each entry MUST contain: Value, Name, Description, Value format, Reference. The range is divided as follows:

• 0–31: Standards Action (as defined in Section 4.1)
• 32–127: IETF Review
• 128–255: Vendor-specific (First Come First Served)

Initial values: ValueNameDescriptionFormatReference 0x00RAW_OCTETSUnstructured data; MUST NOT appear in encrypted messages except PING.OpaqueThis document 0x01VERSIONAdvertised supported protocol versions.Array of integersThis document 0x02CONTENT_TYPESpecifies payload encoding.IntegerThis document 0x03CBOR_PAYLOADPayload encoded as CBOR.CBOR data itemThis document 0x10RESERVEDReserved for future fragmentation specification. Implementations MUST NOT use Type=0x10 until fragmentation is fully specified in a future extension document.N/AThis document 0x20TOPICSubscription topic for OBSERVE.UTF-8 stringThis document 0x21CONDITIONTrigger condition for OBSERVE.UTF-8 or CBORThis document 0x22ERROR_CODEError code returned in TELL(error).IntegerThis document 0xFFCANCEL_SUBSCRIPTIONExplicit termination of OBSERVE subscription.EmptyThis document Future extensions MUST NOT assign new semantics to existing TLV values.

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). ValueNameDescriptionReference 0FIRE_AND_FORGETNo reliability; mapped to CoAP NON.This document 1AT_LEAST_ONCERetransmissions required; mapped to CoAP CON.This document 2AT_MOST_ONCENo retransmission; mapped to CoAP NON.This document 3RESERVEDReserved for future use.This document

IANA is requested to create a registry entitled "µACP Verb Codes". Verb values occupy 2 bits but are listed numerically (0–3). ValueNameDescriptionReference 0PINGLiveness probe.This document 1TELLState update, notification, or response.This document 2ASKRequest for information or action.This document 3OBSERVESubscription to events or state changes.This document

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.

IANA is requested to register the following CoAP Content-Format: NameMedia TypeEncodingIDReference application/muacp+binary application/muacp+binary Binary TBD (to be assigned by IANA) This document 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 .

IANA is requested to register the following media type in the "application" registry per : 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

IANA is requested to register the following CoAP Well-Known URI per using the "IETF Review" policy: URIDescriptionReference /.well-known/muacp Discovery resource indicating µACP support. This document A CoAP GET to /.well-known/muacp SHOULD return a CBOR structure (Content-Format: application/cbor) describing supported TLVs, maximum sizes, and supported versions as specified in Section 10.5. A successful response (2.05 Content) MUST contain a CBOR map. A 4.04 Not Found response indicates that µACP is not supported by the device. Implementations MUST handle both success and error responses gracefully.

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 and ensure long-term extensibility under IETF governance.

This section defines normative finite-state machines (FSMs) governing µACP conversations. Implementations MUST implement these FSMs for deterministic, interoperable behavior. Agents operate according to: receive message, validate OSCORE (if required), validate header/TLVs/payload, identify conversation via Correlation ID, execute verb-specific FSM transition, emit resulting messages. Agents MUST support at least 64 concurrent conversations and MUST reject new conversations if resource ceilings are exceeded (ERR_RESOURCE_EXHAUSTED).

ASK initiates a conversation; TELL completes it. States: IDLE → (send ASK) → WAIT_RESP → (recv TELL or timeout) → COMPLETED → cleanup. If timer expires and QoS=1, retransmit ASK. If QoS=0/2, transition to COMPLETED with ERR_TIMEOUT. Receiver MUST emit TELL(error) for errors.

Figure 8: ASK/TELL State Machine returns to IDLE ]]>

PING serves as a minimal liveness check. PING is stateless and does NOT create persistent conversation table entries. States: IDLE → (send PING) → WAIT_PONG → (recv TELL or timeout) → COMPLETED. PING SHOULD NOT require OSCORE (unencrypted by default), implementations MAY support OSCORE-protected PING, MUST NOT modify application state, and MUST NOT cause retransmissions on timeout.

Figure 9: PING/TELL Liveness FSM

OBSERVE establishes a long-lived subscription. States: NO_SUB → (recv OBSERVE) → SUBSCRIBED → (event trigger) → NOTIFY (TELL) → (recv CANCEL_SUB) → TERMINATED → cleanup. Subscriptions MUST expire after configured lifetime and MUST enforce resource ceilings (max subscriptions per peer).

Figure 10: OBSERVE Subscription FSM

Errors MUST transition FSMs to predictable termination states: ERR_MALFORMED → discard, no state; ERR_UNSUPPORTED_TLV → terminate conversation, send error TELL; ERR_TIMEOUT → COMPLETED with error, free resources; ERR_RESOURCE_EXHAUSTED → reject, no new state; OSCORE failure → silent discard, no state update.

All FSM transitions MUST complete in bounded time and memory. Required limits: conversation table (minimum 64 entries), subscription table (minimum 16 entries), deterministic message buffer sizes (header+1024-byte TLVs+payload), timers without per-message dynamic allocation. Platforms MAY use preallocated memory pools or static tables.

This section defines the security properties, assumptions, and mandatory mitigations for µACP. The protocol relies on OSCORE and the underlying transport for security. All implementations MUST follow the requirements in this section to avoid exposure to denial-of-service, spoofing, downgrade, replay, or privacy attacks.

The µACP threat model assumes attackers may: passively eavesdrop; modify, inject, reorder, or replay messages; exhaust memory/CPU/storage/energy/subscription tables; desynchronize state; conduct traffic analysis; attempt version downgrades; exploit weak random number generation or incorrect OSCORE configuration. The protocol provides security only when implemented with OSCORE. Attackers are assumed to have full control of the transport layer but not of OSCORE-protected channels.

All µACP messages except unencrypted PING MUST be authenticated and integrity-protected using OSCORE. OSCORE provides peer authentication (when derived from EDHOC or provisioned credentials), integrity protection over header/TLVs/payload, replay protection, and request/response binding. Implementations MUST use a unique OSCORE security context per communicating peer. TELL, ASK, and OBSERVE messages MUST be encrypted via OSCORE. Authorization MUST be enforced before performing operations triggered by ASK or OBSERVE.

µACP relies on OSCORE replay protection. Implementations MUST enable and correctly maintain OSCORE replay windows. Receivers SHOULD maintain a per-peer sliding window of recent Sequence IDs. Subscription-triggered notifications MUST validate freshness. Agents MUST reject delayed or reordered messages if OSCORE replay windows indicate a stale nonce.

Implementations MUST enforce: maximum active conversations (minimum 64), maximum OBSERVE subscriptions (minimum 16), rate limits on PING and ASK, TLV region size limits (max 1024 bytes), payload size limits (max 65535 bytes), and static/preallocated memory pools. When limits are exceeded, agents MUST return ERR_RESOURCE_EXHAUSTED or silently drop messages. CoAP-level DoS mitigation (exponential backoff, NON vs CON) MUST also be applied.

OBSERVE and CANCEL_SUB MUST be OSCORE-protected. Subscriptions MUST be bound to an authenticated OSCORE context. Correlation IDs MUST be unpredictable. Subscription deletion MUST require a valid CANCEL_SUB from the same authenticated peer or timeout/resource exhaustion. Agents MUST reject subscription attempts exceeding resource ceilings.

The highest mutually supported version MUST be used. Version negotiation MUST occur under OSCORE (except PING). Agents MUST reject messages advertising only unsupported versions and MUST NOT fall back silently to lower versions.

Implementations MUST provide: secure key provisioning (EDHOC, PSK, or manufacturing-time injection), rotation of OSCORE master secrets, secure deletion of expired keys, protection against key reuse across peers, and protection against side-channel extraction. Compromise of OSCORE keys compromises all µACP security properties. Key Rotation: OSCORE master secrets SHOULD be rotated periodically (e.g., time-based: 30-90 days, usage-based: after 2^32 messages, or event-based: upon compromise suspicion). Rotation procedures MUST preserve active conversations where possible.

Constrained devices may be vulnerable to side-channel attacks (timing, power, electromagnetic). Implementations SHOULD: use constant-time cryptographic operations, minimize observable timing differences, protect against power analysis (HSMs or software countermeasures), avoid leaking information through error timing or resource allocation, use secure random number generators for Correlation IDs and Sequence IDs. While complete side-channel resistance may be impractical on severely constrained devices, implementations SHOULD document their threat model and mitigations.

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

This section defines the minimum feature set required for interoperability between µACP implementations, along with deployment profiles tailored to different classes of devices and networks.

All µACP implementations MUST support: the 64-bit header format; all four verbs (PING, TELL, ASK, OBSERVE); TLV processing with ordering and size limits; 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 and state-machine behavior as defined in this specification.

CNP targets microcontroller-class devices (ARM Cortex-M, ESP32). Implementations MUST use static/preallocated buffers, enforce strict resource bounds, minimize logging, and restrict payload sizes. Implementations SHOULD prefer PSK/EDHOC-based OSCORE contexts and disable vendor-specific TLVs.

INP targets edge gateways and cloud-side collectors. Implementations MUST support full subscription features, extended TLV sets, high-throughput replay windows, EDHOC key exchange, and rate-shaping for constrained peers. INP nodes MAY provide protocol translation and hardware-accelerated crypto.

INP nodes MUST respect CNP resource ceilings, MUST NOT exceed CNP size limits, and SHOULD apply traffic shaping. CNP nodes MUST ignore unsupported TLVs. Fallback to MIP MUST always be possible. All profile interactions MUST preserve security properties.

Feature discovery uses GET /.well-known/muacp, returning a CBOR map describing the device's µACP capabilities. The response MUST use Content-Format application/cbor and MUST conform to the following CDDL schema:

Feature Negotiation Response Format (CDDL) uint, ; Maximum TLV region size in bytes ? "max-payload-size" => uint, ; Maximum payload size in bytes ? "supported-tlv-types" => [*uint], ; List of supported TLV Type values ? "supported-versions" => [*uint], ; List of supported protocol versions ? "congestion-modes" => [*text], ; Supported congestion control modes ? "conversation-limit" => uint, ; Maximum concurrent conversations ? "subscription-limit" => uint ; Maximum concurrent subscriptions } ]]>

All fields are optional. If a field is omitted, implementations MUST assume the minimum required value for that capability. Nodes SHOULD cache results until expiration or reboot. If the resource is unavailable (4.04 Not Found), implementations MUST assume default minimum capabilities: max-tlv-size=1024 (minimum required), max-payload-size=65535 (minimum required), supported-versions=[0x00]. These defaults represent minimum required capabilities; implementations MAY advertise higher limits in their feature negotiation responses.

This section provides essential normative examples of µACP messages. Additional test vectors are available in the reference implementation repository . Byte order is network byte order (big-endian).

A minimal PING contains only the µACP header. The complete 64-bit header is:

Example 1: PING Message (Hex)

No TLVs, no payload. This message may be sent unencrypted over CoAP NON.

ASK messages are sent as CoAP POST requests with OSCORE protection. The unencrypted µACP ASK structure: Header (Sequence ID=0x0002, Correlation ID=0x0003, QoS=1, Verb=2), optional TLVs, optional payload. After OSCORE encryption, the complete µACP message becomes the CoAP payload. TELL responses use the same Correlation ID and are also OSCORE-protected. Complete Example: The following shows a complete ASK/TELL exchange:

Example 2: Complete ASK/TELL Exchange

Complete hexdumps of encrypted payloads with actual OSCORE ciphertext are provided in the reference implementation repository, as they depend on specific OSCORE security contexts, nonces, and key material.

This section defines the normative conformance tests required to validate µACP implementations. A device or software stack MUST pass all tests in this section to be considered µACP-compliant. Detailed test vectors and a complete test suite are available in the reference implementation repository . Implementations MUST pass tests in the following categories:

• Header and TLV Encoding: Correct parsing of all header fields, TLV ordering, size limits (1024 bytes TLV region, 65535 bytes payload), and handling of unknown TLVs.
• Parser Robustness: Safe handling of malformed headers, oversized payloads, invalid TLV lengths, and resource exhaustion conditions.
• State-Machine Behavior: ASK/TELL conversation lifecycle, OBSERVE subscription management, PING statelessness, and deterministic error transitions.
• OSCORE Security: Authentication and decryption of protected messages, replay window enforcement, context isolation, and downgrade protection.
• Resource Constraints: Conversation table limits (minimum 64 entries), subscription limits (minimum 16), and bounded processing time.
• Interoperability: Successful message exchange between independent implementations under the Minimum Interoperability Profile.

All test requirements are derived from the normative sections of this specification. Passing these tests validates full compliance with µACP.

The design of µACP benefited from feedback across multiple research and engineering communities working on IoT systems, multi-agent communication, and distributed protocol design. The authors acknowledge the valuable insights provided by early reviewers, prototype implementers, and colleagues who explored µACP in constrained-device testbeds. Special thanks are extended to members of the open-source contributors who reviewed early drafts of the µACP calculus and provided implementation reports via the project repository. Their feedback led to refinements in the state machines, TLV model, and transport bindings. The authors also thank participants from constrained-network and OSCORE working groups whose discussions influenced the treatment of fragmentation, replay protection, and authentication in this specification. This specification incorporates lessons from deployments in microcontroller-based sensing systems, autonomous control nodes, and large-scale telemetry environments. The authors acknowledge these deployments for motivating the resource model and deterministic behavior guarantees underlying µACP. This work is an independent contribution and does not represent the views of any organization or government entity.