Independent Submission A. Mallick Internet-Draft I. Chebolu Intended status: ExperimentalCentre for Development of Advanced Computing (CDAC) Expires: 21 July 2026 17 January 2026 The Micro Agent Communication Protocol (µACP) draft-mallick-muacp-01 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 bounded resource consumption guarantees (memory, energy, bandwidth) 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." Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Mallick & Chebolu Expires 21 July 2026 [Page 1] Internet-Draft µACP January 2026 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 21 July 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Document Structure . . . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 3. Message Model and Encoding Rules . . . . . . . . . . . . . . 8 3.1. Message Structure . . . . . . . . . . . . . . . . . . . . 8 3.2. Header Format . . . . . . . . . . . . . . . . . . . . . . 8 3.3. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. TLV Processing Rules . . . . . . . . . . . . . . . . 11 3.4. Payload Encoding . . . . . . . . . . . . . . . . . . . . 11 3.5. Byte Ordering . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Fragmentation (Optional Feature) . . . . . . . . . . . . 12 3.7. OSCORE Protection Boundaries . . . . . . . . . . . . . . 12 3.8. Canonical Encoding Rules . . . . . . . . . . . . . . . . 12 4. Protocol Semantics . . . . . . . . . . . . . . . . . . . . . 13 4.1. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. TELL . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. ASK . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. OBSERVE . . . . . . . . . . . . . . . . . . . . . . . . . 14 Mallick & Chebolu Expires 21 July 2026 [Page 2] Internet-Draft µACP January 2026 4.5. Summary of Normative Requirements . . . . . . . . . . . . 15 5. Mandatory Transport Binding: OSCORE/CoAP . . . . . . . . . . 15 5.1. Mapping µACP Messages to CoAP . . . . . . . . . . . . . . 15 5.2. OSCORE Protection Requirements . . . . . . . . . . . . . 16 5.3. Establishing OSCORE Security Contexts . . . . . . . . . . 17 5.4. CoAP Message Types and Reliability . . . . . . . . . . . 17 5.5. Mapping ASK–TELL to CoAP Request/Response . . . . . . . . 18 5.6. Mapping OBSERVE Subscriptions . . . . . . . . . . . . . . 19 5.7. Congestion Control Requirements . . . . . . . . . . . . . 19 5.8. Transport-Layer Error Handling . . . . . . . . . . . . . 20 5.9. Summary of MTI Requirements . . . . . . . . . . . . . . . 20 6. Error Handling, Version Negotiation, and Extensibility . . . 21 6.1. Error Code TLVs . . . . . . . . . . . . . . . . . . . . . 21 6.2. Standardized Error Conditions . . . . . . . . . . . . . . 21 6.3. Handling Malformed Messages . . . . . . . . . . . . . . . 22 6.4. Conversation-Lifetime Error Handling . . . . . . . . . . 23 6.5. Version Negotiation . . . . . . . . . . . . . . . . . . . 24 6.6. Downgrade and Version-Rollback Protection . . . . . . . . 25 6.7. Extensibility Framework . . . . . . . . . . . . . . . . . 26 6.8. Summary of Normative Requirements . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7.1. µACP TLV Types Registry . . . . . . . . . . . . . . . . . 27 7.2. µACP QoS Codes Registry . . . . . . . . . . . . . . . . . 29 7.3. µACP Verb Codes Registry . . . . . . . . . . . . . . . . 29 7.4. µACP Error Codes Registry . . . . . . . . . . . . . . . . 30 7.5. CoAP Content-Format Registration . . . . . . . . . . . . 30 7.6. Media Type Registration . . . . . . . . . . . . . . . . . 31 7.7. Well-Known CoAP Resource . . . . . . . . . . . . . . . . 31 7.8. Summary of IANA Actions . . . . . . . . . . . . . . . . . 32 8. State Machines and Processing Logic . . . . . . . . . . . . . 32 8.1. ASK/TELL Conversation State Machine . . . . . . . . . . . 32 8.2. PING/TELL State Machine . . . . . . . . . . . . . . . . . 33 8.3. OBSERVE Subscription State Machine . . . . . . . . . . . 34 8.4. Error-State Transitions . . . . . . . . . . . . . . . . . 34 8.5. Processing Time and Resource Bounds . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Authentication, Integrity, and Confidentiality . . . . . 35 9.3. Replay Prevention and Freshness . . . . . . . . . . . . . 35 9.4. Denial-of-Service and Resource Exhaustion . . . . . . . . 36 9.5. Subscription Security . . . . . . . . . . . . . . . . . . 36 9.6. Downgrade Protection . . . . . . . . . . . . . . . . . . 36 9.7. Key Management . . . . . . . . . . . . . . . . . . . . . 36 9.8. Side-Channel Attacks . . . . . . . . . . . . . . . . . . 36 9.9. Safe Failure Modes . . . . . . . . . . . . . . . . . . . 37 10. Interoperability and Deployment Profiles . . . . . . . . . . 37 10.1. Minimum Interoperability Profile (MIP) . . . . . . . . . 37 10.2. Constrained Node Profile (CNP) . . . . . . . . . . . . . 38 Mallick & Chebolu Expires 21 July 2026 [Page 3] Internet-Draft µACP January 2026 10.3. Infrastructure Node Profile (INP) . . . . . . . . . . . 38 10.4. Cross-Profile Interoperability . . . . . . . . . . . . . 38 10.5. Feature Negotiation . . . . . . . . . . . . . . . . . . 38 11. Wire Examples . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Minimal PING (unencrypted) . . . . . . . . . . . . . . . 39 11.2. ASK/TELL over OSCORE . . . . . . . . . . . . . . . . . . 39 11.3. Complete OSCORE-Protected Example . . . . . . . . . . . 41 11.4. Complete End-to-End Example . . . . . . . . . . . . . . 41 12. Conformance Tests . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 46 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction The Micro Agent Communication Protocol (µACP) is a compact, resource- efficient communication protocol designed for distributed autonomous agents operating on resource-constrained Edge and IoT devices (including Class 1 and Class 2 devices per [RFC7228]). It aims to bridge the gap between resource-light IoT protocols and semantically rich agent communication languages, by offering minimal overhead yet expressive interaction semantics. Modern IoT, edge, and embedded environments often involve devices with limited RAM, CPU, energy, and unreliable or low-bandwidth networks. At the same time, many distributed applications — from sensor networks and robotics swarms to multi-agent systems and edge- native microservices — require coordination, state sharing, event subscriptions, request/response semantics, and lightweight negotiation. Existing protocols are often unsuited: * Traditional agent-communication languages (e.g., FIPA-ACL) impose heavy parsing and runtime overhead unacceptable on microcontroller-class platforms. * Standard IoT protocols (e.g., plain UDP, lightweight publish/ subscribe) provide minimal semantics, making it difficult to implement structured coordination or stateful dialogues. µACP addresses this by defining a wire-efficient, fixed-header, TLV- extensible protocol that offers exactly four core verbs — PING, TELL, ASK, and OBSERVE — which together are sufficient to express common interaction patterns such as request/response, publish/subscribe, and liveness checking. The protocol is designed so that implementations can remain lean, deterministic in resource consumption, and suitable Mallick & Chebolu Expires 21 July 2026 [Page 4] Internet-Draft µACP January 2026 for microcontroller-class devices, while still supporting structured multi-agent interactions. The formal foundations of µACP, including proofs of resource bounds (memory, energy, bandwidth) and verification of safety, boundedness, and liveness properties, are established in [MUACP]. Because security, confidentiality, and integrity are essential for many deployments (especially those involving sensitive data, distributed control, or untrusted networks), this specification mandates the use of the object-security mechanism defined by the IETF as the mandatory-to-implement transport binding: namely, the combination of CoAP (as the transport substrate) with OSCORE (for application-layer message protection) over constrained or lossy links. This ensures that even devices with limited resources can securely exchange µACP messages while preserving end-to-end confidentiality, integrity, and replay protection [RFC8613]. *Working Group Engagement:* This document is submitted as an Independent Submission to the IETF. The authors welcome feedback from relevant working groups, particularly the Constrained RESTful Environments (CoRE) working group and the Light-Weight Implementation Guidance (LWIG) working group, and are open to transitioning this work to a working group if there is community interest and consensus. 1.1. Goals µACP aims to: provide minimal, low-overhead communication for constrained agents with structured semantics; ensure deterministic and bounded resource usage; support essential multi-agent patterns (request/response, publish/subscribe, liveness) using four orthogonal primitives; define a secure, interoperable transport binding; enable extensibility via TLV options without breaking compatibility. 1.2. Scope This specification defines the wire format, core semantics, normative behavior, mandatory transport binding, security constraints, and IANA registries. It does not specify application-level semantics (content encoding, agent ontology, high-level negotiation), which are left to deployment-specific or higher-layer protocols. Mallick & Chebolu Expires 21 July 2026 [Page 5] Internet-Draft µACP January 2026 1.3. Document Structure Sections 2-3 define conventions, terminology, and message encoding. Sections 4-5 define protocol semantics and the mandatory CoAP/OSCORE transport binding. Sections 6-7 cover error handling, version negotiation, and IANA registries. Sections 8-9 define state machines and security considerations. Sections 10-11 cover interoperability profiles, wire examples, and conformance tests. 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 The following terms are used throughout this document: Agent An autonomous software entity that participates in µACP communication. Agents send and receive µACP messages to coordinate with other agents. Verb One of four core communication primitives in µACP: PING, TELL, ASK, or OBSERVE. Verbs are encoded in 2 bits in the message header. TLV Type-Length-Value encoding format used for optional metadata in µACP messages. Each TLV consists of an 8-bit Type, 8-bit Length, and variable-length Value. Correlation ID A 16-bit identifier that groups related messages into a conversation. Messages sharing the same Correlation ID belong to the same conversation. Sequence ID A 16-bit monotonically increasing identifier used for duplicate detection and replay protection within a conversation. Conversation A sequence of related µACP messages identified by a unique Correlation ID. Conversations typically represent request/ response exchanges or subscription relationships. OSCORE Object Security for Constrained RESTful Environments, as defined in [RFC8613]. OSCORE provides end-to-end security for CoAP messages. Mallick & Chebolu Expires 21 July 2026 [Page 6] Internet-Draft µACP January 2026 CoAP The Constrained Application Protocol, as defined in [RFC7252]. CoAP serves as the transport substrate for µACP. Constrained Device A device with limited resources (memory, CPU, energy, bandwidth) as defined in [RFC7228]. Class 1 devices have approximately 10 KB RAM and 100 KB flash. Class 2 devices have approximately 50 KB RAM and 250 KB flash. µACP targets both Class 1 and Class 2 devices, with deployment profiles supporting microcontroller-class platforms (Class 1) and more capable edge infrastructure nodes (Class 2 and beyond). 2.2. Notation This document uses the following notation conventions: * Hexadecimal values are prefixed with "0x" (e.g., 0x01, 0xFF). * Binary values are prefixed with "0b" (e.g., 0b00, 0b11). * Byte order is network byte order (big-endian) unless otherwise specified. * Bit positions are numbered from 0 (most significant bit) to n-1 (least significant bit). * Message formats are shown using ASCII art diagrams. * Code examples use a monospace font. 2.3. Abbreviations The following abbreviations are used in this document: CBOR Concise Binary Object Representation [RFC8949] CID Correlation ID CoAP Constrained Application Protocol COSE CBOR Object Signing and Encryption [RFC8152] EDHOC Ephemeral Diffie-Hellman Over COSE [RFC9528] FSM Finite State Machine IANA Internet Assigned Numbers Authority IoT Internet of Things Mallick & Chebolu Expires 21 July 2026 [Page 7] Internet-Draft µACP January 2026 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 (64b) | TLVs (0..1024 B) | Payload (0..65535 B) | +----------------------+----------------------+-------------------------+ Figure 1: Figure 1: µACP Message Layout The header format is fixed-length and MUST always appear. TLVs and payloads are optional. Messages MUST NOT exceed transport-imposed size limits; for CoAP/OSCORE, these limits are determined by underlying MTU constraints and CoAP Blockwise Transfer [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 21 July 2026 [Page 8] Internet-Draft µACP January 2026 0 7 8 15 16 23 +---------------------+---------------------+--------------------+ | Sequence ID | Correlation ID | QoS |Verb| Flags | +---------------------+---------------------+--------------------+ 24 63 +--------------------------------------------------------------+ | Reserved (24 bits) | +--------------------------------------------------------------+ Byte 0-1: Sequence ID (16 bits, big-endian) Byte 2-3: Correlation ID (16 bits, big-endian) Byte 4: Bits 0-1: QoS (2 bits) Bits 2-3: Verb (2 bits) Bits 4-7: Flags (4 bits) Byte 5-7: Reserved (24 bits, all zeros) Figure 2: Figure 2: µACP Header Bit Layout *Sequence ID (16 bits, bytes 0-1):* Monotonically increasing identifier used for duplicate detection and replay-window tracking. Sequence ID is per-sender (per OSCORE security context) and monotonically increases within each sender's message stream. MUST wrap modulo 2^16. SHOULD be initialized to a random value (not 0) to prevent predictability and traffic analysis. Initialization to 0 is acceptable only when: (1) a new OSCORE security context is established (e.g., after factory reset or key rotation), (2) the device has no previous communication history with the peer, and (3) the initialization is synchronized with the establishment of the new OSCORE context. In all other cases, Sequence IDs SHOULD be initialized to a random value to prevent traffic analysis and correlation across OSCORE context changes. MUST be unpredictable if security-sensitive traffic requires preventing traffic analysis. *Correlation ID (16 bits, bytes 2-3):* Identifies all messages belonging to the same conversation. Correlation ID MUST be unique among active conversations from the same sender (same OSCORE security context). Different senders may independently use the same Correlation ID values, as conversations are scoped per OSCORE security context. SHOULD be randomly generated in security-sensitive deployments. *QoS (2 bits, byte 4 bits 0-1):* Encodes transmission semantics (fire-and-forget, at-least-once, at-most-once). Values are defined in the IANA Considerations section. *Verb (2 bits, byte 4 bits 2-3):* Identifies one of the four µACP operations: PING(0), TELL(1), ASK(2), OBSERVE(3). Mallick & Chebolu Expires 21 July 2026 [Page 9] Internet-Draft µACP January 2026 *Flags (4 bits, byte 4 bits 4-7):* Control bits reserved for protocol-level features such as fragmentation, retransmission hints, or message cancellation. Future specifications MAY define additional meanings. *Byte Layout (Octets 0-7):* Octets 0-1 contain the Sequence ID as a 16-bit big-endian integer. Octets 2-3 contain the Correlation ID as a 16-bit big-endian integer. Octet 4 contains QoS (bits 0-1), Verb (bits 2-3), and Flags (bits 4-7). Octets 5-7 (24 bits) are Reserved and MUST be zero. *Reserved (24 bits, bytes 5-7):* MUST be set to zero on transmission. MUST be ignored by receivers. Reserved bits MAY be repurposed by future µACP versions but MUST NOT change meaning in this version. 3.3. TLV Encoding TLVs (Type–Length–Value structures) convey optional metadata and extensibility information. They appear immediately after the header and MUST appear in Type-increasing order to allow binary search and deterministic parsing. 0 7 8 15 +----------+-----------+------------------------------+ | Type | Length | Value (Length octets) | +----------+-----------+------------------------------+ Figure 3: Figure 3: TLV Encoding *Type (8 bits):* TLV identifier. The meaning of each Type is defined in the IANA registry. Types 0–31 are reserved and governed by Standards Action. Types 32–127 require IETF Review. Types 128–255 are vendor-specific. *Length (8 bits):* Specifies the number of octets in the Value field. The Length field is an 8-bit unsigned integer, allowing values from 0 to 255. 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. *Example:* A message with three TLVs having Value lengths of 100, 200, and 150 octets would have a total TLV region of (1+1+100) + (1+1+200) + (1+1+150) = 456 bytes, which is within the 1024-byte limit. However, a single TLV with Value length 256 would violate the individual TLV constraint (max 255), and a combination of TLVs summing to 1025 bytes would violate the total region constraint. Mallick & Chebolu Expires 21 July 2026 [Page 10] Internet-Draft µACP January 2026 *Value:* Encoded according to Type. For Types other than 0x00 (Raw Octets), the Value is subject to OSCORE protection (Section 5). *Critical TLVs:* A future TLV Type range MAY designate critical TLVs. Receiving an unknown critical TLV MUST cause message rejection. 3.3.1. TLV Processing Rules Receivers MUST apply the following rules when processing TLVs: * TLVs MUST be parsed strictly in order. * If Length exceeds remaining buffer size, the message MUST be discarded. * Unknown TLV Types MUST be ignored unless they are designated critical. * TLV order MUST be strictly increasing by Type; violating this is a format error. * TLV Type 0x00 (Raw Octets) MUST NOT appear in encrypted messages; its use is restricted to unencrypted PING messages. 3.4. Payload Encoding The µACP payload is an optional octet string of 0–65535 bytes. Its semantics depend on the Verb and the application layer. Payloads are typically used for: * Application data (e.g., sensor readings, state updates); * Action parameters and operation descriptors; * Event notifications for OBSERVE subscriptions; * Encoded content (CBOR, JSON, application-specific formats). Payloads MUST be OSCORE-protected unless the message Verb is PING. Payload sizes MUST be validated before allocation to avoid resource exhaustion. If the payload is encoded using CBOR (Type=0x03), receivers MUST treat it as a single CBOR data item. If the payload is JSON (Type=0x02), it MUST be UTF-8 encoded. Mallick & Chebolu Expires 21 July 2026 [Page 11] Internet-Draft µACP January 2026 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. Fragmentation is an optional feature that will be specified in a future extension document. TLV Type 0x10 is reserved in the IANA registry for fragmentation-related TLVs but MUST NOT be used until fragmentation is fully specified. When fragmentation is implemented in the future, fragments MUST preserve Sequence ID, Correlation ID, and Verb; MUST be reassembled in Sequence ID order; and reassembly MUST abort if missing fragments exceed timeout. Deployments using CoAP Blockwise Transfer [RFC7959] SHOULD avoid µACP-level fragmentation to minimize complexity. 3.7. OSCORE Protection Boundaries When µACP is transported over CoAP with OSCORE, the OSCORE-protected CoAP payload MUST contain the complete µACP message (Header | TLVs | Payload). The OSCORE security context determines integrity, confidentiality, and replay parameters. The following MUST be protected by OSCORE: * All TLVs except those in unencrypted PING messages; * The entire payload; * The header fields other than those needed for outer CoAP routing. Implementations MUST NOT leak semantics (e.g., Verb, QoS) through the CoAP outer header beyond what OSCORE permits. 3.8. Canonical Encoding Rules To ensure interoperability and deterministic parsing, µACP defines the following canonical encoding rules: * Fields MUST NOT be padded. * TLVs MUST be sorted by ascending Type. * No two TLVs MAY share the same Type unless explicitly defined. Mallick & Chebolu Expires 21 July 2026 [Page 12] Internet-Draft µACP January 2026 * Payload MUST begin immediately after the last TLV. * Implementations MUST normalize line endings, whitespace, or internal representations before hashing or signing application content. These rules ensure that µACP messages can be compared as byte strings and efficiently parsed on constrained devices. 4. 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, unless an application explicitly operates in an unauthenticated environment. For each verb, this section defines sender behavior, receiver behavior, state-machine interactions, mandatory error cases, and expected processing-time bounds. 4.1. PING PING provides a low-cost mechanism for reachability and liveness detection. PING messages SHOULD NOT carry OSCORE-protected content and SHOULD be sent unencrypted to remain lightweight and congestion- safe. However, implementations MAY support OSCORE-protected PING messages for deployments requiring authenticated liveness detection, at the cost of increased message size and processing overhead. Sender: MAY emit PING at any time; MUST increment Sequence ID; SHOULD use unique Correlation ID; SHOULD avoid payload; MUST rate-limit to prevent flooding (recommended: no more than one PING per 10 seconds per peer, with exponential backoff on failures). Receiver: SHOULD reply with TELL; MUST NOT require OSCORE for unencrypted PING; MAY require OSCORE for PING if configured for authenticated-only mode; MAY update reachability heuristics; MUST ignore disallowed TLVs; SHOULD rate-limit PING processing to prevent DoS. If an unencrypted PING contains encrypted TLVs or payload, receiver MUST treat as malformed. *Security Considerations for PING:* Unencrypted PING messages may leak information about network topology, device presence, or communication patterns. Implementations SHOULD use rate limiting and randomization to reduce information leakage. For deployments Mallick & Chebolu Expires 21 July 2026 [Page 13] Internet-Draft µACP January 2026 requiring authenticated liveness detection, implementations SHOULD use ASK/TELL with OSCORE protection, or MAY use OSCORE-protected PING if supported. Implementations MUST NOT use unencrypted PING for sensitive operations or as a substitute for authenticated heartbeat mechanisms in security-critical deployments. 4.2. TELL TELL conveys information, updates, or asynchronous notifications, and is the primary mechanism for distributing state and responding to ASK messages. TELL messages MUST be OSCORE-protected unless the deployment explicitly allows an unauthenticated mode. Sender: MUST include payload or meaningful TLV set; SHOULD ensure idempotency for Correlation ID; MUST increment Sequence ID; when responding to ASK, MUST use same Correlation ID; for OBSERVE notifications, MUST include event-related TLVs. Receiver: MUST validate OSCORE before processing; MUST associate via Correlation ID; MUST incorporate content per application policy; in OBSERVE notifications, MUST update subscription state. Errors: TELL without OSCORE MUST be rejected (unless non-secure mode); malformed TLVs MUST cause discard. 4.3. ASK ASK initiates a request for information or action, analogous to a query, command, or method invocation, 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; SHOULD include sufficient payload information; MUST start request timer (expiration triggers retransmission for QoS≥1 or failure); MUST enforce conversation limits. Receiver: MUST validate OSCORE; MUST associate ASK with Correlation ID; MUST generate TELL response with result or error TLV; if request cannot be satisfied in bounded time, MAY send immediate error TELL; SHOULD ensure bounded execution time. Errors: malformed/conflicting TLVs → TELL(error); security validation failure → silent discard; correlation-table limits exceeded → resource exhaustion error. 4.4. OBSERVE OBSERVE establishes a subscription for future notifications, analogous to publish/subscribe but scoped to a single peer. OBSERVE messages MUST be OSCORE-protected. Sender: MUST allocate/update subscription state indexed by Correlation ID; MUST validate subscription limits; MUST increment Sequence ID; MAY include subscription parameter TLVs (topic, conditions); MUST send periodic TELL notifications while active. Receiver: MUST validate OSCORE; MUST establish/refresh subscription state; SHOULD acknowledge with TELL containing subscription parameters; MUST enforce expiration, Mallick & Chebolu Expires 21 July 2026 [Page 14] Internet-Draft µACP January 2026 backpressure, and resource ceilings; when conditions met, MUST send event notifications as TELL. Cancellation: TELL or OBSERVE with Cancel-Subscription TLV (Type=0xFF) → receiver MUST delete state, stop notifications, MAY send confirmation TELL. Errors: subscription limits exceeded → TELL(error); unknown topic/condition TLVs → MAY reject; OSCORE validation failure → drop. 4.5. Summary of Normative Requirements The following summarizes the semantic requirements of each verb: * *PING:* Liveness probe; SHOULD NOT require OSCORE (unencrypted by default for lightweight operation); implementations MAY support OSCORE-protected PING for authenticated deployments; MUST NOT include protected TLVs in unencrypted PING. * *TELL:* Update/response/notification; MUST use OSCORE except in explicitly insecure deployments. * *ASK:* Request; MUST use OSCORE; MUST generate a TELL response. * *OBSERVE:* Subscription; MUST use OSCORE; MUST create or update subscription state. Agents MUST NOT overload verbs with incompatible semantics. All application-defined behaviors MUST build upon these primitives in a manner that preserves µACP’s resource and security guarantees. 5. 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 under specific deployment configurations). Mallick & Chebolu Expires 21 July 2026 [Page 15] Internet-Draft µACP January 2026 µACP messages MUST use the following CoAP message structure: * *Method:* POST * *URI-Path:* "muacp" (fixed path for interoperability) * *Content-Format:* application/muacp+binary * *Payload:* Full µACP message This yields the canonical envelope: +-------------------------------+ | CoAP Header (CON/NON) | +-------------------------------+ | Uri-Path: "muacp" | +-------------------------------+ | Content-Format: muacp+binary| +-------------------------------+ | OSCORE Option | +-------------------------------+ | Ciphertext Payload | | (encapsulated µACP message) | +-------------------------------+ Figure 4: Figure 4: CoAP Envelope Carrying a µACP Message Each µACP message corresponds to exactly one CoAP POST. For request/ response interactions (ASK → TELL), CoAP confirmable/non-confirmable messages MAY be used depending on QoS requirements. 5.2. OSCORE Protection Requirements All µACP messages except unencrypted PING MUST be protected using OSCORE. OSCORE (as defined in [RFC8613]) uses COSE ([RFC8152]) for cryptographic operations and provides confidentiality, integrity, and replay protection independent of the transport layer. OSCORE MUST protect the following elements: * The entire µACP header (except when outer CoAP metadata is required for routing). * All TLVs except raw TLVs permitted for PING. * The entire µACP payload. Mallick & Chebolu Expires 21 July 2026 [Page 16] Internet-Draft µACP January 2026 OSCORE replay protection MUST be enabled. Implementations MUST configure replay windows to match expected message rate and resource constraints. OSCORE MUST use a unique security context per agent-pair. Context reuse between unrelated peers is prohibited. 5.3. Establishing OSCORE Security Contexts Security contexts for OSCORE MAY be derived by any of the following methods: * *EDHOC (RECOMMENDED):* A lightweight authenticated key exchange protocol suitable for constrained devices. * *Pre-Shared Keys (PSK):* For deployments with pre-configured trust anchors. * *Out-of-band provisioning:* Where security associations are established during manufacturing or commissioning. When EDHOC is used, the resulting OSCORE context MUST be bound to the EDHOC handshake transcript to prevent identity misbinding attacks. *OSCORE Context Exhaustion:* Constrained devices may have limited memory for storing OSCORE security contexts. If a device exhausts its available context storage, it MUST reject new context establishment requests with ERR_RESOURCE_EXHAUSTED. Implementations SHOULD implement context eviction policies (e.g., least-recently- used) to free resources for new contexts. However, active conversations MUST NOT be terminated due to context eviction; implementations MUST either maintain contexts for active conversations or gracefully terminate conversations before evicting their contexts. For Class 1 devices with severe memory constraints, implementations SHOULD limit the maximum number of concurrent OSCORE contexts (e.g., 8-16 contexts) and provide clear error signaling when limits are reached. Context exhaustion is a resource management issue that implementations MUST handle gracefully to prevent denial- of-service conditions. 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 21 July 2026 [Page 17] Internet-Draft µACP January 2026 +==========+========================+=======================+ | µACP QoS | Meaning | CoAP Message Type | +==========+========================+=======================+ | 0 | fire-and-forget | NON (Non-confirmable) | +----------+------------------------+-----------------------+ | 1 | at-least-once delivery | CON (Confirmable) | +----------+------------------------+-----------------------+ | 2 | at-most-once delivery | NON (Non-confirmable, | | | | no retransmission) | +----------+------------------------+-----------------------+ Table 1 *QoS Semantics:* QoS=0 (fire-and-forget) provides best-effort delivery with no reliability guarantees. QoS=1 (at-least-once) ensures delivery through CoAP retransmissions. QoS=2 (at-most-once) provides a single delivery attempt without retransmission, suitable for idempotent operations where duplicate delivery must be avoided. Both QoS=0 and QoS=2 use CoAP NON messages. The practical difference is semantic: QoS=0 indicates the sender does not care about delivery confirmation and allows CoAP-level retransmission if configured by the CoAP implementation. QoS=2 explicitly signals that the operation is idempotent and the sender requires exactly one delivery attempt (no retransmission) to prevent duplicate processing of non-idempotent operations. Implementations MUST NOT retransmit QoS=2 messages at the µACP layer, even if the underlying CoAP layer supports retransmission. CoAP-level acknowledgments MUST NOT be interpreted as µACP-level responses. Application responses are always encoded as TELL messages. 5.5. Mapping ASK–TELL to CoAP Request/Response ASK messages MUST be sent as CoAP POST requests. Corresponding TELL responses MUST be sent as CoAP responses. OSCORE MUST protect both directions. The Correlation ID uniquely links the ASK with the TELL response. CoAP Message IDs MUST NOT be used for application correlation. Receivers MUST respond with a TELL message even when requests fail, using an Error TLV to describe failure conditions. Agent A Agent B ------- ------- POST /muacp (ASK, OSCORE) ----------> <---------- 2.04 Changed (TELL, OSCORE) Mallick & Chebolu Expires 21 July 2026 [Page 18] Internet-Draft µACP January 2026 Figure 5: Figure 5: ASK/TELL Over OSCORE-CoAP 5.6. Mapping OBSERVE Subscriptions OBSERVE establishes a long-lived subscription. Subscriptions are maintained by application logic and do NOT rely on CoAP's Observe extension [RFC7641]. µACP defines its own subscription model, independent of CoAP's Observe option. OBSERVE MUST be mapped as: * A CoAP POST containing an µACP OBSERVE message. * Notification messages delivered as CoAP POSTs containing TELL messages. Implementations MUST NOT use CoAP Observe for µACP subscriptions, to avoid semantic conflicts. 5.7. Congestion Control Requirements All µACP-over-CoAP deployments MUST implement congestion control to prevent network collapse and unfair bandwidth usage. Implementations MUST follow CoAP congestion control mechanisms as specified in [RFC7252] Section 4.7. Agents MUST adhere to the following rules: * *Exponential backoff:* Apply exponential backoff on CoAP CON retransmissions. The initial retransmission timeout SHOULD be at least 2 seconds, with exponential backoff (multiply by 2) up to a maximum of 247 seconds, as specified in [RFC7252]. * *PING rate limiting:* Rate-limit PING messages to avoid liveness floods. Implementations SHOULD send no more than one PING per 10 seconds per peer, with exponential backoff on failures. This rate limit is specified in Section 4.1. * *OBSERVE throttling:* Throttle OBSERVE notifications when bandwidth pressure is detected. Implementations SHOULD implement adaptive rate limiting based on network conditions and receiver feedback. * *Deterministic resource usage:* Maintain deterministic CPU and buffer usage for message handling to prevent resource exhaustion attacks. Mallick & Chebolu Expires 21 July 2026 [Page 19] Internet-Draft µACP January 2026 * *Message rate per conversation:* Avoid generating more than one message per RTT per conversation, except under QoS ≥ 1 retransmission requirements. When Blockwise Transfer [RFC7959] is used, agents MUST ensure block sizes do not exceed memory limits and MUST follow CoAP blockwise transfer congestion control rules. 5.8. Transport-Layer Error Handling Transport errors such as CoAP timeouts, OSCORE decryption failures, or missing acknowledgments MUST be translated into µACP-level behavior rather than silently ignored. Specifically: * If OSCORE decryption fails, the µACP message MUST be dropped. * If a CoAP CON message is not acknowledged, the sender MUST apply µACP QoS semantics to determine retransmission. * Repeated timeouts MUST cause the µACP conversation to enter a failure state. * Malformed CoAP envelopes MUST cause message discard. 5.9. Summary of MTI Requirements All compliant µACP implementations MUST: * Support CoAP POST requests to the fixed path "muacp". * Support Content-Format: application/muacp+binary. * Protect all messages except unencrypted PING with OSCORE. * Enforce OSCORE replay protection. * Derive OSCORE contexts using EDHOC or equivalent secure provisioning. * Map QoS codes to CoAP message types according to the CoAP Message Types and Reliability section. * Generate TELL responses for all ASK messages. * Deliver notifications for active OBSERVE subscriptions as TELL messages. Mallick & Chebolu Expires 21 July 2026 [Page 20] Internet-Draft µACP January 2026 This binding ensures interoperability across all µACP implementations and establishes a minimum security baseline for deployments. 6. Error Handling, Version Negotiation, and Extensibility This section defines the normative error-handling rules for µACP, the version-negotiation mechanism, downgrade protection requirements, and the extensibility framework provided by the TLV architecture. Proper handling of malformed messages, incompatible versions, and future extensions is essential for interoperability and robustness. 6.1. Error Code TLVs All protocol-level errors MUST be communicated using a TELL message that includes an Error-Code TLV. Error codes are encoded as unsigned integers and MUST follow the registry defined in the IANA Considerations section. Type: 0x22 (Error-Code, see IANA registry) Length: 1 or 2 octets Value: Integer error code 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: +======+========================+===================================+ | Code | Name | Description | +======+========================+===================================+ | 0x00 | SUCCESS | No error; operation completed | | | | successfully. This code is | | | | OPTIONAL and MAY be included in | | | | TELL messages to explicitly | | | | indicate successful completion, | | | | particularly useful for | | | | debugging, logging, or explicit | | | | acknowledgment scenarios. If | | | | omitted, successful completion | | | | is indicated by the absence of | | | | an Error-Code TLV. | | | | Implementations SHOULD omit | | | | SUCCESS codes to minimize | Mallick & Chebolu Expires 21 July 2026 [Page 21] Internet-Draft µACP January 2026 | | | message size in production | | | | deployments, but MAY include | | | | them for explicit | | | | acknowledgment, testing, or | | | | diagnostic purposes. 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. | +------+------------------------+-----------------------------------+ Table 2 Implementations MAY define additional vendor-specific error codes in the vendor range but MUST NOT redefine standardized codes. 6.3. Handling Malformed Messages Receivers MUST apply strict validation to protect against malformed messages and resource attacks. Specifically: * If TLV Length exceeds remaining bytes, the message MUST be discarded. * If TLVs appear out of Type order, the message MUST be discarded. Mallick & Chebolu Expires 21 July 2026 [Page 22] Internet-Draft µACP January 2026 * If a required TLV (future versions) is absent, the message MUST be rejected. * If header fields contain invalid combinations (e.g., reserved bits set), the message MUST be rejected. * If OSCORE decryption fails, the message MUST be discarded without error signaling. Where feasible, a receiver SHOULD send a TELL(error) message to report failure, unless doing so would amplify a denial-of-service attack. 6.4. Conversation-Lifetime Error Handling Conversations MAY fail due to timeouts, resource limits, or message corruption. When such failures occur: * The agent MUST free associated resources (conversation-table entries). * The agent SHOULD send an ERR_TIMEOUT or ERR_RESOURCE_EXHAUSTED TELL message. * For resource exhaustion, an agent MUST NOT attempt recovery that risks violating its resource budget. 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. 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- Mallick & Chebolu Expires 21 July 2026 [Page 23] Internet-Draft µACP January 2026 order delivery. The receiver MUST NOT modify the existing conversation state and SHOULD silently discard the new message (or MAY send ERR_MALFORMED if the message appears valid but out- of-order). This deterministic strategy ensures interoperability while preventing resource exhaustion and replay attacks. Note: Correlation ID collisions are rare when Correlation IDs are randomly generated with sufficient entropy (at least 16 bits of randomness). Collisions from different senders (different OSCORE contexts) are handled separately, as each OSCORE context maintains its own conversation state. *Security Analysis of Collision Resolution:* The Sequence ID comparison strategy (step 2) is secure because Sequence IDs are authenticated and integrity-protected by OSCORE. An attacker cannot forge a higher Sequence ID without compromising the OSCORE security context. If an attacker compromises an OSCORE context, they can already send arbitrary messages, so the collision resolution does not introduce additional vulnerabilities. The strategy prevents replay attacks (step 3) by rejecting messages with Sequence IDs less than or equal to the last observed value. However, legitimate Correlation ID reuse after conversation completion is handled correctly: if a sender legitimately reuses a Correlation ID after the previous conversation has timed out or completed, the new message will have a higher Sequence ID (since Sequence IDs are monotonically increasing per sender), and the receiver will correctly accept it. The security of this approach depends on the security of the underlying OSCORE context and the randomness of Correlation ID generation. *Example:* If an active conversation exists with Correlation ID=0x1234 and 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 field in the TLV space to allow forward compatibility. A Version-TLV (Type=0x01) MAY be included in any message to indicate the sender’s supported protocol versions. Mallick & Chebolu Expires 21 July 2026 [Page 24] Internet-Draft µACP January 2026 Type: 0x01 (Version) Length: N (number of supported versions) Value: Array of version numbers (e.g., [0x00]) Figure 7: Figure 7: Version TLV If no Version-TLV is present, receivers MUST assume the message uses version 0x00 (this specification). Receivers MUST ignore Version- TLVs indicating versions higher than supported. Receivers MUST accept messages labeled as version 0x00 (this specification) unless malformed. Version negotiation follows these rules: * If a message includes a Version-TLV that indicates only unsupported versions (i.e., all versions listed in the Version-TLV are higher than the receiver's maximum supported version), the receiver MUST return ERR_VERSION_MISMATCH in a TELL error response. * If the Version-TLV contains at least one supported version, the receiver MUST use the highest mutually supported version for subsequent messages in the conversation. * When both parties send Version-TLVs (e.g., in ASK and TELL), each party MUST independently select the highest mutually supported version from the union of both Version-TLV lists. If no common version exists, the receiver MUST return ERR_VERSION_MISMATCH. * The selected version applies to all messages in the conversation identified by the Correlation ID. Once a version is selected, it MUST NOT be changed for that conversation. * Version negotiation MUST occur under OSCORE protection. PING messages (which are typically unencrypted) SHOULD NOT carry Version-TLV to maintain lightweight operation. If version negotiation is required before OSCORE context establishment, implementations SHOULD use ASK/TELL with OSCORE or establish the OSCORE context first, then negotiate versions in subsequent messages. 6.6. Downgrade and Version-Rollback Protection Implementations MUST ensure that attackers cannot force a peer to use a lower protocol version when a higher mutually supported version is available. Specifically: Mallick & Chebolu Expires 21 July 2026 [Page 25] Internet-Draft µACP January 2026 * When a Version TLV lists multiple supported versions, the highest mutually supported version MUST be chosen. * Version negotiation MUST occur inside OSCORE-protected messages except for PING. * Agents MUST NOT downgrade versions unless a failure condition explicitly requires fallback. 6.7. Extensibility Framework µACP is designed to evolve through extensible mechanisms based on TLVs. The following constraints ensure future versions remain interoperable: * *Forward compatibility:* Receivers MUST ignore unknown non- critical TLVs. * *Backward compatibility:* Implementations MUST NOT reuse TLV Types for different semantics. * *Critical TLVs:* Future versions MAY introduce critical TLVs; receiving an unsupported critical TLV MUST trigger ERR_UNSUPPORTED_TLV. * *TLV ordering:* All TLVs MUST be sorted by increasing Type value. * *Vendor extensions:* Types 128–255 are reserved for vendor- specific semantics and MUST NOT require global registration. Complex or multi-field extensions SHOULD define new structured TLVs rather than overloading primitive types. 6.8. Summary of Normative Requirements This section can be summarized as follows: * Malformed messages MUST be rejected and SHOULD trigger a TELL(error) unless unsafe. * Errors MUST use standardized codes where applicable. * Version negotiation MUST prefer the highest mutually supported version. * Unknown non-critical TLVs MUST be ignored; unknown critical TLVs MUST trigger errors. Mallick & Chebolu Expires 21 July 2026 [Page 26] Internet-Draft µACP January 2026 * OSCORE failures MUST cause silent discard. * Resource exhaustion MUST lead to conservative cleanup behavior. These requirements ensure that µACP remains robust, extensible, and secure across diverse deployments. 7. IANA Considerations This section requests the creation of new registries and assignments required for µACP to function as an interoperable Internet protocol. All registries use the policies defined in [RFC8126]. Unless otherwise stated, values are allocated using the "IETF Review" policy. 7.1. µACP TLV Types Registry IANA is requested to create a new registry entitled "µACP TLV Types". The registry consists of 8-bit values (0–255). Each entry MUST contain: * Value (0–255) * Name * Description * Value format (e.g., integer, UTF-8, CBOR) * Reference The range is divided as follows: * *0–31:* Standards Action * *32–127:* IETF Review * *128–255:* Vendor-specific IANA is requested to populate the registry with the initial values below: +=====+=====================+==================+========+===========+ |Value| Name | Description |Format | Reference | +=====+=====================+==================+========+===========+ |0x00 | RAW_OCTETS | Unstructured |Opaque | This | | | | data; MUST NOT | | document | | | | appear in | | | Mallick & Chebolu Expires 21 July 2026 [Page 27] Internet-Draft µACP January 2026 | | | encrypted | | | | | | messages except | | | | | | PING. | | | +-----+---------------------+------------------+--------+-----------+ |0x01 | VERSION | Advertised |Array of| This | | | | supported |integers| document | | | | protocol | | | | | | versions. | | | +-----+---------------------+------------------+--------+-----------+ |0x02 | CONTENT_TYPE | Specifies |Integer | This | | | | payload | | document | | | | encoding. | | | +-----+---------------------+------------------+--------+-----------+ |0x03 | CBOR_PAYLOAD | Payload encoded |CBOR | This | | | | as CBOR. |data | document | | | | |item | | +-----+---------------------+------------------+--------+-----------+ |0x10 | RESERVED | Reserved for |N/A | This | | | | future | | document | | | | fragmentation | | | | | | specification. | | | | | | Implementations | | | | | | MUST NOT use | | | | | | Type=0x10 until | | | | | | fragmentation | | | | | | is fully | | | | | | specified in a | | | | | | future | | | | | | extension | | | | | | document. | | | +-----+---------------------+------------------+--------+-----------+ |0x20 | TOPIC | Subscription |UTF-8 | This | | | | topic for |string | document | | | | OBSERVE. | | | +-----+---------------------+------------------+--------+-----------+ |0x21 | CONDITION | Trigger |UTF-8 or| This | | | | condition for |CBOR | document | | | | OBSERVE. | | | +-----+---------------------+------------------+--------+-----------+ |0x22 | ERROR_CODE | Error code |Integer | This | | | | returned in | | document | | | | TELL(error). | | | +-----+---------------------+------------------+--------+-----------+ |0xFF | CANCEL_SUBSCRIPTION | Explicit |Empty | This | | | | termination of | | document | | | | OBSERVE | | | | | | subscription. | | | +-----+---------------------+------------------+--------+-----------+ Mallick & Chebolu Expires 21 July 2026 [Page 28] Internet-Draft µACP January 2026 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; mapped to | This | | | | CoAP NON. | document | +-------+-----------------+---------------------------+-----------+ | 1 | AT_LEAST_ONCE | Retransmissions required; | This | | | | mapped to CoAP CON. | document | +-------+-----------------+---------------------------+-----------+ | 2 | AT_MOST_ONCE | No retransmission; mapped | This | | | | to CoAP NON. | document | +-------+-----------------+---------------------------+-----------+ | 3 | RESERVED | Reserved for future use. | This | | | | | 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 21 July 2026 [Page 29] Internet-Draft µACP January 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 initial contents are listed in the Error Handling section. The assignment policy for values 0–127 is IETF Review. Values 128–255 are vendor-specific and use the "First Come First Served" policy. *Note:* The Error Codes registry uses different assignment policies than the TLV Types registry. Error Codes 0–127 require IETF Review, while TLV Types 0–31 require Standards Action. This difference reflects the different criticality and extensibility needs of these two protocol elements. TLV Types affect message structure and parsing, requiring stricter control to prevent interoperability failures. Error Codes, while important, are less likely to cause parsing failures and can be extended more flexibly through the IETF Review process. 7.5. CoAP Content-Format Registration IANA is requested to register the following CoAP Content-Format: Mallick & Chebolu Expires 21 July 2026 [Page 30] Internet-Draft µACP January 2026 +==============+==============+==========+============+===========+ | Name | Media Type | Encoding | ID | Reference | +==============+==============+==========+============+===========+ | application/ | application/ | Binary | TBD (to be | This | | muacp+binary | muacp+binary | | assigned | document | | | | | by IANA) | | +--------------+--------------+----------+------------+-----------+ Table 6 This Content-Format is mandatory for all µACP-over-CoAP messages. *Note:* The Content-Format ID value marked as "TBD" will be assigned by IANA during the IESG review process, prior to publication of this document as an RFC. The assignment will follow the "IETF Review" policy as specified in [RFC8126]. 7.6. Media Type Registration IANA is requested to register the following media type in the "application" registry per [RFC6838]: Type name: application Subtype name: muacp+binary Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: See Security Considerations section. Interoperability considerations: Defined by TLV and header structure. Published specification: This document. Intended usage: COMMON Author/Change controller: IETF 7.7. Well-Known CoAP Resource IANA is requested to register the following CoAP Well-Known URI per [RFC8615] using the "IETF Review" policy: +====================+==========================+===========+ | URI | Description | Reference | +====================+==========================+===========+ | /.well-known/muacp | Discovery resource | This | | | indicating µACP support. | document | +--------------------+--------------------------+-----------+ Table 7 Mallick & Chebolu Expires 21 July 2026 [Page 31] Internet-Draft µACP January 2026 A CoAP GET to /.well-known/muacp SHOULD return a CBOR structure describing supported TLVs, maximum sizes, and supported versions. 7.8. Summary of IANA Actions IANA is requested to: * Create the µACP TLV Types registry and populate initial values. * Create the µACP QoS Codes registry. * Create the µACP Verb Codes registry. * Create the µACP Error Codes registry. * Register the CoAP Content-Format application/muacp+binary. * Register the media type application/muacp+binary. * Register the well-known CoAP resource /.well-known/muacp. These actions enable interoperable deployment of µACP across implementations and ensure long-term extensibility under IETF governance. 8. State Machines and Processing Logic This section defines the normative finite-state machines (FSMs) governing µACP conversations. Implementations MUST implement these FSMs to ensure deterministic, interoperable behavior. Agents operate according to a deterministic event loop: receive message, validate OSCORE (if required), validate header/TLVs/payload, identify conversation via Correlation ID, execute verb-specific FSM transition, emit resulting messages. Agents MUST support at least 64 concurrent conversations and MUST reject new conversations if resource ceilings are exceeded (ERR_RESOURCE_EXHAUSTED). 8.1. ASK/TELL Conversation State Machine ASK initiates a conversation; TELL completes it. States: IDLE → (send ASK) → WAIT_RESP → (recv TELL or timeout) → COMPLETED → cleanup. If timer expires and QoS=1, retransmit ASK. If QoS=0/2, transition to COMPLETED with ERR_TIMEOUT. Receiver MUST emit TELL(error) for errors instead of silence. Mallick & Chebolu Expires 21 July 2026 [Page 32] Internet-Draft µACP January 2026 +-----------------+ | IDLE | +-----------------+ | | (send ASK) v +-----------------+ | WAIT_RESP | +-----------------+ | ^ (recv TELL) | | (timeout; QoS=1) v | +-----------------+ | COMPLETED | +-----------------+ (cleanup) --> returns to IDLE Figure 8: Figure 8: ASK/TELL State Machine 8.2. PING/TELL State Machine PING serves as a minimal liveness check. PING is stateless in that it does NOT create persistent conversation table entries (unlike ASK/ TELL or OBSERVE). The FSM states (IDLE → WAIT_PONG → COMPLETED) represent transient sender-side state only and do not persist beyond the PING/TELL exchange. States: IDLE → (send PING) → WAIT_PONG → (recv TELL or timeout) → COMPLETED. PING SHOULD NOT require OSCORE (unencrypted by default), implementations MAY support OSCORE- protected PING, MUST NOT modify application state, and MUST NOT cause retransmissions on timeout. +--------+ | IDLE | +--------+ | | send PING v +--------------+ | WAIT_PONG | +--------------+ | ^ recv TELL| | timeout v | +--------------+ | COMPLETED | +--------------+ Figure 9: Figure 9: PING/TELL Liveness FSM Mallick & Chebolu Expires 21 July 2026 [Page 33] Internet-Draft µACP January 2026 8.3. OBSERVE Subscription State Machine OBSERVE establishes a long-lived subscription. States: NO_SUB → (recv OBSERVE) → SUBSCRIBED → (event trigger) → NOTIFY (TELL) → (recv CANCEL_SUB) → TERMINATED → cleanup. Subscriptions MUST expire after configured lifetime and MUST enforce resource ceilings (max subscriptions per peer). +----------------+ | NO_SUB | +----------------+ | | (recv OBSERVE) v +----------------+ | SUBSCRIBED | +----------------+ | | (event trigger) v +----------------+ | NOTIFY (TELL) | +----------------+ | | (recv CANCEL_SUB) v +----------------+ | TERMINATED | +----------------+ cleanup → NO_SUB Figure 10: Figure 10: OBSERVE Subscription FSM 8.4. Error-State Transitions Errors MUST transition FSMs to predictable termination states: ERR_MALFORMED → discard, no state; ERR_UNSUPPORTED_TLV → terminate conversation, send error TELL; ERR_TIMEOUT → COMPLETED with error, free resources; ERR_RESOURCE_EXHAUSTED → reject, no new state; OSCORE failure → silent discard, no state update. Mallick & Chebolu Expires 21 July 2026 [Page 34] Internet-Draft µACP January 2026 8.5. Processing Time and Resource Bounds All FSM transitions MUST complete in bounded time and memory. Required limits: conversation table (minimum 64 entries), subscription table (minimum 16 entries), deterministic message buffer sizes (header+1024-byte TLVs+payload), timers without per-message dynamic allocation. Platforms MAY use preallocated memory pools or static tables. 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. 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. Mallick & Chebolu Expires 21 July 2026 [Page 35] Internet-Draft µACP January 2026 9.4. Denial-of-Service and Resource Exhaustion Implementations MUST enforce: maximum active conversations (minimum 64), maximum OBSERVE subscriptions (minimum 16), rate limits on PING and ASK, TLV region size limits (max 1024 bytes), payload size limits (max 65535 bytes), and static/preallocated memory pools. When limits are exceeded, agents MUST return ERR_RESOURCE_EXHAUSTED or silently drop messages. CoAP-level DoS mitigation (exponential backoff, NON vs CON) MUST also be applied. 9.5. Subscription Security OBSERVE and CANCEL_SUB MUST be OSCORE-protected. Subscriptions MUST be bound to an authenticated OSCORE context. Correlation IDs MUST be unpredictable. Subscription deletion MUST require a valid CANCEL_SUB from the same authenticated peer or timeout/resource exhaustion. Agents MUST reject subscription attempts exceeding resource ceilings. 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. *Key Rotation:* OSCORE master secrets SHOULD be rotated periodically to limit exposure from key compromise. Recommended rotation intervals: (1) time-based: every 30-90 days for long-lived deployments, (2) usage-based: after 2^32 messages per security context, (3) event-based: immediately upon suspicion of compromise or after device recovery from sleep. Rotation procedures MUST preserve active conversations and subscriptions where possible. Implementations SHOULD support graceful rotation that allows both old and new contexts during a transition period. 9.8. Side-Channel Attacks Constrained devices implementing µACP may be vulnerable to side- channel attacks including timing analysis, power consumption analysis, and electromagnetic emissions. Implementations SHOULD: Mallick & Chebolu Expires 21 July 2026 [Page 36] Internet-Draft µACP January 2026 * Use constant-time cryptographic operations where possible (e.g., for OSCORE decryption and signature verification). * Minimize observable differences in processing time between valid and invalid messages. * Protect against power analysis by using hardware security modules (HSMs) or software countermeasures for key operations. * Avoid leaking information through error message timing or resource allocation patterns. * Use secure random number generators for Correlation IDs and Sequence IDs to prevent predictability. While complete side-channel resistance may be impractical on severely constrained devices, implementations SHOULD document their threat model and any side-channel mitigations applied. 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) All µACP implementations MUST support: the 64-bit header format; all four verbs (PING, TELL, ASK, OBSERVE); TLV processing with ordering and size limits; OSCORE/CoAP transport binding; Content-Format application/muacp+binary; conversation state for at least 64 active Correlation IDs; subscription state for at least 16 active OBSERVE subscriptions; error-handling and state-machine behavior as defined in this specification. Mallick & Chebolu Expires 21 July 2026 [Page 37] Internet-Draft µACP January 2026 10.2. Constrained Node Profile (CNP) CNP targets microcontroller-class devices (ARM Cortex-M, ESP32). Implementations MUST use static/preallocated buffers, enforce strict resource bounds, minimize logging, and restrict payload sizes. Implementations SHOULD prefer PSK/EDHOC-based OSCORE contexts and disable vendor-specific TLVs. 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. 10.4. Cross-Profile Interoperability INP nodes MUST respect CNP resource ceilings, MUST NOT exceed CNP size limits, and SHOULD apply traffic shaping. CNP nodes MUST ignore unsupported TLVs. Fallback to MIP MUST always be possible. All profile interactions MUST preserve security properties. 10.5. Feature Negotiation Feature discovery uses GET /.well-known/muacp, returning a CBOR map (CDDL: muacp-capabilities = { ? "max-tlv-size" => uint, ; Maximum TLV region size in bytes ? "max-payload-size" => uint, ; Maximum payload size in bytes ? "supported-tlv-types" => [*uint], ; List of supported TLV Type values ? "supported-versions" => [*uint], ; List of supported protocol versions ? "congestion-modes" => [*text], ; Supported congestion control modes ? "conversation-limit" => uint, ; Maximum concurrent conversations ? "subscription-limit" => uint ; Maximum concurrent subscriptions }). Nodes SHOULD cache results until expiration or reboot. If the resource is unavailable, implementations MUST assume default values: max-tlv-size=1024, max- payload-size=65535, supported-versions=[0x00]. 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 21 July 2026 [Page 38] Internet-Draft µACP January 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 (fire-and-forget), Verb = 0 (PING), Flags = 0 00 00 00 # Reserved (24 bits, all zeros) Total: 8 bytes Figure 11: Example 1: PING Message (Hex) No TLVs, no payload. This message may be sent unencrypted over CoAP NON. 11.2. ASK/TELL over OSCORE This example shows an ASK message wrapped in CoAP POST with OSCORE protection, followed by a TELL response. *ASK Request (CoAP POST with OSCORE):* CoAP Header: 44 02 7A 10 # CON, POST, MID=0x7A10 CoAP Options: Uri-Path: "muacp" Content-Format: application/muacp+binary OSCORE Option: [OSCORE flag and partial IV] OSCORE-Protected Payload (encrypted µACP message): [Encrypted µACP header + TLVs + payload] Note: The actual ciphertext depends on OSCORE context and contains the complete µACP message (Header | TLVs | Payload) Figure 12: Example 2a: CoAP Envelope for ASK The unencrypted µACP message structure (before OSCORE encryption) would be: Mallick & Chebolu Expires 21 July 2026 [Page 39] Internet-Draft µACP January 2026 Header (8 bytes): 00 02 # Sequence ID = 0x0002 00 03 # Correlation ID = 0x0003 40 # QoS = 1 (at-least-once), Verb = 2 (ASK), Flags = 0 00 00 00 # Reserved (24 bits, all zeros) TLVs (if present): [TLV Type][Length][Value...] # Sorted by Type Payload (if present): [Application data, e.g., CBOR-encoded action parameters] Figure 13: Example 2a-1: µACP ASK Message Structure (before encryption) *TELL Response (CoAP 2.04 Changed with OSCORE):* CoAP Header: 64 44 7A 10 # ACK, 2.04 Changed, MID=0x7A10 OSCORE-Protected Payload (encrypted µACP TELL): [Encrypted µACP TELL message with same Correlation ID as ASK] Figure 14: Example 2b: CoAP Envelope for TELL The unencrypted µACP TELL message structure (before OSCORE encryption) would be: Header (8 bytes): 00 03 # Sequence ID = 0x0003 00 03 # Correlation ID = 0x0003 (matches ASK) 10 # QoS = 0 (fire-and-forget), Verb = 1 (TELL), Flags = 0 00 00 00 # Reserved (24 bits, all zeros) TLVs: 22 01 00 # Error-Code TLV: Type=0x22, Length=1, Value=0x00 (SUCCESS) [Additional TLVs if present] Payload (if present): [Response data, e.g., CBOR-encoded result] Figure 15: Example 2b-1: µACP TELL Message Structure (before encryption) 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. Mallick & Chebolu Expires 21 July 2026 [Page 40] Internet-Draft µACP January 2026 11.3. Complete OSCORE-Protected Example The following example shows a complete ASK message with placeholder OSCORE ciphertext. In practice, the actual ciphertext depends on the OSCORE security context, partial IV, and key material. CoAP Header (4 bytes): 44 02 7A 10 # CON, POST, MID=0x7A10 CoAP Options: 0B 6D 75 61 63 70 # Uri-Path: "muacp" (option delta=0, length=5) 11 2A # Content-Format: application/muacp+binary (0x2A, TBD) 09 XX # OSCORE Option (flag byte and partial IV) # Note: Actual OSCORE option format depends on context OSCORE-Protected Payload (encrypted µACP message): # The following is a PLACEHOLDER ciphertext for illustration only. # Actual ciphertext will differ based on: # - OSCORE security context (master secret, ID context) # - Partial IV (sender sequence number) # - Associated data (CoAP options) # - Plaintext µACP message D4 83 58 20 A1 B3 C4 99 02 5D 11 0A C8 EE 73 71 4F 52 B0 C8 76 DA 91 22 10 9C 5E 33 81 15 ... # This represents an encrypted µACP ASK message containing: # - Header: Sequence ID=0x0002, Correlation ID=0x0003, QoS=1, Verb=2 # - TLVs: (if any, encrypted) # - Payload: (if any, encrypted) # Receivers MUST decrypt using OSCORE before parsing the µACP message. Figure 16: Example 3: Complete CoAP POST with OSCORE (Placeholder) Implementers MUST refer to [RFC8613] for the complete OSCORE encryption format. The reference implementation repository provides additional examples with specific security contexts for testing purposes. 11.4. Complete End-to-End Example This example demonstrates the complete stack from µACP message encoding through CoAP transport to OSCORE protection, showing how all layers work together. *Step 1: Unencrypted µACP ASK Message* Mallick & Chebolu Expires 21 July 2026 [Page 41] Internet-Draft µACP January 2026 The application creates an ASK message to request sensor data. The unencrypted µACP message structure is: µACP Header (8 bytes): 00 05 # Sequence ID = 0x0005 12 34 # Correlation ID = 0x1234 40 # QoS = 1 (at-least-once), Verb = 2 (ASK), Flags = 0 00 00 00 # Reserved (24 bits, all zeros) TLVs (optional, none in this example): [No TLVs] Payload (optional, CBOR-encoded request): A1 # CBOR map with 1 key-value pair 66 61 63 74 69 6F 6E # "action" (UTF-8 string) 64 72 65 61 64 # "read" (UTF-8 string) Total µACP message: 8 bytes (header) + 0 bytes (TLVs) + 11 bytes (payload) = 19 bytes Figure 17: Example 4a: Unencrypted µACP ASK Message *Step 2: CoAP Envelope (without OSCORE)* For illustration, here is how the message would appear in a CoAP POST without OSCORE (note: this is NOT recommended for production; ASK messages MUST be OSCORE-protected): CoAP Header (4 bytes): 44 02 7A 10 # CON, POST, MID=0x7A10 # Ver=1, T=CON (0), Code=POST (2), MID=0x7A10 CoAP Options: 0B 6D 75 61 63 70 # Option 11 (Uri-Path): "muacp" # Delta=0, Length=5, Value="muacp" 11 2A # Option 17 (Content-Format): 0x2A (TBD, application/muacp+binary) # Delta=6, Length=1, Value=0x2A CoAP Payload (19 bytes): [The complete µACP message from Step 1] 00 05 12 34 40 00 00 00 A1 66 61 63 74 69 6F 6E 64 72 65 61 64 Total CoAP message: 4 (header) + 8 (options) + 19 (payload) = 31 bytes Figure 18: Example 4b: CoAP POST Envelope (Unprotected, for illustration only) *Step 3: OSCORE-Protected CoAP Message* Mallick & Chebolu Expires 21 July 2026 [Page 42] Internet-Draft µACP January 2026 In production, the µACP message MUST be protected by OSCORE. The OSCORE option is added, and the payload (including the µACP message) is encrypted: CoAP Header (4 bytes): 44 02 7A 10 # CON, POST, MID=0x7A10 CoAP Options: 0B 6D 75 61 63 70 # Option 11 (Uri-Path): "muacp" 11 2A # Option 17 (Content-Format): 0x2A (application/muacp+binary) 09 01 02 03 # Option 9 (OSCORE): Flag byte + Partial IV # Flag byte indicates OSCORE protection # Partial IV = 0x010203 (sender sequence number, example) # Note: Actual OSCORE option format depends on context OSCORE-Protected Payload (encrypted µACP message): # The µACP message from Step 1 is encrypted here using OSCORE # The ciphertext includes: µACP Header + TLVs + Payload # Actual ciphertext depends on: # - OSCORE security context (master secret, ID context) # - Partial IV (sender sequence number) # - Associated data (CoAP options) # - Plaintext µACP message (19 bytes from Step 1) [Encrypted ciphertext, length varies based on OSCORE algorithm] # Example placeholder (actual will differ): D4 83 58 20 A1 B3 C4 99 02 5D 11 0A C8 EE 73 71 4F 52 B0 C8 76 DA 91 22 10 9C 5E 33 81 15 ... Processing Flow: 1. Sender creates µACP ASK message (Step 1) 2. Sender wraps in CoAP POST with OSCORE option (Step 3) 3. OSCORE encrypts the µACP message payload 4. CoAP layer transmits the complete message 5. Receiver receives CoAP message 6. Receiver processes OSCORE option and decrypts payload 7. Receiver parses decrypted µACP message 8. Receiver processes ASK and generates TELL response 9. TELL response follows same encryption/transport path in reverse Figure 19: Example 4c: Complete OSCORE-Protected CoAP Message *Key Points:* * The µACP message (Header + TLVs + Payload) is a contiguous byte string that becomes the CoAP payload. Mallick & Chebolu Expires 21 July 2026 [Page 43] Internet-Draft µACP January 2026 * OSCORE encrypts the entire µACP message, not individual components. * The CoAP layer handles transport reliability (CON/NON) based on µACP QoS. * Receivers MUST decrypt using OSCORE before parsing the µACP message structure. * The Correlation ID (0x1234) links the ASK request to its TELL response, independent of CoAP Message IDs. 12. Conformance Tests This section defines the normative conformance tests required to validate µACP implementations. A device or software stack MUST pass all tests in this section to be considered µACP-compliant. Detailed test vectors and a complete test suite are available in the reference implementation repository [MUACP-IMPL]. Implementations MUST pass tests in the following categories: * *Header and TLV Encoding:* Correct parsing of all header fields, TLV ordering, size limits (1024 bytes TLV region, 65535 bytes payload), and handling of unknown TLVs. * *Parser Robustness:* Safe handling of malformed headers, oversized payloads, invalid TLV lengths, and resource exhaustion conditions. * *State-Machine Behavior:* ASK/TELL conversation lifecycle, OBSERVE subscription management, PING statelessness, and deterministic error transitions. * *OSCORE Security:* Authentication and decryption of protected messages, replay window enforcement, context isolation, and downgrade protection. * *Resource Constraints:* Conversation table limits (minimum 64 entries), subscription limits (minimum 16), and bounded processing time. * *Interoperability:* Successful message exchange between independent implementations under the Minimum Interoperability Profile. All test requirements are derived from the normative sections of this specification. Passing these tests validates full compliance with µACP. Mallick & Chebolu Expires 21 July 2026 [Page 44] Internet-Draft µACP January 2026 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, July 2017, . [RFC8613] Selander, G., Mattsson, J., and T. Fossati, "OSCORE: Object Security for Constrained RESTful Environments", RFC 8613, April 2019, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, September 2015, . [RFC7959] Bormann, C. and Z. Shelby, "Blockwise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, August 2016, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . Mallick & Chebolu Expires 21 July 2026 [Page 45] Internet-Draft µACP January 2026 [RFC9528] Selander, G., Mattsson, J., and M. Furuhed, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, March 2024, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . 13.2. Informative References [FIPA-ACL] (FIPA), F. F. I. P. A., "ACL Message Structure Specification", 1997, . [MUACP] Mallick, A. and I. Chebolu, "µACP: A Formal Calculus for Expressive, Resource-Constrained Agent Communication", arXiv 2601.00219, archivePrefix arXiv, primaryClass cs.MA, 2026, . [RFC9147] Rescorla, E., "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022, . [MUACP-IMPL] Mallick, A., "µACP Reference Implementation", GitHub Repository arnab-m1/miuACP, 2025, . [AGENT-SURVEY] Finin, T., Labrou, Y., and J. Mayfield, "A Survey of Agent Communication Languages: Formalisms and Applications", Communications of ACM 40(5), DOI 10.1145/265563.265564, 1997, . [IOT-SURVEY] Palattella, M., Accettura, N., Vilajosana, X., Watteyne, T., Grieco, L., Boggia, G., and M. Dohler, "IoT Protocols for Resource-Constrained Devices: A Comparative Survey", IEEE Communications Surveys & Tutorials 18(3), DOI 10.1109/COMST.2016.2549528, 2016, . Mallick & Chebolu Expires 21 July 2026 [Page 46] Internet-Draft µACP January 2026 [RPL] Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012, . [DDS] Group, O. M., "Data Distribution Service (DDS) for Real- Time Systems, Version 1.4", OMG Document formal/15-04-10, April 2015. [DT] Boschert, S. and R. Rosen, "Digital Twin—The Simulation Aspect", Mechatronic Futures: Challenges and Solutions for Mechatronic Systems and their Designers Chapter 3, Publisher Springer, DOI 10.1007/978-3-319-32156-1_3, 2016, . 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 acknowledge the valuable insights provided by early reviewers, prototype implementers, and colleagues who explored µACP in constrained-device testbeds. Special thanks are extended to members of the open-source contributors who reviewed early drafts of the µACP calculus and provided implementation reports via the project repository. Their feedback led to refinements in the state machines, TLV model, and transport bindings. The authors also thank participants from constrained-network and OSCORE working groups whose discussions influenced the treatment of fragmentation, replay protection, and authentication in this specification. This specification incorporates lessons from deployments in microcontroller-based sensing systems, autonomous control nodes, and large-scale telemetry environments. The authors acknowledge these deployments for motivating the resource model and deterministic behavior guarantees underlying µACP. This work is an independent contribution and does not represent the views of any organization or government entity. Authors' Addresses Mallick & Chebolu Expires 21 July 2026 [Page 47] Internet-Draft µACP January 2026 Arnab Mallick Centre for Development of Advanced Computing (CDAC) Hyderabad India Email: arnabm@cdac.in URI: https://arnab-m1.github.io Indraveni Chebolu Centre for Development of Advanced Computing (CDAC) Hyderabad India Email: indravenik@cdac.in Authors' Addresses 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 21 July 2026 [Page 48]