



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]
