The Micro Agent Communication Protocol (uACP)
draft-mallick-muacp-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Arnab Mallick , Indraveni Chebolu | ||
| Last updated | 2026-05-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mallick-muacp-03
Network Working Group A. Mallick
Internet-Draft I. Chebolu
Intended status: ExperimentalCentre for Development of Advanced Computing (CDAC)
Expires: 29 November 2026 28 May 2026
The Micro Agent Communication Protocol (µACP)
draft-mallick-muacp-03
Abstract
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 [RFC7228]). Existing agent
communication protocols assume unbounded computational and energy
resources, µACP provides mechanisms for bounded resource consumption
with deterministic memory bounds (8-byte header, explicitly delimited
TLV region, and profile-dependent payload limits) 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.
Status of This Memo
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."
This Internet-Draft will expire on 29 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mallick & Chebolu Expires 29 November 2026 [Page 1]
Internet-Draft µACP May 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Problem Space . . . . . . . . . . . . . . 5
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 6
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Relationship to Other Protocols . . . . . . . . . . . . . 8
1.6. Document Structure . . . . . . . . . . . . . . . . . . . 9
1.7. Implementation Experience . . . . . . . . . . . . . . . . 9
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 10
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 11
3. Message Model and Encoding Rules . . . . . . . . . . . . . . 11
3.1. Message Structure . . . . . . . . . . . . . . . . . . . . 11
3.2. Header Format . . . . . . . . . . . . . . . . . . . . . . 11
3.3. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. TLV Processing Rules . . . . . . . . . . . . . . . . 14
3.4. Payload Encoding . . . . . . . . . . . . . . . . . . . . 15
3.5. Byte Ordering . . . . . . . . . . . . . . . . . . . . . . 15
3.6. Fragmentation (Optional Feature) . . . . . . . . . . . . 15
3.7. OSCORE Protection Boundaries . . . . . . . . . . . . . . 16
3.8. Canonical Encoding Rules . . . . . . . . . . . . . . . . 16
4. Protocol Semantics . . . . . . . . . . . . . . . . . . . . . 16
4.1. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. TELL . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. ASK . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. OBSERVE . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Summary of Normative Requirements . . . . . . . . . . . . 19
5. Mandatory Transport Binding: OSCORE/CoAP . . . . . . . . . . 19
5.1. Mapping µACP Messages to CoAP . . . . . . . . . . . . . . 19
5.2. OSCORE Protection Requirements . . . . . . . . . . . . . 20
5.3. Establishing OSCORE Security Contexts . . . . . . . . . . 20
5.4. CoAP Message Types and Reliability . . . . . . . . . . . 20
5.5. Mapping ASK/TELL to CoAP Request/Response . . . . . . . . 21
5.6. Mapping OBSERVE Subscriptions . . . . . . . . . . . . . . 22
5.7. Congestion Control Requirements . . . . . . . . . . . . . 23
5.8. Transport-Layer Error Handling . . . . . . . . . . . . . 23
5.9. Summary of MTI Requirements . . . . . . . . . . . . . . . 23
6. Error Handling, Version Negotiation, and Extensibility . . . 23
6.1. Error Code TLVs . . . . . . . . . . . . . . . . . . . . . 23
Mallick & Chebolu Expires 29 November 2026 [Page 2]
Internet-Draft µACP May 2026
6.2. Standardized Error Conditions . . . . . . . . . . . . . . 24
6.3. Handling Malformed Messages . . . . . . . . . . . . . . . 26
6.4. Conversation-Lifetime Error Handling . . . . . . . . . . 26
6.5. Version Negotiation . . . . . . . . . . . . . . . . . . . 27
6.6. Downgrade and Version-Rollback Protection . . . . . . . . 29
6.7. Extensibility Framework . . . . . . . . . . . . . . . . . 29
6.8. Summary of Normative Requirements . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7.1. µACP TLV Types Registry . . . . . . . . . . . . . . . . . 30
7.2. µACP QoS Codes Registry . . . . . . . . . . . . . . . . . 32
7.3. µACP Verb Codes Registry . . . . . . . . . . . . . . . . 32
7.4. µACP Error Codes Registry . . . . . . . . . . . . . . . . 33
7.5. CoAP Content-Format Registration . . . . . . . . . . . . 34
7.6. Media Type Registration . . . . . . . . . . . . . . . . . 35
7.7. Well-Known CoAP Resource . . . . . . . . . . . . . . . . 35
7.8. Summary of IANA Actions . . . . . . . . . . . . . . . . . 36
8. State Machines and Processing Logic . . . . . . . . . . . . . 36
8.1. ASK/TELL Conversation State Machine . . . . . . . . . . . 36
8.2. PING State Machine . . . . . . . . . . . . . . . . . . . 37
8.3. OBSERVE Subscription State Machine . . . . . . . . . . . 38
8.4. Error-State Transitions . . . . . . . . . . . . . . . . . 39
8.5. Processing Time and Resource Bounds . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 40
9.2. Authentication, Integrity, and Confidentiality . . . . . 40
9.3. Replay Prevention and Freshness . . . . . . . . . . . . . 41
9.4. Denial-of-Service and Resource Exhaustion . . . . . . . . 41
9.5. Subscription Security . . . . . . . . . . . . . . . . . . 41
9.6. Downgrade Protection . . . . . . . . . . . . . . . . . . 41
9.7. Key Management . . . . . . . . . . . . . . . . . . . . . 41
9.8. Side-Channel Attacks . . . . . . . . . . . . . . . . . . 42
9.9. Safe Failure Modes . . . . . . . . . . . . . . . . . . . 42
10. Interoperability and Deployment Profiles . . . . . . . . . . 42
10.1. Minimum Interoperability Profile (MIP) . . . . . . . . . 42
10.2. Constrained Node Profile (CNP) . . . . . . . . . . . . . 43
10.3. Infrastructure Node Profile (INP) . . . . . . . . . . . 43
10.4. Cross-Profile Interoperability . . . . . . . . . . . . . 44
10.5. Feature Negotiation . . . . . . . . . . . . . . . . . . 44
11. Wire Examples . . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. Minimal PING (unencrypted) . . . . . . . . . . . . . . . 45
11.2. ASK/TELL over OSCORE . . . . . . . . . . . . . . . . . . 45
12. Conformance Checklist . . . . . . . . . . . . . . . . . . . . 47
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . 49
Open Questions for Working Group Discussion . . . . . . . . . . . 49
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
Mallick & Chebolu Expires 29 November 2026 [Page 3]
Internet-Draft µACP May 2026
1. Introduction
The Internet of Things (IoT) and Edge computing domains increasingly
demand autonomous coordination among resource-constrained devices.
Multi-agent systems, in which software entities collaborate to
achieve distributed goals, are a natural fit for these environments.
However, existing agent communication protocols, such as FIPA-ACL
[FIPA-ACL], assume unlimited computational resources and are
unsuitable for devices with kilobytes of RAM operating on battery
power.
At the same time, constrained IoT protocols like CoAP [RFC7252]
provide efficient request/response primitives but lack the structured
semantics necessary for multi-agent coordination patterns such as
state dissemination, event-driven subscriptions, and conversation
management. This gap leaves developers without a standard,
interoperable way to implement lightweight agent communication on
microcontroller-class platforms (Class 1 and Class 2 devices per
[RFC7228]).
The Micro Agent Communication Protocol (µACP) addresses this gap by
defining a resource-efficient, semantically expressive protocol
tailored for autonomous agents on constrained devices. µACP provides:
* A compact wire format with deterministic resource bounds: 64-bit
fixed header, explicitly delimited TLV region, and profile-
dependent payload limits.
* Four orthogonal communication primitives (PING, TELL, ASK,
OBSERVE) sufficient for liveness detection, request/response,
state updates, and publish/subscribe patterns.
* Mandatory OSCORE [RFC8613] security binding ensuring end-to-end
confidentiality, integrity, and replay protection without
requiring heavyweight TLS stacks.
* Finite-state machine semantics enabling deterministic, verifiable
implementations with bounded processing time and memory
consumption.
µACP is designed to operate over CoAP [RFC7252] as the transport
substrate, leveraging CoAP's congestion control and reliability
mechanisms while adding agent-oriented communication semantics.
Unlike general-purpose messaging protocols, µACP targets specific
coordination patterns found in distributed autonomous systems, making
it complementary to, rather than a replacement for, existing IoT
protocols.
Mallick & Chebolu Expires 29 November 2026 [Page 4]
Internet-Draft µACP May 2026
An accompanying formal model [MUACP] explores resource bounds and
safety properties of a simplified µACP core. This model is
informative and non-normative, providing an informative exploration
of design trade-offs related to determinism. A reference
implementation demonstrates µACP operating on ARM Cortex-M
microcontrollers with as little as 10 KB of RAM, validating its
suitability for severely constrained environments.
The authors welcome feedback on technical approach, scope, and design
trade-offs via the µACP reference implementation repository
[MUACP-IMPL] and the IETF mailing lists.
1.1. Motivation and Problem Space
Modern IoT deployments face three converging challenges:
1. *Resource Scarcity:* Billions of deployed devices (Class 1: ~10
KB RAM/100 KB flash, Class 2: ~50 KB RAM/250 KB flash per
[RFC7228]) cannot support traditional agent communication
frameworks or heavy middleware.
2. *Semantic Gap:* Existing constrained protocols (CoAP, MQTT-SN)
provide transport-level primitives but lack structured
conversation management, subscription scoping, and error
semantics required for agent coordination.
3. *Security Requirements:* Autonomous agents operating in
adversarial environments (smart cities, industrial control,
healthcare) require authenticated, confidentiality-protected
communication without the overhead of TLS.
Representative use cases include:
* *Smart Agriculture:* Soil moisture sensors (agents) autonomously
coordinate irrigation decisions by subscribing to weather events
and sharing state with actuator agents.
* *Industrial IoT:* Machine monitoring agents request diagnostic
information from equipment agents and subscribe to fault
notifications, all under strict latency and energy budgets.
* *Healthcare Monitoring:* Wearable device agents exchange
physiological data with edge gateway agents, requiring
authenticated communication and conversation-scoped correlation.
* *Autonomous Robotics:* Swarm robots coordinate via lightweight
request/response and event notification without centralized
infrastructure.
Mallick & Chebolu Expires 29 November 2026 [Page 5]
Internet-Draft µACP May 2026
These scenarios share common requirements: deterministic resource
usage, secure multi-party interaction, structured conversation
management, and operation on devices where every byte and CPU cycle
matters. µACP provides a standardized, interoperable foundation for
these patterns.
1.2. Design Principles
µACP is guided by the following principles:
* *Deterministic Bounds:* All message processing completes in
bounded time and memory. Static allocation and preallocated
tables eliminate dynamic memory risks.
* *Minimal Overhead:* The 64-bit fixed header, binary TLV encoding,
and optional payload design minimize wire overhead and parsing
complexity.
* *Orthogonal Primitives:* Four verbs (PING, TELL, ASK, OBSERVE)
compose to support request/response, publish/subscribe, and
liveness patterns without semantic overloading.
* *Security by Default:* OSCORE protection is mandatory for all
messages except unencrypted PING, ensuring that security is not an
afterthought.
* *Transport Compatibility:* µACP builds upon CoAP's proven
constrained-network optimizations (congestion control, blockwise
transfer, DTLS/OSCORE) rather than reinventing them.
* *Extensibility Without Bloat:* TLV-based options allow future
extensions while maintaining backward compatibility and enabling
parsers to skip unknown options.
1.3. Goals
µACP aims to:
* Provide minimal, low-overhead communication primitives for
constrained autonomous agents with structured, agent-oriented
semantics.
* Ensure deterministic and bounded resource usage suitable for Class
1 and Class 2 devices.
* Support essential multi-agent coordination patterns (request/
response, publish/subscribe, liveness detection) using four
orthogonal primitives.
Mallick & Chebolu Expires 29 November 2026 [Page 6]
Internet-Draft µACP May 2026
* Define a secure, interoperable transport binding with mandatory
OSCORE protection.
* Enable extensibility via TLV options without breaking
compatibility or imposing mandatory overhead.
* Establish IANA registries and interoperability profiles to
facilitate independent implementations and ecosystem growth.
1.4. Scope
This specification defines:
* The normative wire format for µACP messages, including header
structure, TLV encoding rules, and payload processing.
* The semantics of four core communication verbs (PING, TELL, ASK,
OBSERVE) and their state-machine behavior.
* The mandatory CoAP/OSCORE transport binding, including QoS
mapping, congestion control, and security context requirements.
* Error handling, version negotiation, and extensibility mechanisms.
* IANA registries for TLV types, QoS codes, verbs, error codes,
content formats, and well-known URIs.
* Interoperability profiles (Minimum Interoperability Profile,
Constrained Node Profile, Infrastructure Node Profile) and a
conformance checklist.
This specification does NOT define:
* *Application-Level Semantics:* The meaning of specific payloads,
negotiation protocols, or high-level agent behaviors is
application-specific. µACP provides the communication substrate,
not the application logic.
* *Ontologies and Knowledge Representation:* Unlike FIPA-ACL, µACP
does not prescribe ontology languages, content languages, or
semantic frameworks. Developers may use CBOR schemas, JSON-LD, or
domain-specific formats as needed.
* *Agent Discovery and Registry:* While /.well-known/muacp provides
feature discovery, agent registry protocols and service discovery
are out of scope. Existing mechanisms like CoRE Resource
Directory [RFC9176] or DNS-SD may be used.
Mallick & Chebolu Expires 29 November 2026 [Page 7]
Internet-Draft µACP May 2026
* *Alternative Transport Bindings:* This specification defines CoAP/
OSCORE as the mandatory-to-implement transport. Other bindings
(e.g., DTLS/UDP, QUIC) may be specified in future companion
documents but are not normative here.
* *Non-Goals:* µACP is not a general-purpose messaging queue (like
MQTT), not a data-centric pub/sub system (like DDS), and not
suitable for Class 0 devices (<10 KB RAM) without significant
adaptation.
The scope intentionally focuses on the protocol layer, allowing
higher-level agent frameworks, ontologies, and application semantics
to evolve independently while maintaining wire-level
interoperability.
1.5. Relationship to Other Protocols
µACP builds upon and complements existing IETF protocols:
* *CoAP (RFC 7252):* µACP uses CoAP as its transport substrate,
leveraging CoAP's request/response model, congestion control (RFC
7252 Section 4.7), and optional blockwise transfer (RFC 7959).
µACP messages are carried as CoAP POST payloads.
* *OSCORE (RFC 8613):* µACP mandates OSCORE for end-to-end security,
providing authentication, integrity, confidentiality, and replay
protection without requiring TLS.
* *CoAP Observe (RFC 7641):* While CoAP Observe provides resource
observation, µACP OBSERVE adds agent-oriented subscription
semantics with explicit correlation IDs, cancellation TLVs, and
subscription state management independent of CoAP's Observe
mechanism.
* *MQTT and MQTT-SN:* These protocols provide publish/subscribe for
constrained networks but lack request/response semantics,
conversation correlation, and structured agent interaction
patterns that µACP targets.
* *DDS-XRCE:* DDS for eXtremely Constrained Environments focuses on
data-centric publish/subscribe. µACP focuses on agent-to-agent
communication with explicit conversations, request/response, and
lightweight state machines.
µACP is positioned as a specialized protocol for multi-agent
coordination on constrained devices, occupying a niche between
generic IoT messaging (CoAP, MQTT) and heavyweight agent platforms
(FIPA-ACL, JADE).
Mallick & Chebolu Expires 29 November 2026 [Page 8]
Internet-Draft µACP May 2026
1.6. Document Structure
The remainder of this document is organized as follows:
* Section 2 defines conventions, terminology, notation, and
abbreviations.
* Section 3 specifies the message model and encoding rules,
including header format, TLV encoding, payload processing, and
OSCORE protection boundaries.
* Section 4 defines the normative semantics of the four µACP verbs
(PING, TELL, ASK, OBSERVE) and their processing requirements.
* Section 5 specifies the mandatory CoAP/OSCORE transport binding,
including message mapping, QoS semantics, and congestion control.
* Section 6 covers error handling, version negotiation, downgrade
protection, and extensibility mechanisms.
* Section 7 defines IANA registries for TLV types, QoS codes, verbs,
error codes, content formats, and well-known URIs.
* Section 8 specifies finite-state machines governing conversation
lifecycles and resource bounds.
* Section 9 provides comprehensive security considerations,
including threat model, authentication, DoS mitigation, and key
management.
* Section 10 defines interoperability profiles (MIP, CNP, INP) and
feature negotiation mechanisms.
* Section 11 presents normative wire examples with hexadecimal
encodings and OSCORE-protected payloads.
* Section 12 provides a conformance checklist for µACP-compliant
implementations.
1.7. Implementation Experience
A reference implementation of µACP has been developed and is
available as open source. The implementation targets multiple
platforms including ESP32 (Xtensa), ARM Cortex-M4, and Linux,
demonstrating portability across Class 1, Class 2, and infrastructure
devices.
Measured resource usage:
Mallick & Chebolu Expires 29 November 2026 [Page 9]
Internet-Draft µACP May 2026
* RAM: ~8 KB (MIP profile, 8 conversations), ~15 KB (CNP profile, 8
conversations with static buffers)
* Flash: ~25 KB (protocol code + OSCORE stack)
* Message throughput: ~200 msg/sec (ESP32 @ 160MHz), ~1000 msg/sec
(Linux x86_64)
* Latency: <10ms for local delivery, <100ms over constrained 6LoWPAN
networks
Interoperability testing between ESP32 and Linux implementations has
validated the wire format, OSCORE protection, and state machine
behavior. The implementation confirms that µACP is practical for
severely constrained devices while maintaining deterministic resource
bounds.
2. Conventions and Terminology
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 [RFC2119] [RFC8174] when they appear in ALL CAPS. These words may
also appear in lowercase or mixed case as plain English words, absent
their normative meanings.
2.1. Terminology
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 [RFC8613], *CoAP*: Constrained Application Protocol
[RFC7252], *Constrained Device*: device with limited resources per
[RFC7228] (Class 1: ~10 KB RAM/100 KB flash, Class 2: ~50 KB RAM/250
KB flash).
2.2. Notation
Notation: hexadecimal values prefixed with "0x", binary values
prefixed with "0b", network byte order (big-endian) unless otherwise
specified, bit positions within an octet numbered with bit 7 as the
most significant bit (MSB) and bit 0 as the least significant bit
(LSB), message formats shown using ASCII art diagrams.
Mallick & Chebolu Expires 29 November 2026 [Page 10]
Internet-Draft µACP May 2026
2.3. Abbreviations
Abbreviations: CBOR (Concise Binary Object Representation [RFC8949]),
CID (Correlation ID), CoAP (Constrained Application Protocol), COSE
(CBOR Object Signing and Encryption [RFC9052]), 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. Message Model and Encoding Rules
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.
3.1. Message Structure
A µACP message consists of three components encoded in the following
order:
+--------+----------------+-------------------+
| Header | TLV region | Payload |
| 8 B | 0..1024 bytes | 0..65535 bytes |
+--------+----------------+-------------------+
Figure 1: Figure 1: µACP Message Layout
The header format is fixed-length and MUST always appear. TLVs and
payloads are optional. The 16-bit TLV Length field in the header
delimits the TLV region; the payload is the remaining octets after
the header and TLV region. Messages MUST NOT exceed transport-
imposed size limits; for CoAP/OSCORE, these limits are determined by
underlying MTU constraints and CoAP Blockwise Transfer [RFC7959] 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:
Mallick & Chebolu Expires 29 November 2026 [Page 11]
Internet-Draft µACP May 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence ID | Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS |Verb | Flags | VER |Rsv| TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(MSB first)
Byte 0-1: Sequence ID (16 bits, big-endian, MSB first)
Byte 2-3: Correlation ID (16 bits, big-endian, MSB first)
Byte 4: Bits 7-6: QoS (2 bits)
Bits 5-4: Verb (2 bits)
Bits 3-0: Flags (4 bits)
Byte 5: Bits 7-4: VER (4 bits, protocol version)
Bits 3-0: Reserved (4 bits, all zeros)
Bytes 6-7: TLV Length (16 bits, big-endian)
Figure 2: Figure 2: µACP Header Bit Layout
The VER field in byte 5 carries the protocol version used for this
message, allowing a receiver to select the correct parsing rules
before examining any TLV content. This field addresses the
bootstrapping problem inherent in TLV-based version negotiation: a
receiver MUST parse byte 5 first and apply the corresponding wire-
format rules before proceeding to the TLV region. The current
specification defines version 0x0. Senders MUST set VER to the
highest version mutually negotiated for the conversation (or 0x0 if
no negotiation has occurred). Receivers MUST reject messages whose
VER value exceeds their maximum supported version with
ERR_VERSION_MISMATCH.
*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 MUST be initialized to a
cryptographically random value to prevent predictability and traffic
analysis. The only exception is when ALL of the following conditions
are met: (1) a new OSCORE security context is being established, (2)
no prior communication history exists with the peer, AND (3) the
initialization is synchronized with the establishment of the new
OSCORE context. In this specific case, initialization to 0 is
acceptable. In all other cases, random initialization is mandatory.
*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
Mallick & Chebolu Expires 29 November 2026 [Page 12]
Internet-Draft µACP May 2026
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 7-6):* Encodes transmission semantics
(fire-and-forget, confirmable transfer, or non-confirmable transfer
without µACP retransmission). Values are defined in the IANA
Considerations section.
*Verb (2 bits, byte 4 bits 5-4):* Identifies one of the four µACP
operations: PING(0), TELL(1), ASK(2), OBSERVE(3).
*Flags (4 bits, byte 4 bits 3-0):* Control bits reserved for
protocol-level features such as fragmentation, retransmission hints,
or message cancellation. Future specifications MAY define additional
meanings for individual flag bits.
*VER (4 bits, byte 5 bits 7-4):* Protocol version number for this
message. MUST be set to 0x0 in this specification. A non-zero value
indicates a later version of µACP. Receivers encountering an
unsupported VER value MUST return ERR_VERSION_MISMATCH and MUST NOT
attempt to parse the remainder of the message under the current
version's rules. Version 0x0 is this specification. Future VER
values are defined only by Experimental or Standards Track RFCs that
explicitly update or obsolete this document; no separate IANA
registry is created for VER values.
*Reserved (4 bits, byte 5 bits 3-0):* MUST be set to zero on
transmission and MUST be ignored by receivers.
*TLV Length (16 bits, bytes 6-7):* Specifies the number of octets in
the TLV region immediately following the header. TLV Length MUST NOT
exceed 1024. A value of 0 indicates that no TLVs are present.
Receivers MUST reject messages where TLV Length exceeds the remaining
message size or the active profile limit. The payload length is the
remaining message length after the 8-byte header and TLV Length
octets.
3.3. TLV Encoding
TLVs (Type-Length-Value structures) convey optional metadata and
extensibility information. They appear immediately after the header,
occupy exactly the number of octets specified by the header TLV
Length field, and MUST appear in Type-increasing order to allow
binary search and deterministic parsing.
Mallick & Chebolu Expires 29 November 2026 [Page 13]
Internet-Draft µACP May 2026
0 7 8 15
+----------+-----------+------------------------------+
| Type | Length | Value (Length octets) |
+----------+-----------+------------------------------+
Figure 3: Figure 3: TLV Encoding
*Type (8 bits):* TLV identifier. Bit 7 (MSB) of the Type byte is the
Criticality flag: if bit 7 = 0, the TLV is non-critical (unknown
types MUST be silently ignored); if bit 7 = 1, the TLV is critical
(unknown types MUST cause the message to be rejected with
ERR_UNSUPPORTED_TLV). The remaining 7 bits (bits 6-0) identify the
specific TLV within its criticality class. Registration ranges are
as follows:
* 0x00-0x1F (non-critical): Expert Review
* 0x20-0x7F (non-critical): Expert Review
* 0x80-0x9F (critical): Expert Review
* 0xA0-0xBF (critical): Expert Review
* 0xC0-0xFF (critical): Private Use
*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 (Section 5).
*Critical TLVs:* Criticality is encoded in bit 7 of the Type byte as
defined above. Receivers MUST reject messages containing unknown
critical TLVs (bit 7 = 1) with ERR_UNSUPPORTED_TLV. Unknown non-
critical TLVs (bit 7 = 0) MUST be silently ignored.
3.3.1. TLV Processing Rules
Receivers MUST apply the following rules when processing TLVs:
* TLVs MUST be parsed strictly in order.
Mallick & Chebolu Expires 29 November 2026 [Page 14]
Internet-Draft µACP May 2026
* If Length exceeds the remaining octets in the TLV region, 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 and its Value
field MUST NOT exceed 255 bytes.
* TLV Type 0x10 (Reserved Fragmentation) MUST be silently ignored.
A future specification will define its semantics.
3.4. Payload Encoding
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). Payload length is inferred from the
enclosing transport object after subtracting the 8-byte header and
the TLV Length value. 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.
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 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 [RFC7959]
SHOULD avoid µACP-level fragmentation.
Mallick & Chebolu Expires 29 November 2026 [Page 15]
Internet-Draft µACP May 2026
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). 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.
3.8. Canonical Encoding Rules
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, the TLV region MUST contain exactly TLV Length
octets, payload MUST begin immediately after the TLV region, and
implementations MUST normalize line endings, whitespace, or internal
representations before hashing or signing application content.
4. Protocol Semantics
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. The only unprotected µACP
message permitted by this specification is PING, and support for
unprotected PING is OPTIONAL.
*PING Security Policy:* OSCORE-protected PING is mandatory to
implement. Support for unencrypted PING is OPTIONAL and MUST be
explicitly configurable. Deployments that enable unencrypted PING
accept the associated privacy and security risks documented in
Section 9.
For each verb, this section defines sender behavior, receiver
behavior, state-machine interactions, mandatory error cases, and
expected processing-time bounds.
Mallick & Chebolu Expires 29 November 2026 [Page 16]
Internet-Draft µACP May 2026
4.1. PING
PING provides low-cost reachability and liveness detection.
Implementations MUST support OSCORE-protected PING. Implementations
MAY support unencrypted PING for lightweight liveness detection in
environments where unauthenticated reachability checking is
acceptable. When unencrypted PING is supported, deployments SHOULD
carefully consider the privacy and security implications.
Sender behavior: MAY emit PING at any time, MUST increment Sequence
ID, SHOULD use unique Correlation ID, SHOULD rate-limit PING
transmissions (the RECOMMENDED default is no more than one per 10
seconds per peer on constrained networks; deployments on higher-
capacity links MAY use shorter intervals). Unencrypted PING MUST
carry no TLVs other than RAW_OCTETS (Type=0x00) and MUST carry a
zero-length payload. Receiver behavior: MUST reply to OSCORE-
protected PING with an OSCORE-protected TELL carrying the same
Correlation ID and an empty payload. When unencrypted PING mode is
explicitly enabled, a receiver MUST reply with an unencrypted TELL
carrying the same Correlation ID, Verb=TELL (1), and an empty payload
— this is the only permitted unprotected TELL in the protocol.
Receivers MUST rate-limit PING processing to mitigate abuse.
Security note: Unencrypted PING messages may leak topology and
presence information through timing analysis, message frequency
patterns, and correlation tracking. Implementations supporting
unencrypted PING SHOULD use rate limiting, randomized response
timing, and Correlation ID randomization to reduce information
leakage. For authenticated liveness detection, use OSCORE-protected
PING or ASK/TELL with OSCORE.
4.2. TELL
TELL conveys information, updates, or asynchronous notifications, and
responds to ASK messages. TELL messages MUST be OSCORE-protected.
Sender: MUST increment Sequence ID; when responding to ASK, MUST use
the same Correlation ID; MAY carry an empty payload and empty TLV set
(e.g., for ACK-like responses). Receiver: MUST validate OSCORE, MUST
associate via Correlation ID, MUST incorporate content per
application policy. Errors: TELL without OSCORE MUST be rejected,
malformed TLVs MUST cause discard.
Mallick & Chebolu Expires 29 November 2026 [Page 17]
Internet-Draft µACP May 2026
4.3. ASK
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 result in TELL(error), security
validation failure results in silent discard, and correlation-table
limits exceeded results in resource exhaustion error.
4.4. OBSERVE
OBSERVE establishes a subscription for future event-driven
notifications, scoped to a single authenticated peer. OBSERVE
messages MUST be OSCORE-protected. The subscriber (sender of
OBSERVE): MUST allocate/update subscription state indexed by
Correlation ID, MUST validate subscription limits, MUST increment
Sequence ID, MAY include subscription parameter TLVs (topic,
conditions, SUBSCRIPTION_LIFETIME). The publisher (receiver of
OBSERVE): MUST validate OSCORE, MUST establish/refresh subscription
state, MUST enforce subscription expiration and resource ceilings,
and when the subscribed condition is met MUST deliver event
notifications as OSCORE-protected TELL messages to the subscriber's
CoAP endpoint (see Section 5.6 for the notification delivery
mechanism).
*Subscription Lifetime:* Every subscription has a lifetime after
which the publisher MUST free subscription state and SHOULD send
TELL(ERR_TIMEOUT) to the subscriber. If the OBSERVE message carries
a SUBSCRIPTION_LIFETIME TLV (Type=0x23), the publisher MUST use that
value (in seconds, uint32) as the lifetime. If no
SUBSCRIPTION_LIFETIME TLV is present, the publisher MUST apply the
RECOMMENDED default lifetime of 86400 seconds (24 hours).
Implementations MAY use a shorter default appropriate to their device
class; the chosen default SHOULD be advertised in the feature-
negotiation response. A subscriber MUST refresh a subscription
before it expires by sending a new OBSERVE message with the same
Correlation ID; the publisher MUST reset the lifetime timer upon
receipt of a valid refresh. Subscribers SHOULD refresh at least 60
seconds before the known expiry.
The subscription remains active and the publisher continues sending
event-triggered TELL notifications until explicitly cancelled or
expired. Cancellation: sender issues OBSERVE or TELL with
Mallick & Chebolu Expires 29 November 2026 [Page 18]
Internet-Draft µACP May 2026
CANCEL_SUBSCRIPTION TLV (Type=0x80, critical), and the receiver MUST
immediately delete subscription state and cease notifications; the
receiver MUST respond with a TELL confirming cancellation. Errors:
subscription limits exceeded result in TELL(error), and OSCORE
validation failure results in silent drop.
4.5. Summary of Normative Requirements
Summary: PING is a liveness probe, MUST support OSCORE-protected
PING, and MAY support unencrypted PING for lightweight deployments;
TELL is an update, response, or notification and MUST use OSCORE; ASK
is a request, MUST use OSCORE, and MUST generate a TELL response;
OBSERVE is a subscription, MUST use OSCORE, and MUST create or update
subscription state. Agents MUST NOT overload verbs with incompatible
semantics.
5. Mandatory Transport Binding: OSCORE/CoAP
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 [RFC9147] or QUIC) but such bindings are outside the
scope of this specification and MUST NOT weaken or replace the
OSCORE/CoAP MTI profile.
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). µACP messages MUST use: Method=POST, URI-
Path="muacp" (fixed), Content-Format=application/muacp, Payload=Full
µACP message. Each µACP message corresponds to exactly one CoAP
POST.
Mallick & Chebolu Expires 29 November 2026 [Page 19]
Internet-Draft µACP May 2026
+-------------------------------+
| CoAP Header (CON/NON) |
+-------------------------------+
| Uri-Path: "muacp" |
+-------------------------------+
| Content-Format: application/muacp |
+-------------------------------+
| OSCORE Option |
+-------------------------------+
| Ciphertext Payload |
| (encapsulated µACP message) |
+-------------------------------+
Figure 4: Figure 4: CoAP Envelope Carrying a µACP Message
5.2. OSCORE Protection Requirements
All µACP messages except unencrypted PING MUST be protected using
OSCORE [RFC8613], which uses COSE [RFC9052] 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.
5.3. Establishing OSCORE Security Contexts
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. Implementations SHOULD limit concurrent OSCORE
contexts according to their device class, see Section 10 for profile-
specific recommendations (MIP: 8 contexts minimum, CNP: 8 contexts
minimum, INP: 64 contexts minimum).
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:
Mallick & Chebolu Expires 29 November 2026 [Page 20]
Internet-Draft µACP May 2026
+==========+======================+=======================+
| µACP QoS | Meaning | CoAP Message Type |
+==========+======================+=======================+
| 0 | fire-and-forget | NON (Non-confirmable) |
+----------+----------------------+-----------------------+
| 1 | confirmable transfer | CON (Confirmable) |
+----------+----------------------+-----------------------+
| 2 | non-confirmable, no | NON (Non-confirmable, |
| | µACP retransmission | no retransmission) |
+----------+----------------------+-----------------------+
Table 1
*QoS Semantics:* QoS=0 (fire-and-forget) provides best-effort
transfer with no µACP delivery tracking; the sender does not expect
an application response unless the verb semantics require one. QoS=1
requests CoAP CON processing and CoAP retransmissions, but a CoAP
acknowledgment does not prove application processing. Messages may
be delivered more than once, and receivers MUST use the OSCORE replay
window together with Sequence ID and Correlation ID to suppress
duplicate side effects when the requested operation is not
idempotent. QoS=2 requests one NON transfer and no µACP
retransmission; if delivery fails, no retry occurs. QoS=2 expresses
sender intent to avoid protocol retries, not a network-wide guarantee
that duplicates can never occur. 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.
5.5. Mapping ASK/TELL to CoAP Request/Response
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.
Agent A Agent B
------- -------
POST /muacp (ASK, OSCORE) ---------->
<---------- 2.04 Changed (TELL, OSCORE)
Figure 5: Figure 5: ASK/TELL Over OSCORE-CoAP
Mallick & Chebolu Expires 29 November 2026 [Page 21]
Internet-Draft µACP May 2026
5.6. Mapping OBSERVE Subscriptions
OBSERVE establishes a long-lived subscription. µACP defines its own
subscription model, independent of CoAP's Observe extension
[RFC7641]. The initial OBSERVE message MUST be sent as a CoAP POST
to the publisher's "/muacp" endpoint. Event notifications are
delivered by the publisher as CoAP POST requests to the subscriber's
"/muacp" endpoint, i.e., the publisher acts as a CoAP client for
notification delivery. Implementations MUST NOT use CoAP Observe for
µACP-defined subscription semantics. This restriction applies only
to µACP message exchange and does not preclude concurrent use of CoAP
Observe for resource-centric interactions outside µACP.
*Notification Delivery Architecture:* µACP OBSERVE requires each
agent to expose a CoAP server endpoint at "/muacp" and be reachable
by its peers for incoming CoAP POST requests on the selected
transport path. When a subscriber sends an OBSERVE to a publisher,
it implicitly registers its own CoAP endpoint (identified by the
OSCORE security context and the CoAP transport address from which the
OBSERVE was sent) as the delivery target for notifications.
Deployments behind NATs, firewalls, or sleeping-link gateways MUST
provide a reachable path by configuration, Resource Directory-
assisted discovery, or an application relay outside this
specification. A change in the subscriber's transport address
invalidates the delivery target until the subscriber refreshes the
subscription. The publisher MUST deliver event notifications to the
current delivery target as OSCORE-protected CoAP POST requests
carrying TELL messages with the matching Correlation ID. If the
publisher cannot reach the subscriber's endpoint, it MUST apply the
selected QoS and CoAP retransmission policy; after exhausting
permitted retries, the publisher MUST terminate the subscription and
free the associated state.
CoAP Observe (RFC 7641) is resource-centric: clients observe changes
to a specific resource identified by URI. µACP OBSERVE is
conversation-centric: agents establish subscriptions scoped to agent-
to-agent conversations, identified by Correlation ID and OSCORE
security context. While both mechanisms provide event notification,
they address different use cases: CoAP Observe targets resource state
monitoring, while µACP OBSERVE enables agent interaction patterns
with subscription lifecycle tied to conversations. The two
mechanisms are complementary and may coexist in deployments.
Mallick & Chebolu Expires 29 November 2026 [Page 22]
Internet-Draft µACP May 2026
5.7. Congestion Control Requirements
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
[RFC7252] Section 4.7.
Agents MUST adhere to: exponential backoff on CoAP CON
retransmissions (initial timeout >= 2s, max 247s per [RFC7252]), PING
rate limiting (RECOMMENDED default: <= 1 per 10 seconds per peer on
constrained networks; deployments SHOULD configure this limit per
their link characteristics), OBSERVE throttling when bandwidth
pressure is detected, deterministic resource usage, message rate
limits per conversation. When Blockwise Transfer [RFC7959] is used,
agents MUST ensure block sizes do not exceed memory limits.
5.8. Transport-Layer Error Handling
Transport errors (CoAP timeouts, OSCORE decryption failures, missing
acknowledgments) MUST be translated into µACP-level behavior. OSCORE
decryption failures cause message drop. Unacknowledged CoAP CON
messages apply µACP QoS semantics for retransmission. Repeated
timeouts move the conversation to a failure state. Malformed CoAP
envelopes are discarded.
5.9. Summary of MTI Requirements
All compliant µACP implementations MUST: support CoAP POST to fixed
path "muacp", support Content-Format application/muacp, 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 establishes interoperability and provides a minimum security
baseline.
6. Error Handling, Version Negotiation, and Extensibility
This section defines normative error-handling rules, version-
negotiation mechanism, downgrade protection requirements, and the
extensibility framework provided by the TLV architecture.
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
8-bit integers and MUST follow the registry defined in the IANA
Considerations section.
Mallick & Chebolu Expires 29 November 2026 [Page 23]
Internet-Draft µACP May 2026
Type: 0x22 (Error-Code, see IANA registry)
Length: 1 octet
Value: uint8 error code
Figure 6: 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.
6.2. Standardized Error Conditions
The following error codes are defined for µACP:
Mallick & Chebolu Expires 29 November 2026 [Page 24]
Internet-Draft µACP May 2026
+======+========================+===================================+
| Code | Name | Description |
+======+========================+===================================+
| 0x00 | SUCCESS | 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). |
+------+------------------------+-----------------------------------+
| 0x01 | ERR_MALFORMED | Malformed header, TLV, or |
| | | payload. |
+------+------------------------+-----------------------------------+
| 0x02 | ERR_UNSUPPORTED_VERB | Verb not recognized or not |
| | | supported by receiver. |
+------+------------------------+-----------------------------------+
| 0x03 | ERR_UNSUPPORTED_TLV | Critical TLV not understood. |
+------+------------------------+-----------------------------------+
| 0x04 | ERR_FORBIDDEN | Operation not permitted due |
| | | to policy or authorization. |
+------+------------------------+-----------------------------------+
| 0x05 | ERR_RESOURCE_EXHAUSTED | Memory, CPU, or subscription/ |
| | | conversation limits exceeded. |
+------+------------------------+-----------------------------------+
| 0x06 | ERR_VERSION_MISMATCH | Message uses unsupported |
| | | protocol version. |
+------+------------------------+-----------------------------------+
| 0x07 | ERR_TIMEOUT | Sender or receiver timed out |
| | | while waiting for a response. |
+------+------------------------+-----------------------------------+
| 0x08 | ERR_INTERNAL | Internal failure not covered |
| | | by other error categories. |
+------+------------------------+-----------------------------------+
| 0x09 | ERR_REPLAY | Message rejected as potential |
| | | replay or out-of-order |
| | | delivery (Sequence ID less |
| | | than or equal to last |
| | | observed value for this |
| | | Correlation ID). |
+------+------------------------+-----------------------------------+
Table 2
Implementations MAY define additional private-use error codes in the
private-use range but MUST NOT redefine standardized codes.
Mallick & Chebolu Expires 29 November 2026 [Page 25]
Internet-Draft µACP May 2026
6.3. Handling Malformed Messages
Receivers MUST apply strict validation: if header TLV Length exceeds
remaining bytes or the active profile limit, discard; if an
individual TLV Length exceeds the remaining TLV-region 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.
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.
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
[RFC1982] 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.
Mallick & Chebolu Expires 29 November 2026 [Page 26]
Internet-Draft µACP May 2026
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_REPLAY to indicate the rejection reason).
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.
6.5. Version Negotiation
µ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).
The VER header field is the wire-format selector and MUST be examined
before interpreting any TLV, including the Version-TLV. A receiver
MUST parse the fixed header, validate that VER identifies a supported
wire format, and only then parse the TLV region according to that
version's rules. The Version-TLV negotiates the version to use for
subsequent messages in a conversation; once a version is selected,
senders MUST place the selected value in the VER field of subsequent
messages for that conversation.
Version negotiation follows these rules:
Mallick & Chebolu Expires 29 November 2026 [Page 27]
Internet-Draft µACP May 2026
* 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-TLV-based negotiation MUST occur under OSCORE protection.
Note: the VER header field (byte 5, bits 7-4) carries the active
version unprotected by design, since it must be read before OSCORE
decryption; this is intentional. PING messages SHOULD NOT carry
Version-TLV. If Version-TLV negotiation is required before OSCORE
context establishment, implementations SHOULD establish the OSCORE
context first, then negotiate versions in a subsequent message.
Type: 0x01 (Version)
Length: N (number of supported versions, 1-255)
Value: Sequence of N unsigned 8-bit integers.
Each integer represents one supported protocol version
(e.g., [0x00] for version 0).
Figure 7: 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.
Mallick & Chebolu Expires 29 November 2026 [Page 28]
Internet-Draft µACP May 2026
6.6. Downgrade and Version-Rollback Protection
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.
6.7. Extensibility Framework
µ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, and private-use TLV values MUST NOT be assumed to interoperate
across vendors. Complex extensions SHOULD define new structured TLVs
rather than overloading primitive types.
6.8. Summary of Normative Requirements
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.
7. IANA Considerations
This section requests the creation of new registries and assignments
required for µACP to function as an interoperable Internet protocol.
This document is published on the Independent Submission stream.
Consistent with the independent stream's scope, all new registries
use the Expert Review policy as defined in [RFC8126] Section 4.5,
administered by designated experts appointed by IANA in consultation
with the ISE. Designated experts are expected to have expertise in
constrained IoT protocols (e.g., CoAP, OSCORE, 6LoWPAN). Expert
review criteria: the proposed value must have a stable public
specification, must not conflict with existing assignments, and must
be consistent with the µACP design principles in this document.
Mallick & Chebolu Expires 29 November 2026 [Page 29]
Internet-Draft µACP May 2026
7.1. µACP TLV Types Registry
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:
Bit 7 of the Type byte is the Criticality flag (0 = non-critical, 1 =
critical). All ranges use Expert Review unless noted:
* *0x00-0x1F* (non-critical): Expert Review
* *0x20-0x7F* (non-critical): Expert Review
* *0x80-0x9F* (critical): Expert Review
* *0xA0-0xBF* (critical): Expert Review
* *0xC0-0xFF* (critical): Private Use
Initial values, all with Reference "This document":
+=====+========================+==========+==================+======+
|Value| Name | Critical | Description |Format|
+=====+========================+==========+==================+======+
|0x00 | RAW_OCTETS | No | Unstructured |Opaque|
| | | | data, MUST NOT | |
| | | | appear in | |
| | | | encrypted | |
| | | | messages; | |
| | | | restricted to | |
| | | | unencrypted | |
| | | | PING. Payload | |
| | | | MUST be zero- | |
| | | | length or | |
| | | | limited to 255 | |
| | | | bytes. | |
+-----+------------------------+----------+------------------+------+
|0x01 | VERSION | No | Advertised |Array |
| | | | supported |of |
| | | | protocol |uint8 |
| | | | versions. | |
+-----+------------------------+----------+------------------+------+
|0x02 | CONTENT_TYPE | No | Specifies |uint8 |
| | | | payload | |
| | | | encoding. | |
+-----+------------------------+----------+------------------+------+
|0x03 | CBOR_PAYLOAD | No | Payload encoded |CBOR |
Mallick & Chebolu Expires 29 November 2026 [Page 30]
Internet-Draft µACP May 2026
| | | | as CBOR. |data |
| | | | |item |
+-----+------------------------+----------+------------------+------+
|0x10 | RESERVED_FRAGMENTATION | No | Reserved for |N/A |
| | | | future | |
| | | | fragmentation | |
| | | | extension. NOT | |
| | | | defined by this | |
| | | | specification. | |
| | | | Receivers MUST | |
| | | | silently ignore | |
| | | | this TLV until | |
| | | | a future | |
| | | | document | |
| | | | defines its | |
| | | | semantics. | |
+-----+------------------------+----------+------------------+------+
|0x20 | TOPIC | No | Subscription |UTF-8 |
| | | | topic for |string|
| | | | OBSERVE. | |
+-----+------------------------+----------+------------------+------+
|0x21 | CONDITION | No | Trigger |UTF-8 |
| | | | condition for |or |
| | | | OBSERVE. |CBOR |
+-----+------------------------+----------+------------------+------+
|0x22 | ERROR_CODE | No | Error code |uint8 |
| | | | returned in | |
| | | | TELL(error). | |
+-----+------------------------+----------+------------------+------+
|0x23 | SUBSCRIPTION_LIFETIME | No | Requested |uint32|
| | | | subscription | |
| | | | lifetime in | |
| | | | seconds for | |
| | | | OBSERVE. | |
| | | | uint32, big- | |
| | | | endian. If | |
| | | | absent, | |
| | | | publisher | |
| | | | applies default | |
| | | | (RECOMMENDED: | |
| | | | 86400 seconds). | |
+-----+------------------------+----------+------------------+------+
|0x80 | CANCEL_SUBSCRIPTION | Yes | Explicit |Empty |
| | | | termination of | |
| | | | OBSERVE | |
| | | | subscription. | |
| | | | Critical: | |
| | | | receivers MUST | |
Mallick & Chebolu Expires 29 November 2026 [Page 31]
Internet-Draft µACP May 2026
| | | | process this | |
| | | | TLV and stop | |
| | | | notifications. | |
| | | | Value field | |
| | | | MUST be empty | |
| | | | (Length=0). | |
+-----+------------------------+----------+------------------+------+
Table 3
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).
+=======+==========================+=================+===========+
| Value | Name | Description | Reference |
+=======+==========================+=================+===========+
| 0 | FIRE_AND_FORGET | No reliability, | This |
| | | mapped to CoAP | document |
| | | NON. | |
+-------+--------------------------+-----------------+-----------+
| 1 | CONFIRMABLE_TRANSFER | Use CoAP CON | This |
| | | and CoAP | document |
| | | retransmission | |
| | | behavior. | |
+-------+--------------------------+-----------------+-----------+
| 2 | NON_CONFIRMABLE_NO_RETRY | Use one CoAP | This |
| | | NON transfer | document |
| | | with no µACP | |
| | | retransmission. | |
+-------+--------------------------+-----------------+-----------+
| 3 | RESERVED | Reserved for | This |
| | | future use. | document |
+-------+--------------------------+-----------------+-----------+
Table 4
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).
Mallick & Chebolu Expires 29 November 2026 [Page 32]
Internet-Draft µACP May 2026
+=======+=========+============================+===============+
| Value | Name | Description | Reference |
+=======+=========+============================+===============+
| 0 | PING | Liveness probe. | This document |
+-------+---------+----------------------------+---------------+
| 1 | TELL | State update, | This document |
| | | notification, or response. | |
+-------+---------+----------------------------+---------------+
| 2 | ASK | Request for information or | This document |
| | | action. | |
+-------+---------+----------------------------+---------------+
| 3 | OBSERVE | Subscription to events or | This document |
| | | state changes. | |
+-------+---------+----------------------------+---------------+
Table 5
7.4. µACP Error Codes Registry
IANA is requested to create a registry entitled "µACP Error Codes"
consisting of integers 0-255.
The assignment policy for values 0-127 is Expert Review. Values
128-255 are Private Use.
Initial values:
Mallick & Chebolu Expires 29 November 2026 [Page 33]
Internet-Draft µACP May 2026
+======+========================+=====================+===========+
| Code | Name | Description | Reference |
+======+========================+=====================+===========+
| 0x00 | SUCCESS | No error, operation | This |
| | | completed | document |
| | | successfully. | |
+------+------------------------+---------------------+-----------+
| 0x01 | ERR_MALFORMED | Malformed header, | This |
| | | TLV, or payload. | document |
+------+------------------------+---------------------+-----------+
| 0x02 | ERR_UNSUPPORTED_VERB | Verb not recognized | This |
| | | or not supported. | document |
+------+------------------------+---------------------+-----------+
| 0x03 | ERR_UNSUPPORTED_TLV | Critical TLV not | This |
| | | understood. | document |
+------+------------------------+---------------------+-----------+
| 0x04 | ERR_FORBIDDEN | Operation not | This |
| | | permitted. | document |
+------+------------------------+---------------------+-----------+
| 0x05 | ERR_RESOURCE_EXHAUSTED | Resource limits | This |
| | | exceeded. | document |
+------+------------------------+---------------------+-----------+
| 0x06 | ERR_VERSION_MISMATCH | Unsupported | This |
| | | protocol version. | document |
+------+------------------------+---------------------+-----------+
| 0x07 | ERR_TIMEOUT | Request timed out. | This |
| | | | document |
+------+------------------------+---------------------+-----------+
| 0x08 | ERR_INTERNAL | Internal failure. | This |
| | | | document |
+------+------------------------+---------------------+-----------+
| 0x09 | ERR_REPLAY | Message rejected as | This |
| | | potential replay. | document |
+------+------------------------+---------------------+-----------+
Table 6
7.5. CoAP Content-Format Registration
IANA is requested to register the following CoAP Content-Format:
Mallick & Chebolu Expires 29 November 2026 [Page 34]
Internet-Draft µACP May 2026
+===================+==========+===================+===========+
| Media Type | Encoding | ID | Reference |
+===================+==========+===================+===========+
| application/muacp | binary | TBD (to be | This |
| | | assigned by IANA) | document |
+-------------------+----------+-------------------+-----------+
Table 7
This Content-Format is mandatory for all µACP-over-CoAP messages.
The Content-Format ID will be assigned by IANA prior to publication.
CoAP Content-Format assignments for independent submissions follow
the Expert Review policy for the CoAP Content-Formats registry.
7.6. Media Type Registration
IANA is requested to register the following media type in the
"application" registry per [RFC6838]:
Type name: application
Subtype name: muacp
Required parameters: none
Optional parameters: none
Encoding considerations: binary
Security considerations: See the Security Considerations section.
Interoperability considerations: Defined by the µACP header,
TLV-region, and payload structure.
Published specification: This document.
Intended usage: COMMON
Author/Change controller: IESG
7.7. Well-Known CoAP Resource
IANA is requested to register the following well-known URI suffix per
[RFC8615] using the "Specification Required" policy:
+============+==========================+===========+
| URI Suffix | Description | Reference |
+============+==========================+===========+
| muacp | Discovery resource | This |
| | indicating µACP support. | document |
+------------+--------------------------+-----------+
Table 8
Mallick & Chebolu Expires 29 November 2026 [Page 35]
Internet-Draft µACP May 2026
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.
7.8. Summary of IANA Actions
IANA is requested to: create the µACP TLV Types registry (Expert
Review) and populate initial values, create the µACP QoS Codes
registry (Expert Review), create the µACP Verb Codes registry (Expert
Review), create the µACP Error Codes registry (Expert Review),
register the CoAP Content-Format application/muacp (Expert Review),
register the media type application/muacp (Expert Review per RFC
6838), and register the well-known URI suffix muacp (Specification
Required per RFC 8615). All Expert Review registries will be
administered by designated experts appointed by IANA on advice of the
ISE.
8. State Machines and Processing Logic
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
enforce a bounded maximum number of concurrent conversations
determined by their resource profile (see Section 10). Agents MUST
reject new conversations with ERR_RESOURCE_EXHAUSTED when resource
limits are exceeded.
8.1. ASK/TELL Conversation State Machine
ASK initiates a conversation, TELL completes it. States: IDLE ->
(send ASK) -> WAIT_RESP -> (recv TELL) -> COMPLETED -> cleanup. On
timeout with QoS=1, the CoAP layer retransmits the CON request; after
CoAP exhausts MAX_RETRANSMIT retransmissions without acknowledgment,
µACP MUST transition to COMPLETED with ERR_TIMEOUT. On timeout with
QoS=0 or QoS=2 (no retransmission), µACP MUST immediately transition
to COMPLETED with ERR_TIMEOUT. Receiver MUST emit TELL(error) for
protocol errors.
Mallick & Chebolu Expires 29 November 2026 [Page 36]
Internet-Draft µACP May 2026
+-----------------+
| IDLE |
+-----------------+
|
| (send ASK)
v
+-----------------+
| WAIT_RESP |<--+
+-----------------+ | (CoAP retransmit,
| | | QoS=1 only, while
(recv TELL) | | | retries remain)
| (timeout, |
| QoS=0/2; or ----+
| QoS=1 after
| max retries)
v
+-----------------+
| COMPLETED |
| (ok or ERR_ |
| TIMEOUT) |
+-----------------+
(cleanup) --> returns to IDLE
Figure 8: Figure 8: ASK/TELL State Machine
8.2. PING State Machine
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 with matching Correlation ID,
or timeout) -> COMPLETED. Responses are always Verb=TELL: OSCORE-
protected TELL for OSCORE-protected PING; unprotected TELL for
unencrypted PING (when permitted). Implementations MUST support
OSCORE-protected PING and MAY support unencrypted PING for
lightweight liveness detection. PING MUST NOT modify application
state and MUST NOT cause retransmissions on timeout.
Mallick & Chebolu Expires 29 November 2026 [Page 37]
Internet-Draft µACP May 2026
+--------+
| IDLE |
+--------+
|
| send PING
v
+--------------+
| WAIT_PONG |
+--------------+
| ^
recv pong | | timeout
v |
+--------------+
| COMPLETED |
+--------------+
Figure 9: Figure 9: PING Liveness FSM
8.3. OBSERVE Subscription State Machine
OBSERVE establishes a long-lived subscription that persists and
delivers multiple event-triggered notifications until cancelled or
expired. The FSM resides on the publisher (receiver of OBSERVE).
Each event trigger causes a TELL notification; the subscription
returns to SUBSCRIBED and awaits the next event. Subscriptions MUST
expire after the negotiated or default lifetime (see Section 4.4) and
MUST enforce resource ceilings (max subscriptions per peer). A new
OBSERVE on the same Correlation ID from the same peer resets the
lifetime timer. Upon expiry, the publisher MUST free all
subscription state and SHOULD notify the subscriber via a
TELL(ERR_TIMEOUT).
Mallick & Chebolu Expires 29 November 2026 [Page 38]
Internet-Draft µACP May 2026
+----------------+
| NO_SUB |
+----------------+
|
| (recv OBSERVE)
v
+----------------+ <---------+
| SUBSCRIBED | |
+----------------+ |
| | |
(event trigger) | (expiry/limit) |
v v |
+----------+ +----------+ |
| NOTIFY | |TERMINATED| |
| (TELL) | +----------+ |
+----------+ cleanup |
| -> NO_SUB |
| (notify sent; subscription |
| still active) |
+-----------------------------+
(recv CANCEL_SUBSCRIPTION TLV
or OBSERVE
with CANCEL_SUBSCRIPTION at any time)
|
v
+----------+
|TERMINATED|
+----------+
cleanup -> NO_SUB
Figure 10: Figure 10: OBSERVE Subscription FSM (Publisher Side)
8.4. Error-State Transitions
Errors MUST transition FSMs to predictable termination states:
ERR_MALFORMED causes discard with no state, ERR_UNSUPPORTED_TLV
terminates the conversation and sends error TELL, ERR_TIMEOUT
completes with error and frees resources, ERR_RESOURCE_EXHAUSTED
rejects without new state, and OSCORE failure causes silent discard
with no state update.
Mallick & Chebolu Expires 29 November 2026 [Page 39]
Internet-Draft µACP May 2026
8.5. Processing Time and Resource Bounds
All FSM transitions MUST complete in bounded time and memory.
Required limits: conversation table (a bounded number of entries,
determined by the active interoperability profile), subscription
table (a bounded number of entries, determined by the active
interoperability profile), deterministic message buffer sizes (header
plus bounded TLV region plus bounded payload), timers without per-
message dynamic allocation. Numeric minimums are defined only in
Section 10 (Interoperability Profiles). Platforms MAY use
preallocated memory pools or static tables.
9. Security Considerations
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.
9.1. Threat Model
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.
9.2. Authentication, Integrity, and Confidentiality
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.
Mallick & Chebolu Expires 29 November 2026 [Page 40]
Internet-Draft µACP May 2026
9.3. Replay Prevention and Freshness
µ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.
9.4. Denial-of-Service and Resource Exhaustion
Implementations MUST enforce: maximum active conversations
(determined by interoperability profile), maximum OBSERVE
subscriptions (determined by interoperability profile), rate limits
on PING and ASK, TLV region size limits (max 1024 bytes), payload
size limits determined by the active profile (MIP default: 1024
bytes; INP: up to 65535 bytes), and static/preallocated memory pools.
Numeric minimums are defined in Section 10 (Interoperability
Profiles). 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.
9.5. Subscription Security
OBSERVE and CANCEL_SUBSCRIPTION 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_SUBSCRIPTION from the same authenticated peer
or timeout/resource exhaustion. Agents MUST reject subscription
attempts exceeding resource ceilings.
9.6. Downgrade Protection
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.
9.7. Key Management
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.
Mallick & Chebolu Expires 29 November 2026 [Page 41]
Internet-Draft µACP May 2026
*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.
9.8. Side-Channel Attacks
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.
9.9. Safe Failure Modes
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.
10. Interoperability and Deployment Profiles
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.
10.1. Minimum Interoperability Profile (MIP)
MIP defines the absolute floor: every conformant µACP implementation
MUST satisfy MIP regardless of device class. All µACP
implementations MUST support: the 64-bit header format (including the
VER field), all four verbs (PING, TELL, ASK, OBSERVE), TLV processing
with ordering and size limits, OSCORE/CoAP transport binding,
Content-Format application/muacp, and error-handling and state-
machine behavior as defined in this specification.
* Minimum concurrent conversations: 8
* Minimum concurrent subscriptions: 4
* Maximum payload size: 1024 bytes (senders MUST NOT send larger
payloads to MIP peers without prior capability negotiation)
* Maximum TLV region: 1024 bytes
Mallick & Chebolu Expires 29 November 2026 [Page 42]
Internet-Draft µACP May 2026
10.2. Constrained Node Profile (CNP)
CNP targets severely constrained microcontroller-class devices (Class
1: ~10 KB RAM / 100 KB flash; Class 2: ~50 KB RAM / 250 KB flash per
[RFC7228]). CNP is a constrained implementation profile that still
satisfies the MIP receive requirements. Implementations declaring
CNP compliance MUST satisfy MIP and additionally MUST use static/
preallocated buffers, minimize logging, and SHOULD prefer PSK/EDHOC-
based OSCORE contexts.
* Minimum concurrent conversations: 8 (same as MIP minimum; CNP
nodes SHOULD expose this limit via feature negotiation)
* Minimum concurrent subscriptions: 4 (same as MIP minimum)
* Maximum payload size accepted: 1024 bytes (same as MIP)
* Maximum TLV region accepted: 1024 bytes (same as MIP)
Note: CNP nodes MAY use smaller routine application payloads, for
example 512-byte payloads and 256-byte TLV regions, as local sending
defaults. Those local defaults MUST NOT be advertised as peer
receive limits unless the implementation is explicitly operating
outside MIP conformance.
10.3. Infrastructure Node Profile (INP)
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.
* Minimum concurrent conversations: 64
* Minimum concurrent subscriptions: 16
* Maximum payload size: 65535 bytes
* Maximum TLV region: 1024 bytes
Mallick & Chebolu Expires 29 November 2026 [Page 43]
Internet-Draft µACP May 2026
10.4. Cross-Profile Interoperability
When an INP node communicates with a CNP node, the INP node SHOULD
discover the peer's capabilities via feature negotiation
(Section 10.5) before sending large messages, and MUST NOT exceed the
peer's advertised payload or TLV limits. CNP nodes MUST ignore
unknown non-critical TLVs. MIP compliance is always the fallback:
when no capability advertisement is available, all parties MUST
assume MIP limits. All profile interactions MUST preserve security
properties.
10.5. Feature Negotiation
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:
muacp-capabilities = {
? "max-tlv-size" => uint, ; Max TLV bytes
? "max-payload-size" => uint, ; Max payload bytes
? "supported-tlv-types" => [*uint], ; TLV Type values
? "supported-versions" => [*uint], ; Protocol versions
? "congestion-modes" => [*text], ; Congestion modes
? "conversation-limit" => uint, ; Max conversations
? "subscription-limit" => uint, ; Max subscriptions
? "default-sub-lifetime" => uint, ; Default subscription lifetime (seconds)
? "profile" => ("mip" / "cnp" / "inp"), ; Profile identifier
}
Figure 11: Feature Negotiation Response Format (CDDL)
All fields are optional. If a field is omitted, implementations MUST
assume the MIP minimum for that capability. Nodes SHOULD cache
results until expiration or reboot. If the resource is unavailable
(4.04 Not Found), implementations MUST assume MIP defaults: max-tlv-
size=1024, max-payload-size=1024, conversation-limit=8, subscription-
limit=4, default-sub-lifetime=86400, supported-versions=[0x00].
Senders MUST NOT transmit payloads or TLV regions exceeding the
peer's advertised or assumed limits.
11. Wire Examples
This section provides essential normative examples of µACP messages.
Additional test vectors are available in the reference implementation
repository [MUACP-IMPL]. Byte order is network byte order (big-
endian).
Mallick & Chebolu Expires 29 November 2026 [Page 44]
Internet-Draft µACP May 2026
11.1. Minimal PING (unencrypted)
A minimal PING contains only the µACP header. The complete 64-bit
header is:
00 01 # Sequence ID = 0x0001
00 01 # Correlation ID = 0x0001
00 # QoS = 0 (bits7:6), Verb = 0 (bits5:4), Flags = 0
00 # VER = 0 (bits7:4), Reserved = 0 (bits3:0)
00 00 # TLV Length = 0 bytes
Total: 8 bytes
Figure 12: Example 1: PING Message (Hex)
No TLVs, no payload. This message may be sent unencrypted over CoAP
NON.
11.2. ASK/TELL over OSCORE
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:
Step 1: ASK before OSCORE encryption:
Header (8 bytes):
00 02 # Sequence ID = 0x0002
00 03 # Correlation ID = 0x0003
60 # QoS=1 (confirmable, bits7:6=01),
# Verb=2 (ASK), Flags=0
00 # VER=0, Reserved=0
00 00 # TLV Length = 0 bytes
TLVs (none in this example):
[No TLVs]
Payload (CBOR-encoded request, 13 bytes):
A1 # CBOR map(1): 1 key-value pair
66 61 63 74 69 6F 6E # text(6): "action"
64 72 65 61 64 # text(4): "read"
Total µACP message:
8 bytes (header) + 0 bytes (TLVs) + 13 bytes (payload)
Mallick & Chebolu Expires 29 November 2026 [Page 45]
Internet-Draft µACP May 2026
= 21 bytes
Step 2: CoAP POST with OSCORE (encrypted):
CoAP Header: 44 02 7A 10 # CON, POST, MID=0x7A10
CoAP Options:
0B 6D 75 61 63 70 # Uri-Path: "muacp"
[Content-Format: application/muacp; IANA value TBD]
09 XX # OSCORE Option
OSCORE-Protected Payload (encrypted µACP message):
[Ciphertext depends on OSCORE context]
Note: the 21-byte message from Step 1 is encrypted here
Step 3: TELL before OSCORE:
Header (8 bytes):
00 03 # Sequence ID = 0x0003
00 03 # Correlation ID = 0x0003
10 # QoS=0, Verb=1 (TELL), Flags=0
00 # VER=0, Reserved=0
00 03 # TLV Length = 3 bytes
TLVs:
22 01 00 # Error-Code TLV:
# Type=0x22, Len=1, Value=SUCCESS
Payload (CBOR-encoded result, 10 bytes):
A1 # CBOR map(1): 1 key-value pair
65 76 61 6C 75 65 # text(5): "value"
F9 4D 60 # float16: 21.5
# 0x4D60 decodes to 21.5
Step 4: CoAP Response with OSCORE (encrypted):
CoAP Header: 64 44 7A 10 # ACK, 2.04 Changed, MID=0x7A10
OSCORE-Protected Payload (encrypted µACP TELL):
[Ciphertext depends on OSCORE context]
Figure 13: 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.
*Note:* The Content-Format numeric option value is intentionally
omitted from this example because it will be assigned by IANA during
the IESG review process. Conformant implementations MUST use the
assigned value for application/muacp.
Mallick & Chebolu Expires 29 November 2026 [Page 46]
Internet-Draft µACP May 2026
12. Conformance Checklist
This section summarizes the conformance points that implementations
need to satisfy. Compliance is determined by the normative
requirements in this specification; external test suites and the
reference implementation repository [MUACP-IMPL] are informative aids
and do not define additional normative requirements.
A conformant implementation MUST satisfy the normative requirements
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, subscription
limits, and bounded processing time (minimums defined per
interoperability profile in Section 10).
* *Interoperability:* Successful message exchange between
independent implementations under the Minimum Interoperability
Profile.
Test vectors can help demonstrate these properties, but a test suite
cannot weaken, replace, or add to the requirements in this document.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
Mallick & Chebolu Expires 29 November 2026 [Page 47]
Internet-Draft µACP May 2026
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC8613] Selander, G., Mattsson, J., and T. Fossati, "OSCORE:
Object Security for Constrained RESTful Environments",
RFC 8613, April 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, September 2015,
<https://www.rfc-editor.org/rfc/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, "Blockwise Transfers in the
Constrained Application Protocol (CoAP)", RFC 7959, August
2016, <https://www.rfc-editor.org/rfc/rfc7959>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9528] Selander, G., Mattsson, J., and M. Furuhed, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", RFC 9528, March 2024,
<https://www.rfc-editor.org/rfc/rfc9528>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014,
<https://www.rfc-editor.org/rfc/rfc7228>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
Mallick & Chebolu Expires 29 November 2026 [Page 48]
Internet-Draft µACP May 2026
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996, <https://www.rfc-editor.org/rfc/rfc1982>.
13.2. Informative References
[FIPA-ACL] (FIPA), F. F. I. P. A., "ACL Message Structure
Specification", 1997,
<https://www.fipa.org/specs/fipa00061/>.
[RFC9176] Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V.
D. Stok, "Constrained RESTful Environments (CoRE) Resource
Directory", RFC 9176, April 2022,
<https://www.rfc-editor.org/rfc/rfc9176>.
[MUACP] Mallick, A. and I. Chebolu, "μACP: A Formal Calculus for
Expressive, Resource-Constrained Agent Communication",
Proc. of the 25th International Conference on Autonomous
Agents and Multiagent Systems AAMAS 2026,
DOI 10.65109/PHRW6922, arXiv 2601.00219, 2026,
<https://doi.org/10.65109/PHRW6922>.
[RFC9147] Rescorla, E., "The Datagram Transport Layer Security
(DTLS) Protocol Version 1.3", RFC 9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
[MUACP-IMPL]
Mallick, A., "µACP Reference Implementation", GitHub
Repository arnab-m1/miuACP, 2025,
<https://github.com/arnab-m1/miuACP>.
Open Questions for Working Group Discussion
The following design choices are highlighted for working group review
and consensus-building:
1. *Unencrypted PING:* Should unencrypted PING be mandatory-to-
implement (for maximum interoperability), optional (current
specification), or prohibited (for maximum security)? The
current draft specifies MAY to balance lightweight liveness
detection with security concerns.
2. *Resource Minimums:* Are the profile-specific resource limits
(MIP: 8/4, CNP: 8/4, INP: 64/16 conversations/subscriptions)
appropriate for the target device classes? Should additional
profiles be defined?
Mallick & Chebolu Expires 29 November 2026 [Page 49]
Internet-Draft µACP May 2026
3. *OBSERVE vs RFC 7641:* Should µACP OBSERVE semantics be more
closely aligned with CoAP Observe (RFC 7641), or maintain
conversation-centric subscription management? What are the
tradeoffs between resource-centric and conversation-centric
approaches?
4. *Transport Bindings:* Should additional transport bindings (e.g.,
DTLS/UDP without CoAP, QUIC) be standardized, or should CoAP/
OSCORE remain the only MTI (mandatory-to-implement) binding?
5. *Interoperability Testing:* What interoperability events or
conformance test suites are needed to validate independent
implementations? Should µACP participate in existing IoT
plugfests?
The authors welcome feedback on these and all other aspects of the
specification. The authors plan to submit this work to the CoRE
Working Group for consideration and to seek ACE review for the OSCORE
and authorization aspects.
Acknowledgments
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 thank the early reviewers who provided detailed feedback
on the wire format, TLV design, and OSCORE integration. Special
thanks to the contributors to the open-source reference
implementation who identified edge cases in the state machine
implementations and provided interoperability testing reports.
The authors acknowledge participants from the IETF CoRE and ACE
working groups whose prior work on OSCORE, EDHOC, and constrained-
device protocols informed the security architecture of µACP.
Discussions at IETF hackathons and CoAP plugfests helped refine the
transport binding specification.
Feedback from researchers working on formal verification of
constrained protocols influenced the deterministic resource bounds
and finite-state machine specifications in this document.
This work is an individual contribution and does not represent the
views of any organization or government entity.
Authors' Addresses
Mallick & Chebolu Expires 29 November 2026 [Page 50]
Internet-Draft µACP May 2026
Arnab Mallick
Centre for Development of Advanced Computing (CDAC)
Hyderabad
India
Email: arnabm@cdac.in
Indraveni Chebolu
Centre for Development of Advanced Computing (CDAC)
Hyderabad
India
Email: indravenik@cdac.in
Mallick & Chebolu Expires 29 November 2026 [Page 51]