# drafts

name: draft-gaikwad-aps-profile
rev: 00
title: Agent Persistent State Profile
time: 2025-11-30T01:55:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-03T01:55:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774064+00:00
source: ietf
abstract:
  Autonomous agents increasingly maintain durable persistent state
     containing user preferences, embedding vectors, safety logs,
     intermediate reasoning steps, and audit traces.  Today, agent
     frameworks treat storage as a generic file system, while storage
     administrators treat agents as stateless virtual machines.  This
     "layer mismatch" leads to fragility, poor performance, and privacy
     risks.

     The Agent Persistent State (APS) Profile defines an experimental,
     vendor-neutral storage service class for durable agent state.  APS
     emphasizes *compliance*: ensuring that memory associated with a
     specific user or agent identity can be retained, audited, and
     cryptographically erased.  APS also addresses high-frequency small I/
     O, vector index workloads, crash consistency, and Kubernetes/CSI
     [CSI] integration.

     APS introduces a Usage Class ("AgentPersistentState"), a versioned
     PersistentStateLineOfService schema, guidance for container
     orchestration systems, non-normative bindings for Swordfish
     [Swordfish] and Redfish [Redfish], and considerations for multi-
     tenancy.  APS is intended as an Experimental RFC to gather
     implementation feedback prior to any standards-track work.

full_text:
  Network Working Group                                         M. Gaikwad
  Internet-Draft                                           1 December 2025
  Intended status: Experimental                                           
  Expires: 4 June 2026


                       Agent Persistent State Profile
                        draft-gaikwad-aps-profile-00

  Abstract

     Autonomous agents increasingly maintain durable persistent state
     containing user preferences, embedding vectors, safety logs,
     intermediate reasoning steps, and audit traces.  Today, agent
     frameworks treat storage as a generic file system, while storage
     administrators treat agents as stateless virtual machines.  This
     "layer mismatch" leads to fragility, poor performance, and privacy
     risks.

     The Agent Persistent State (APS) Profile defines an experimental,
     vendor-neutral storage service class for durable agent state.  APS
     emphasizes *compliance*: ensuring that memory associated with a
     specific user or agent identity can be retained, audited, and
     cryptographically erased.  APS also addresses high-frequency small I/
     O, vector index workloads, crash consistency, and Kubernetes/CSI
     [CSI] integration.

     APS introduces a Usage Class ("AgentPersistentState"), a versioned
     PersistentStateLineOfService schema, guidance for container
     orchestration systems, non-normative bindings for Swordfish
     [Swordfish] and Redfish [Redfish], and considerations for multi-
     tenancy.  APS is intended as an Experimental RFC to gather
     implementation feedback prior to any standards-track work.

  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."



  Gaikwad                    Expires 4 June 2026                  [Page 1]


  Internet-Draft       Agent Persistent State Profile        December 2025


     This Internet-Draft will expire on 4 June 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Landscape of Agent Frameworks and Persistent State Needs  . .   4
     4.  APS Data Model  . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  PersistentStateLineOfService Schema . . . . . . . . . . . . .   5
       5.1.  IOProfile Behavior (Non-Normative)  . . . . . . . . . . .   7
       5.2.  DurabilityClass Guidance (Non-Normative)  . . . . . . . .   8
     6.  Crash Consistency Requirements  . . . . . . . . . . . . . . .   9
     7.  Privacy, Replication, and Erasure . . . . . . . . . . . . . .   9
       7.1.  Non-Normative Implementation Patterns . . . . . . . . . .  11
     8.  Multi-Tenancy and Volume Scalability  . . . . . . . . . . . .  12
     9.  Block and File Applicability  . . . . . . . . . . . . . . . .  12
     10. Identity and Control Plane Role . . . . . . . . . . . . . . .  12
     11. Kubernetes and CSI Mapping  . . . . . . . . . . . . . . . . .  12
     12. Bindings and Profile Discovery  . . . . . . . . . . . . . . .  13
     13. Versioning and Extensibility  . . . . . . . . . . . . . . . .  14
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
     16. Limitations and Future Work . . . . . . . . . . . . . . . . .  14
     17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       18.1.  Normative References . . . . . . . . . . . . . . . . . .  15
       18.2.  Informative References . . . . . . . . . . . . . . . . .  16
     Appendix A.  Example APS Profiles (Non-Normative) . . . . . . . .  16
       A.1.  APS-Standard (Checkpoint-Oriented)  . . . . . . . . . . .  16
       A.2.  APS-Vector (Embedding-Heavy)  . . . . . . . . . . . . . .  18
       A.3.  APS-Light (BestEffort / ApplicationKey) . . . . . . . . .  20
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22








  Gaikwad                    Expires 4 June 2026                  [Page 2]


  Internet-Draft       Agent Persistent State Profile        December 2025


  1.  Introduction

     AI agents are entering a new operational phase.  Early systems
     focused on prompt engineering and model context.  Modern deployments
     involve several of autonomous agents with distinct identities and
     long-lived state.  Persistent state stores embeddings, preferences,
     memory, safety constraints, and reasoning artifacts that must remain
     durable and compliant across failures.

     Current practice reveals a structural mismatch: agent developers
     assume implicitly that "somewhere" there is a low-latency, compliant
     store; storage administrators assume short-lived, stateless
     applications.  This mismatch leads to data loss, privacy violations,
     tail-latency spikes, and unpredictable behavior.

     Reviewers have observed that this draft is premature but can be
     possibly timely: as deployments scale to thousands of agents, storage
     semantics will become critical infrastructure.  By the time APS
     reaches maturity, the need is expected to be urgent.

     The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this
     document are to be interpreted as described in [RFC2119] and
     [RFC8174] when, and only when, they appear in all capitals.

  2.  Terminology

     Agent:  An autonomous software entity with a distinct identity and a
        multi-session lifecycle.  Agents maintain durable state across
        restarts or container rescheduling, motivating specialized
        persistent storage semantics.

     Persistent State:  Durable data associated with an agent identity,
        including embeddings, preferences, caches, audit logs, and vector
        indexes.

     APS:  Agent Persistent State Profile defined in this document.

     Usage Class:  A tag applied to storage resources indicating the
        expected workload.  This document defines AgentPersistentState.

     Line of Service (LoS):  A structured description of storage behavior.

     Forgetting Policy:  A policy that causes persistent state to be
        deleted or scrubbed according to age, event triggers, or external
        legal/compliance requests (for example, scheduled deletion of
        records older than a given retention period).





  Gaikwad                    Expires 4 June 2026                  [Page 3]


  Internet-Draft       Agent Persistent State Profile        December 2025


  3.  Landscape of Agent Frameworks and Persistent State Needs

     Agent frameworks today implement persistence at the application
     layer, leading to fragility.  The following table summarizes common
     patterns as of 2025; it is illustrative and non-exhaustive.

     +===========+==================+===============+====================+
     |Framework  | Current          |Pain Point     | APS Benefit        |
     |           | Mechanism        |               |                    |
     +===========+==================+===============+====================+
     |LangChain  | Postgres/SQLite/ |Locking, tail  | SmallRandom        |
     |(LangGraph)| Redis            |latency from   | profile; advisory  |
     |           | checkpoints      |high-frequency | locking hints      |
     |           |                  |checkpointing  |                    |
     +-----------+------------------+---------------+--------------------+
     |AutoGPT/   | JSON files and   |Crash can      | CrashConsistency   |
     |BabyAGI    | local workspace  |corrupt state; | and journaling     |
     |           | directories      |agent          | recommendations    |
     |           |                  |"forgets"      |                    |
     |           |                  |everything     |                    |
     +-----------+------------------+---------------+--------------------+
     |LlamaIndex | Vector stores    |Noisy-neighbor | Vector-phase-aware |
     |           | (e.g., HNSW)     |throttling     | profiles; tail-    |
     |           | plus document    |during bulk    | latency awareness  |
     |           | stores           |index I/O      |                    |
     +-----------+------------------+---------------+--------------------+
     |CrewAI     | Local SQLite or  |Multi-agent    | ReplicationScope   |
     |           | similar shared   |persistence    | for AZ/region      |
     |           | state            |fragile across | resilience         |
     |           |                  |failures       |                    |
     +-----------+------------------+---------------+--------------------+

                                    Table 1

     The structural problems across frameworks validate the need for APS:
     requirements for durability, performance, and compliance must move
     downward into the infrastructure layer in a standard form.

  4.  APS Data Model

     APS defines a new Usage Class:

     UsageClass: "AgentPersistentState"








  Gaikwad                    Expires 4 June 2026                  [Page 4]


  Internet-Draft       Agent Persistent State Profile        December 2025


     APS applies to storage abstractions that present block or filesystem
     semantics to agents and their orchestrators, including volumes
     provisioned via Kubernetes PersistentVolumes or surfaces exposed
     through SNIA/DMTF management schemas.  Applying APS directly to pure
     object stores or HTTP-based APIs is outside the scope of the
     normative requirements in this document.

  5.  PersistentStateLineOfService Schema

     The PersistentStateLineOfService structure describes a single APS
     profile.  Fields marked OPTIONAL are advisory and MAY be omitted.  A
     subset of fields constitutes the core APS compliance baseline and
     MUST be present and honored for any profile that claims APS
     compliance.

     PersistentStateLineOfService {

       ApsVersion: string           # e.g., "1.0"

       Id: string
       Name: string
       Purpose: "AgentPersistentState"

       IOProfile: enum {
           SmallRandom,
           MixedRandom,
           MetadataHeavy,
           VectorIndex
       }

       # Optional refinement for vector workloads:
       VectorPhase: enum {
           Ingest,
           Query,
           Mixed
       } OPTIONAL

       CapacityRangeGiB {
         MinGiB: integer
         MaxGiB: integer
         RecommendedStepGiB: integer
       }

       Performance {
         MinIOPS: integer
         MaxLatencyMsP95: number
         MaxLatencyMsP99: number




  Gaikwad                    Expires 4 June 2026                  [Page 5]


  Internet-Draft       Agent Persistent State Profile        December 2025


         RecommendedIOSizeKiB: integer
             # Embeddings and vectors may use 16-64KiB I/O sizes
       }

       Durability {
         DurabilityClass: enum { Standard, High, VeryHigh }
         ReplicationScope: enum { LocalAZ, MultiAZ, MultiRegion }
       }

       CrashConsistency {
         RequiresWriteOrdering: boolean
       }

       Retention {
         RetentionDays: integer
         ForgettingPolicySupported: boolean
       }

       Privacy {
         ContainsUserFacingDataExpected: boolean

         MinDeletionSemantics: enum {
           BestEffort,
           CryptographicErase,
           MediaScrub
         }

         ErasureScope: enum {
           Volume,          # Whole LUN / filesystem
           FilesystemTree,  # Directory / inode subtree
           ObjectPrefix,    # Prefix subset for object-backed systems
           ApplicationKey   # Crypto handled above storage
         }

         MaxEraseLatencyHours: integer
       }

       ConcurrencyHints {        # OPTIONAL, advisory only
         AdvisoryLockingSupported: boolean
       }
     }

     The core APS compliance baseline consists of the following fields,
     which *MUST* be present and reflect behavior meaningful to the
     abstraction being exposed:

     *  IOProfile




  Gaikwad                    Expires 4 June 2026                  [Page 6]


  Internet-Draft       Agent Persistent State Profile        December 2025


     *  CapacityRangeGiB (all members)

     *  Performance.MinIOPS

     *  Performance.MaxLatencyMsP95

     *  Durability.DurabilityClass

     *  Durability.ReplicationScope

     *  CrashConsistency.RequiresWriteOrdering

     *  Retention.RetentionDays

     *  Retention.ForgettingPolicySupported

     *  Privacy.MinDeletionSemantics

     *  Privacy.ErasureScope

     *  Privacy.MaxEraseLatencyHours

     Providers *MUST NOT* advertise an APS-compliant profile that omits or
     ignores these core fields.  Additional fields MAY be omitted if they
     are not meaningful for the abstraction (for example, advisory locking
     hints on raw block volumes).

     In environments that provision storage in terms of throughput (for
     example, MiB/s) rather than IOPS, implementers MAY derive an
     effective MinIOPS from documented throughput and average I/O size.
     One reasonable approach is:

     MinIOPS ≈ (ThroughputMiBps * 1024) / RecommendedIOSizeKiB

     APS does not constrain how this effective value is calculated, but
     providers SHOULD document the relationship between throughput and
     MinIOPS.

  5.1.  IOProfile Behavior (Non-Normative)

     IOProfile values describe expected workload envelopes.  This section
     is non-normative guidance for implementers and consumers.  APS
     profiles are provisioned at volume-creation time, while agent
     workloads may evolve dynamically.  Consumers SHOULD treat IOProfile
     as a coarse signal for provisioning decisions, not a real-time
     optimization mechanism.





  Gaikwad                    Expires 4 June 2026                  [Page 7]


  Internet-Draft       Agent Persistent State Profile        December 2025


     Some IOProfile values (for example, VectorIndex) include an OPTIONAL
     VectorPhase field.  VectorPhase refines expected workload behavior
     but does not override the baseline characteristics of the underlying
     IOProfile.

     SmallRandom:  Dominated by 4-16 KiB random reads and writes, typical
        for agent checkpointing, key-value state blocks, preference
        updates, and log fragments.  Storage SHOULD provision enough low-
        latency IOPS to avoid tail-latency amplification during frequent
        agent state flushes.

     MetadataHeavy:  Characterized by high rates of metadata changes
        (directory operations, inode updates, journal commits).  Suitable
        for agents producing many small files or maintaining structured
        reasoning traces.  Storage SHOULD support efficient metadata
        journaling and crash-consistent mounts.

     MixedRandom:  A balanced workload combining small random I/O with
        occasional larger sequential batches.  Appropriate when agents
        interleave checkpointing, replay logs, and batched vector updates.

     VectorIndex:  Represents workloads dominated by embedding ingestion,
        vector construction, nearest-neighbor search, or index compaction.
        Providers SHOULD document which vector phase(s) their
        configuration optimizes.  The OPTIONAL VectorPhase enum has the
        following meanings:

        *  Ingest — optimized for high-throughput sequential or semi-
           sequential writes during bulk embedding generation, HNSW edge
           linking, or batch import.

        *  Query — optimized for low-latency random reads and small-range
           fetches typical of approximate nearest neighbor search
           workloads such as DiskANN-style index queries.

        *  Mixed — balanced for deployments where ingest, query, and
           compaction phases interleave or shift over time.  Providers
           SHOULD state which tradeoffs are made (write-friendly vs. read-
           friendly).

        Because vector workloads are phase-shifting, consumers SHOULD NOT
        assume that a single VectorPhase value can optimize all stages of
        the index lifecycle.

  5.2.  DurabilityClass Guidance (Non-Normative)

     DurabilityClass values are intentionally abstract.  As non-normative
     guidance, providers might interpret them as:



  Gaikwad                    Expires 4 June 2026                  [Page 8]


  Internet-Draft       Agent Persistent State Profile        December 2025


     *  Standard: durability comparable to typical single-region cloud
        block volumes.

     *  High: durability comparable to replicated volumes or erasure-coded
        storage (for example, multiple independent copies within a region
        or across zones).

     *  VeryHigh: durability approaching or exceeding widely replicated
        object storage classes.

     Exact "nines" targets are out of scope and MAY vary by provider.

  6.  Crash Consistency Requirements

     All APS-compliant resources *MUST* provide metadata consistency after
     power loss or crash.  For the purposes of this document, metadata
     consistency means that the filesystem or block namespace remains
     mountable without manual repair tools and that directory and inode
     structures do not exhibit silent corruption that would cause loss of
     reachability for existing files.

     The RequiresWriteOrdering flag indicates that applications rely on
     storage honoring write ordering or barrier semantics (for example,
     flush/fence operations) to maintain write-ahead logging or similar
     invariants.  When true, providers *MUST* document the ordering
     guarantees and the mechanisms available to applications.

     Implementations supporting high-frequency agent checkpointing SHOULD
     document whether O_DIRECT, O_SYNC, or equivalent durability hints are
     honored by the underlying storage stack.

     Applications are expected to rely on standard filesystem atomic
     operations (such as POSIX rename) for batched updates.  APS does not
     define or negotiate additional transactional semantics.

  7.  Privacy, Replication, and Erasure

     The MinDeletionSemantics, ErasureScope, and MaxEraseLatencyHours
     fields describe the minimum deletion and erasure behavior for data
     stored under the profile.  When combined with ReplicationScope,
     providers *MUST* interpret these fields as applying to all replicas
     of the primary data in scope.

     The MaxEraseLatencyHours field *MUST* be a strictly positive integer.
     A value of zero is reserved and MUST NOT be used.  Deployments that
     effectively provide synchronous erasure MAY represent this with a
     small non-zero value and SHOULD document the expected behavior.




  Gaikwad                    Expires 4 June 2026                  [Page 9]


  Internet-Draft       Agent Persistent State Profile        December 2025


     For example, if MinDeletionSemantics is set to CryptographicErase and
     ReplicationScope is MultiRegion, then cryptographic erasure of all
     regions *MUST* complete within MaxEraseLatencyHours, unless the
     provisioning request explicitly accepts weaker behavior.

     APS describes behavior for primary data under the profile.
     Snapshots, backups, and other disaster recovery mechanisms MAY retain
     older copies of data beyond MaxEraseLatencyHours.  End-to-end
     compliance for such copies is outside the scope of this document and
     MUST be addressed by higher-level data lifecycle policies.

     The ErasureScope field indicates the granularity at which
     cryptographic or destructive erase is expected to act:

     *  Volume: erasure is performed at the level of a whole volume, LUN,
        or filesystem.  Destroying the associated key or media affects all
        data hosted on that volume.

     *  FilesystemTree: erasure is performed at the level of a directory
        or inode subtree.  For example, implementations MAY use per-
        directory filesystem encryption mechanisms (such as Linux fscrypt)
        where destroying the key renders only that subtree unreadable.

     *  ObjectPrefix: erasure is scoped to a subset of objects under a
        prefix or bucket namespace.  This is primarily informative for
        object-backed systems that expose filesystem views or may be the
        basis of future APS profiles for object-native agent state.
        Profiles that target purely block or filesystem abstractions MUST
        NOT use ObjectPrefix.

     *  ApplicationKey: cryptographic erase is implemented above the
        storage layer.  The storage system provides generic persistence,
        and an application, sidecar, or agent runtime manages keys and
        performs crypto-shredding by destroying them.

     When MinDeletionSemantics is set to CryptographicErase and
     ErasureScope is Volume, FilesystemTree, or ObjectPrefix, the storage
     or filesystem layer is responsible for ensuring that destruction of
     the relevant cryptographic material renders the targeted scope
     unreadable without affecting adjacent scopes beyond what is
     documented.

     When MinDeletionSemantics is CryptographicErase and ErasureScope is
     ApplicationKey, the storage layer is not aware of per-agent keys.  In
     this case, APS simply records that cryptographic erase is expected to
     be achieved via application- or sidecar-managed key lifecycles.
     Operators MUST NOT interpret such a profile as evidence of storage-
     controller-level key separation.



  Gaikwad                    Expires 4 June 2026                 [Page 10]


  Internet-Draft       Agent Persistent State Profile        December 2025


     Storage backing APS MAY be multi-tenant.  Providers *SHOULD* document
     whether cryptographic erase is implemented via volume-level keys,
     per-tenant keys, filesystem-level keys, or other mechanisms, and what
     the effective erase granularity is.

     There is intentionally no single mandatory minimum for
     MinDeletionSemantics.  A provider that cannot implement
     CryptographicErase MAY still advertise an APS profile using
     BestEffort semantics, but such profiles are generally unsuitable for
     compliance-critical deployments and SHOULD be clearly documented as
     such.

  7.1.  Non-Normative Implementation Patterns

     The following patterns illustrate how different implementations might
     realize finer-grained erasure scopes in practice:

     FilesystemTree via fscrypt:  A CSI driver or agent runtime mounts a
        shared volume and creates per-agent directories (for example,
        /data/agent-a, /data/agent-b).  Each directory is protected with a
        distinct filesystem encryption key (such as a Linux fscrypt
        policy).  To erase a specific agent's data, the orchestrator
        destroys that directory's key in a KMS.  The APS profile would set
        ErasureScope=FilesystemTree and
        MinDeletionSemantics=CryptographicErase.

     Sub-volume Constructs (vVols, Qtrees):  Enterprise arrays that
        support lightweight logical containers inside a physical pool can
        assign unique keys to those constructs.  An APS profile might then
        represent each logical container as having ErasureScope=Volume
        from the perspective of the host filesystem, while the array
        internally multiplexes many such logical volumes.

     ApplicationKey Sidecar:  When the underlying storage provides only
        coarse-grained encryption, an application or sidecar may intercept
        I/O, encrypt data with per-agent keys, and write to a shared
        volume.  Destroying the per-agent key achieves cryptographic erase
        for that agent's data.  An APS profile for such a deployment would
        use ErasureScope=ApplicationKey.

     These patterns are examples only.  APS does not mandate a particular
     implementation, but seeks to make the erasure scope explicit so
     operators and frameworks understand where compliance responsibilities
     sit.







  Gaikwad                    Expires 4 June 2026                 [Page 11]


  Internet-Draft       Agent Persistent State Profile        December 2025


  8.  Multi-Tenancy and Volume Scalability

     APS does *not* require a 1:1 mapping between agents and volumes.
     Volume-per-agent designs risk exhausting controller limits at scale.
     Instead, APS is intended to describe the behavior of shared storage
     classes that MAY host many agents.

     Implementations are encouraged to separate cryptographic and policy
     granularity from volume granularity.  For example, a single APS
     volume may host multiple agents while still satisfying erasure and
     isolation requirements at a filesystem-tree or application-key level,
     as indicated by ErasureScope.

  9.  Block and File Applicability

     APS is intended for storage abstractions that present block or
     filesystem semantics to agents.  Some fields are primarily relevant
     to block devices (for example, RecommendedIOSizeKiB), and others are
     primarily relevant to filesystems (for example,
     AdvisoryLockingSupported).

     Providers *MAY* omit non-core fields that are not meaningful for the
     abstraction they expose.  Core fields listed in Section Section 5
     MUST be honored.

  10.  Identity and Control Plane Role

     APS discusses persistent state in terms of "agent identity", but does
     not require storage protocols (for example, NVMe, iSCSI, NFS) to
     carry per-agent identifiers on individual I/O operations.  In most
     deployments, storage controllers see host or initiator identifiers,
     not agent IDs.

     Identity mapping and scoping are therefore the responsibility of the
     control plane and agent platform (for example, an orchestrator that
     binds particular agents or pods to specific volumes, filesystems, or
     filesystem subtrees).  APS describes the properties of those storage
     constructs; it does not define new protocol headers or on-the-wire
     identity fields.

  11.  Kubernetes and CSI Mapping

     Kubernetes and CSI are expected to be primary consumers of APS.  This
     section provides guidance for CSI driver integrations.  It is
     informative for the CSI specification itself.






  Gaikwad                    Expires 4 June 2026                 [Page 12]


  Internet-Draft       Agent Persistent State Profile        December 2025


     A CSI driver that claims to be "APS-aware" *MUST* support a
     documented mechanism to pass APS hints from higher-level
     configuration (for example, StorageClass parameters) to backend
     profiles.  One possible mapping is:

     *  parameters["aps.storage.k8s.io/ioProfile"] → IOProfile

     *  parameters["aps.storage.k8s.io/privacy.minDeletion"] →
        MinDeletionSemantics

     *  parameters["aps.storage.k8s.io/privacy.erasureScope"] →
        ErasureScope

     *  parameters["aps.storage.k8s.io/privacy.maxEraseHours"] →
        MaxEraseLatencyHours

     *  parameters["aps.storage.k8s.io/durability.replicationScope"] →
        ReplicationScope

     The recommended "aps.storage.k8s.io/" prefix reduces the likelihood
     of collisions with vendor-defined parameters.  Alternative key names
     MAY be used if they are clearly documented by the CSI driver and its
     consumers.

  12.  Bindings and Profile Discovery

     APS MAY be expressed in existing schemas as follows:

     Swordfish:  Implementations expressing APS profiles in Swordfish
        SHOULD use ClassOfService with UsageClass="AgentPersistentState",
        and attach a vendor-defined or standardized
        PersistentStateLineOfService extension carrying APS fields.
        Discovery of available APS profiles then follows Swordfish
        mechanisms for enumerating lines of service.

     Redfish:  Implementations exposing APS via Redfish SHOULD use OEM
        extensions on StorageService and Volume resources to represent
        PersistentStateLineOfService fields, together with
        UsageClass="AgentPersistentState" where applicable.  Discovery
        would use Redfish resource enumeration.

     CSI:  APS hints MAY be conveyed through StorageClass parameters by
        convention, as described in Section Section 11.  A higher-level
        control plane (for example, a storage operator) is expected to map
        available backend profiles to supported StorageClasses.






  Gaikwad                    Expires 4 June 2026                 [Page 13]


  Internet-Draft       Agent Persistent State Profile        December 2025


     The details of profile discovery are intentionally left to existing
     management and orchestration mechanisms; APS focuses on the shape and
     semantics of individual profiles.

     Future work MAY explore bindings for object-native stores, for
     example, using object prefixes and S3 Select-like mechanisms to host
     agent state directly in object storage, based on the ObjectPrefix
     erasure scope.

  13.  Versioning and Extensibility

     The ApsVersion field in PersistentStateLineOfService identifies the
     APS version the profile conforms to (for example, "1.0").

     Future versions of APS *MAY* add new OPTIONAL fields.  Profiles that
     set ApsVersion to "1.x" MUST remain backward compatible for all
     fields defined in version 1.0, and consumers *MUST* ignore unknown
     fields rather than treating them as errors.

  14.  Security Considerations

     APS-compliant resources are expected to host sensitive agent state,
     including user-identifiable data and behavior-derived embeddings.
     Implementations *SHOULD* support encryption at rest, strong identity
     scoping in the control plane, and cryptographic erasure according to
     policy.

  15.  Privacy Considerations

     Enterprises may need to demonstrate that agent memory for a specific
     user was deleted in accordance with regulation (for example, GDPR).
     APS provides explicit deletion semantics, an erasure scope, and a
     latency bound to support such compliance, but implementation details
     and audits remain the responsibility of the operator and any higher-
     level governance systems.

  16.  Limitations and Future Work

     This document does not define a conformance test suite or reference
     implementation.  Future work MAY include tests for APS-aware CSI
     drivers, managed vector databases, and storage arrays.

     APS does not provide guidance on how agents should degrade gracefully
     when APS-compliant storage is unavailable.  Agent frameworks are
     responsible for fallback behavior (for example, operating in a
     stateless mode).





  Gaikwad                    Expires 4 June 2026                 [Page 14]


  Internet-Draft       Agent Persistent State Profile        December 2025


     APS does not model cost trade-offs explicitly.  Operators are
     expected to balance erase latency, replication scope, erasure scope,
     and storage-class cost.

     APS does not attempt to model differential privacy, federated
     learning, or higher-level alignment techniques.  Those may rely on
     APS semantics but are outside the scope of this profile.

     A normative JSON Schema for PersistentStateLineOfService is intended
     for a future revision to enable automated validation and tooling.

  17.  IANA Considerations

     This document requests that IANA create an "APS UsageClass and
     Profile Registry" containing the following initial values:

     UsageClass:
        *  AgentPersistentState

     IOProfile:
        *  SmallRandom

        *  MixedRandom

        *  MetadataHeavy

        *  VectorIndex

     ErasureScope:
        *  Volume

        *  FilesystemTree

        *  ObjectPrefix

        *  ApplicationKey

     No additional IANA actions are required by this document.

  18.  References

  18.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>.





  Gaikwad                    Expires 4 June 2026                 [Page 15]


  Internet-Draft       Agent Persistent State Profile        December 2025


     [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>.

  18.2.  Informative References

     [Swordfish]
                SNIA, "Swordfish Storage Management Specification", 2024.

     [Redfish]  DMTF, "Redfish Scalable Platforms Management API", 2024.

     [CSI]      Kubernetes Community, "Container Storage Interface (CSI)",
                2024.

  Appendix A.  Example APS Profiles (Non-Normative)

     This appendix provides three example PersistentStateLineOfService
     instances.  These are illustrative and non-normative.  They are
     intended to show how capacity, performance, durability, and privacy
     settings can be combined for common agent scenarios.

  A.1.  APS-Standard (Checkpoint-Oriented)

     APS-Standard is intended for general agent checkpointing and short-
     to medium-term memory.  It favors small random I/O, moderate
     capacity, and relatively tight tail latency so that frequent state
     saves do not break conversational responsiveness.  The 8 KiB
     recommended I/O size and 3000 IOPS target are representative of a
     busy checkpointing workload where many agents periodically flush
     small state blobs or logs.





















  Gaikwad                    Expires 4 June 2026                 [Page 16]


  Internet-Draft       Agent Persistent State Profile        December 2025


     PersistentStateLineOfService {
       ApsVersion: "1.0"
       Id: "aps-standard-1"
       Name: "APS-Standard-Checkpoint"
       Purpose: "AgentPersistentState"

       IOProfile: SmallRandom

       CapacityRangeGiB {
         MinGiB: 5
         MaxGiB: 100
         RecommendedStepGiB: 5
       }

       Performance {
         MinIOPS: 3000
         MaxLatencyMsP95: 20
         MaxLatencyMsP99: 50
         RecommendedIOSizeKiB: 8
       }

       Durability {
         DurabilityClass: High
         ReplicationScope: MultiAZ
       }

       CrashConsistency {
         RequiresWriteOrdering: true
       }

       Retention {
         RetentionDays: 30
         ForgettingPolicySupported: true
       }

       Privacy {
         ContainsUserFacingDataExpected: true
         MinDeletionSemantics: CryptographicErase
         ErasureScope: Volume
         MaxEraseLatencyHours: 24
       }

       ConcurrencyHints {
         AdvisoryLockingSupported: true
       }
     }





  Gaikwad                    Expires 4 June 2026                 [Page 17]


  Internet-Draft       Agent Persistent State Profile        December 2025


  A.2.  APS-Vector (Embedding-Heavy)

     APS-Vector is intended for embedding-heavy and index-heavy agent
     workloads.  It assumes larger capacity, higher IOPS, and a
     RecommendedIOSizeKiB of 32 KiB to reflect typical vector segment
     sizes during scan-oriented operations.  It disables advisory locking
     hints because many vector index implementations use append-only or
     copy-on-write designs and do not rely on traditional filesystem
     locking semantics for concurrency control.  The VectorPhase field is
     set to indicate that this profile is tuned primarily for read-heavy
     query traffic.








































  Gaikwad                    Expires 4 June 2026                 [Page 18]


  Internet-Draft       Agent Persistent State Profile        December 2025


     PersistentStateLineOfService {
       ApsVersion: "1.0"
       Id: "aps-vector-1"
       Name: "APS-Vector-Index"
       Purpose: "AgentPersistentState"

       IOProfile: VectorIndex
       VectorPhase: Query

       CapacityRangeGiB {
         MinGiB: 50
         MaxGiB: 2000
         RecommendedStepGiB: 50
       }

       Performance {
         MinIOPS: 8000
         MaxLatencyMsP95: 25
         MaxLatencyMsP99: 80
         RecommendedIOSizeKiB: 32
       }

       Durability {
         DurabilityClass: VeryHigh
         ReplicationScope: MultiRegion
       }

       CrashConsistency {
         RequiresWriteOrdering: true
       }

       Retention {
         RetentionDays: 90
         ForgettingPolicySupported: true
       }

       Privacy {
         ContainsUserFacingDataExpected: true
         MinDeletionSemantics: CryptographicErase
         ErasureScope: FilesystemTree
         MaxEraseLatencyHours: 48
       }

       ConcurrencyHints {
         AdvisoryLockingSupported: false
       }
     }




  Gaikwad                    Expires 4 June 2026                 [Page 19]


  Internet-Draft       Agent Persistent State Profile        December 2025


  A.3.  APS-Light (BestEffort / ApplicationKey)

     APS-Light illustrates deployments that rely on application-managed
     keys or do not require strict retention or erase guarantees.
     Suitable for experimentation, low-risk workloads, or sidecar-based
     encryption designs where the storage layer itself does not enforce
     cryptographic erase.












































  Gaikwad                    Expires 4 June 2026                 [Page 20]


  Internet-Draft       Agent Persistent State Profile        December 2025


     PersistentStateLineOfService {
       ApsVersion: "1.0"
       Id: "aps-light-1"
       Name: "APS-Light-Experiment"
       Purpose: "AgentPersistentState"

       IOProfile: MixedRandom

       CapacityRangeGiB {
         MinGiB: 1
         MaxGiB: 200
         RecommendedStepGiB: 1
       }

       Performance {
         MinIOPS: 500
         MaxLatencyMsP95: 40
         MaxLatencyMsP99: 120
         RecommendedIOSizeKiB: 4
       }

       Durability {
         DurabilityClass: Standard
         ReplicationScope: LocalAZ
       }

       CrashConsistency {
         RequiresWriteOrdering: false
       }

       Retention {
         RetentionDays: 7
         ForgettingPolicySupported: false
       }

       Privacy {
         ContainsUserFacingDataExpected: false
         MinDeletionSemantics: BestEffort
         ErasureScope: ApplicationKey
         MaxEraseLatencyHours: 24
       }

       ConcurrencyHints {
         AdvisoryLockingSupported: false
       }
     }





  Gaikwad                    Expires 4 June 2026                 [Page 21]


  Internet-Draft       Agent Persistent State Profile        December 2025


  Author's Address

     Madhava Gaikwad
     Email: gaikwad.madhav@gmail.com















































  Gaikwad                    Expires 4 June 2026                 [Page 22]


name: draft-williams-http-bearer-extension
rev: 00
title: HTTP Bearer Auth Method Extensions
time: 2025-12-03T19:18:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-06T19:18:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774068+00:00
source: ietf
abstract:
  This document specifies an improved HTTP 401 and 407 flow for Bearer
     authentication where user-agents (or client applications) can
     automatically fetch requested tokens from a Security Token Service
     (STS).  A fallback to an OpenID Connect (OIDC) redirect flow is
     included.

     This improved 401/407 Bearer flow, when used, elides the need for
     Proof Key for Code Exchange (PKCE) and does not impose on application
     Universal Resource Identifier (URI) query parameter design.  As well
     this extension allows for user-agent caching of tokens.

full_text:
  HTTP                                                         N. Williams
  Internet-Draft                                           3 December 2025
  Intended status: Standards Track                                        
  Expires: 6 June 2026


                     HTTP Bearer Auth Method Extensions
                  draft-williams-http-bearer-extension-00

  Abstract

     This document specifies an improved HTTP 401 and 407 flow for Bearer
     authentication where user-agents (or client applications) can
     automatically fetch requested tokens from a Security Token Service
     (STS).  A fallback to an OpenID Connect (OIDC) redirect flow is
     included.

     This improved 401/407 Bearer flow, when used, elides the need for
     Proof Key for Code Exchange (PKCE) and does not impose on application
     Universal Resource Identifier (URI) query parameter design.  As well
     this extension allows for user-agent caching of tokens.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-williams-http-bearer-
     extension/.

     Discussion of this document takes place on the NETWORK Working Group
     mailing list (mailto:ietf-http-wg@w3.org), which is archived at
     https://lists.w3.org/Archives/Public/ietf-http-wg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/nicowilliams/http-bearer-ext.

  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/.





  Williams                   Expires 6 June 2026                  [Page 1]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     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 6 June 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
         1.1.1.  Automation of Bearer  . . . . . . . . . . . . . . . .   3
         1.1.2.  Making OAuth, OIDC, and SAML not Camp on URI
                 Design  . . . . . . . . . . . . . . . . . . . . . . .   4
         1.1.3.  Reducing Load on Token Issuers by Facilitating Token
                 Caching . . . . . . . . . . . . . . . . . . . . . . .   4
         1.1.4.  Enabling the Use of Bearer for Proxy Auth . . . . . .   4
       1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
     2.  Extended 401 WWW-Authenticate: Bearer Flow  . . . . . . . . .   5
       2.1.  Example flow  . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.  Server Response Type Selection  . . . . . . . . . . . . .   8
       2.3.  User-Agent Use  . . . . . . . . . . . . . . . . . . . . .   9
       2.4.  Client Application Use  . . . . . . . . . . . . . . . . .   9
       2.5.  Mapping realm to issuer . . . . . . . . . . . . . . . . .   9
       2.6.  Token Caching . . . . . . . . . . . . . . . . . . . . . .  10
     3.  Extended Redirect Flow  . . . . . . . . . . . . . . . . . . .  10
     4.  Negotiation of 401 vs Redirect Flows  . . . . . . . . . . . .  11
     5.  Local Policy  . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.  New fields  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.  New auth-params . . . . . . . . . . . . . . . . . . . . . . .  12
     8.  Wider Applicability: Negotiate Auth w/o GSS or Kerberos
             Implementations!  . . . . . . . . . . . . . . . . . . . .  12
     9.  Single Sign-On  . . . . . . . . . . . . . . . . . . . . . . .  13
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13



  Williams                   Expires 6 June 2026                  [Page 2]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


       10.1.  HTTP Field Registrations . . . . . . . . . . . . . . . .  13
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
       12.2.  Informative References . . . . . . . . . . . . . . . . .  15
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction

     HTTP [HTTP] has a number of authentication methods available,
     including Bearer [BEARER] that uses OAuth 2.0 [OAUTH2], which is the
     subject of this document.  Some HTTP authentication methods, like
     Negotiate [NEGOTIATE], allow the user-agent to automatically respond
     to a 401 or 407 status response when possible by creating a token
     locally using the GSS-API [GSSAPI], typically using Kerberos
     [KERBEROS].  However, the Bearer method effectively requires that the
     client application respond to the 401/407 authentication request
     rather than the HTTP user-agent, and it provides little metadata that
     either can use to figure out how to obtain a Bearer token.  Today an
     OAuth application just has to know how to obtain the Bearer token,
     and has to be configured appropriately, and this greatly limits the
     applicability of the 401/407 flows.

     Note that we will mostly refer to 401 flows here, but everything that
     applies to 401 flows also applies to 407 flows.

     Here we specify extension auth-params to the 401 WWW-Authenticate:
     Bearer HTTP response so that either the client application or the
     user-agent can figure out how to obtain the requested token after
     applying local policy.

     As well we provide a way to improve the OIDC redirect flow to make
     use of this extension where possible, and this provides a migration
     path to a world where URI q-param camping and PKCE [PKCE] and code-
     to-token conversions are no-longer needed just to use OAuth 2.x.

     The extended Bearer 401 flow presented here is a glorified redirect
     that avoids the need for camping on the application's URI q-params.

  1.1.  Motivation

  1.1.1.  Automation of Bearer

     In general it would be better for user-agents to know how to execute
     HTTP auth methods, and generally they do, except for Bearer, where
     they often only know when the application has provided the user-agent
     with a token ahead of it being needed.



  Williams                   Expires 6 June 2026                  [Page 3]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     Some user-agents, such as for example (at the time of this writing)
     curl, do not support redirect flows quite well enough.  This causes
     users to work around these limitations by, for example, scripting
     around these user-agents' limitations.

     In order to make such user-agents automatically fetch tokens we want
     improve the 401 Bearer flow so that the user-agent can learn where
     and how to acquire a token.  This necessitates OPTIONAL local policy,
     but only because some such user-agents do not enable redirect
     following by default, whereas browser-type user-agents chase
     redirects by default.

  1.1.2.  Making OAuth, OIDC, and SAML not Camp on URI Design

     Besides automatic Bearer token fetching in tools such as curl there
     is also the desire to not impose on application URI design.

  1.1.3.  Reducing Load on Token Issuers by Facilitating Token Caching

     By making auth requests a first-class operation (by using 401 where
     possible instead of a redirect) and the user-agent responsible for
     executing auth request we make it possible for the user-agent to
     cache tokens during their remaining lifetime.  This allows for a
     significant reduction in issuer load in some cases.

     The token cache can be in-memory or stored in local storage (e.g., a
     local filesystem) for sharing among the user's non-browser
     applications, further reducing issuer load.

  1.1.4.  Enabling the Use of Bearer for Proxy Auth

     Currently Bearer cannot be used for proxy auth (407) in browsers as
     browsers do not know how to fetch the required token.

     For many users this means being stuck with the New Technology LAN
     Manager (NTLM) mechanism via Negotiate [NEGOTIATE], or Kerberos
     [KERBEROS] via Negotiate, or SCRAM [SCRAM].  But NTLM is weak and
     dangerous, Kerberos is often seen as legacy that one should be able
     to avoid, and SCRAM requires passwords and thus is not a single-sign-
     on solution.

     Maintaining infrastructure for many auth methods is a burden on
     operators.  Operators would like to reduce that burden.  And many
     operators want to be able to use OAuth as the primary or only auth
     method.  But there is a long tail of work to do to make OAuth a
     replacement for Kerberos.  Proxy auth is part of that long tail, thus
     by eliminating that part of the long tail we make the tail shorter.




  Williams                   Expires 6 June 2026                  [Page 4]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


  1.2.  Notational Conventions

     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, and only when, they appear in all
     capitals, as shown here.

  2.  Extended 401 WWW-Authenticate: Bearer Flow

     Currently the following auth-params are supported in a 401 response
     with WWW-Authenticate=Bearer:

     *  realm

     *  scope

     *  error

     *  error_description

     *  error_uri

     We add the following additional, OPTIONAL auth-params:

     *  issuer with a URI as a value

     *  server_token_type with a token type Universal Resource Name (URN)
        as a value

     *  server_token with a token to be forwarded to the issuer by the
        user-agent or client application

     *  state with a "state" value -- this corresponds to the OIDC state
        q-param in a redirect to the OpenID provider

     The issuer parameter allows the user-agent or client application to
     discover the URI of a Security Token Service (STS) to visit to get a
     token.  Though of course a user-agent or client application could map
     a realm auth-param value to an STS URI, or even the realm could
     consist of an issuer URI, however by having an auth-param intended to
     carry an issuer URI we avoid ambiguities about the meaning of
     "realm".








  Williams                   Expires 6 June 2026                  [Page 5]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     The server_token auth-param allows the server to pass a cryptographic
     token to the issuer via the user-agent's or client application's
     subsequent request to the issuer.  The user-agent or client
     application will set a new requested header Token-Request-Pref to the
     value in the 401 response's server_token auth-param.

     Essentially this functions like a redirect response, but with a 401
     status code and with the Server-Token and Server-Token-Type carrying
     the token and token type from the server_token and server_token_type
     auth-params respectively, if present.

     The user-agent and/or client application MUST apply local policy,
     where any is set, as to whether to execute a token request against
     the requrested issuer.

     When making the token request to the issuer the user-agent or client
     application MUST also set the following fields:

     *  Referer, as if the 401 response had been a redirect

     *  a new Token-Request header to indicate that the request is in
        response to an extended Bearer token request by the server

     *  Token-Request-Token, set to the token from the server_token auth-
        param, if present

     When making the token request to the issuer the user-agent or client
     application SHOULD also set the following fields:

     *  Token-Request-Auth-Params, with all auth-params other than the
        issuer and server_token parameters.

     When the STS supports this feature then a successful response MUST be
     a 200 status code response if successful rather than a 3xx redirect
     response, with a field Location field set to the value of the Token-
     Request-URI field (if present) from the request to the STS and with
     the issued token in the response body.

     The value forms of these headers are specified below (Section 6).

  2.1.  Example flow

     Request to https://some.origin.example/some/resource:

     GET /some/resource HTTP/1.1
     Host: some.origin.example





  Williams                   Expires 6 June 2026                  [Page 6]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     Here the user-agent or client MAY use a new field, Token-Request-
     Pref, to indicate a preference for 401 or 3xx flows.  Not specifying
     a preference allows the server to honor that preference instead of
     having to guess it from fingerprinting the user-agent.

     The server may not support this feature, in which case it will either
     use an unextended 401 WWW-Authenticate: bearer or a 3xx OIDC redirect
     flow.  Here we show the server responding with an extended 401 WWW-
     Authenticate: Bearer:

     HTTP/1.1 401 Authentication required
     WWW-Authenticate: Negotiate
     WWW-Authenticate: Bearer issuer=https://iam.foo.example/v1/token
             scope=read:some/resource
             server_token=Bearer:<some-JWT>

     Token request to STS:

     POST /v1/token
     Host: iam.foo.example
     Token-Request-Auth-Params: scope=read:some/resource
     Token-Request-Token: Bearer:<some-JWT>
     Token-Request-URI: https://some.origin.example/some/resource

     grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
     audience=some.origin.example&
     scope=read:some/resource&
     ...

     The token request to the STS may elicit a 401 response instructing
     the user-agent or client application to authenticate in some manner.
     For example, an STS might use Bearer with a "token granting token"
     that the user-agent just has to have a priori (how such a token-
     granting-token is acquired and refreshed is out of scope for this
     document), and/or it might use Negotiate, Basic, or other
     authentication methods.  The user-agent or client application might
     also be configured to know which authentication methods a given
     issuer might require and thus "pre-flight" an Authorization field in
     the token request to the STS.  We elide the 401 and retry here for
     brevity.

     It is also possible that an STS might issue a redirect or extended
     401 flow to another STS.  This too is elided here, but the user-agent
     MUST save the state from the first token request, process the second,
     return to the first STS, and retry the first request with the newly
     acquired credential.





  Williams                   Expires 6 June 2026                  [Page 7]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     Thus after any authentication exchanges, a successful response from
     the STS if it supports this feature is a 200 Ok response with a
     Location field to remind the user-agent or client its state (but the
     user-agent or client MUST recall this metadata anyways):

     HTTP/1.1 200 Ok
     Location: https://some.origin.example/some/resource

     <token>

     XXX Well, perhaps we should dispense with the Location field here
     given that we require the user-agent/client to know that anyways.

     XXX It might be desirable to allow the STS to tell the user-agent to
     set some select fields in its return request to the origin, perhaps
     headers named Token-Response* or specifically Authorization.

     Otherwise if the STS does not support this feature but it would issue
     the token then it should issue a code and respond with a redirect as
     in an OIDC redirect flow:

     HTTP/1.1 302 Found
     Location: https://some.origin.example/some/resource?code=..&state=..

     The user-agent or client MUST remember the URI in case the STS
     responds with 200 Ok with the token as the response body and without
     a Location field.

     Armed with the requisite token (if it was issued), the user-agent/
     client SHOULD retry the original request with the Authorization field
     set to Bearer <token> with the token returned by the STS.

     Note that the extended Bearer 401 flow MUST NOT change the browser's
     window location when the user-agent is a browser.  Instead the user-
     agent MUST execute the STS request and then retry the original
     request (if the STS response is successful) in the same sort of way
     that it would perform any Kerberos KDC exchanges had the selected
     HTTP authentication method been Negotiate [NEGOTIATE], that is: the
     STS interaction MUST NOT be visible to any scripts on the web page
     that produced the 401 response.

  2.2.  Server Response Type Selection

     When a server needs the client to authenticate or obtain a new access
     token (with different scopes), it can respond with a 3xx redirect or
     a 401.  The server needs to be able to decide which to use.





  Williams                   Expires 6 June 2026                  [Page 8]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     When the client includes a Token-Request-Pref field in its request,
     the server that supports extended 401 flows SHOULD use the client's
     preference.

     Otherwise the server should use local configuration, possibly
     including user-agent fingerprinting (such as by user-agent substring
     matching), to pick a response type.  When the user-agent is
     interactive the server can return a 401 with a body with a script
     that will load a page that will trigger an OIDC redirect flow,
     possibly after a few seconds, or with a link that the user can click
     on.  Or the server can expose a way for the user to choose the flow
     to use, though this presumably will not usually be done except for
     debugging or demonstration purposes.

  2.3.  User-Agent Use

     Ideally user-agents will implement the 401 flow, but typically they
     will not include the Token-Request-Pref field in their requests,
     either at all or unless configured to do so (possibly only for some
     sites).

     Reasons for not including the Token-Request-Pref field include:

     *  avoiding request bloat

     *  avoiding fingerprinting

     User-agents SHOULD be configurable, possibly using a list of sites
     and domainname stems for selecting when to include this header.

  2.4.  Client Application Use

     Client applications can also implement the extended 401 flow as they
     would a regular unextended 401 flow.

     As with user-agents, when it is the client application that
     implements the extended 401 flow the application SHOULD have local
     policy and configuration.

  2.5.  Mapping realm to issuer

     For the non-extended 401 case, user-agents and clients can be
     configured to map the realm auth-param to an issuer, and engage in
     the extended 401 flow anyways.







  Williams                   Expires 6 June 2026                  [Page 9]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


  2.6.  Token Caching

     Where a user-agent or client application implements this extended
     Bearer 401 flow it can and SHOULD also implement some sort of token
     cache to alleviate load on STSes and to improve availability.
     Proxies, however, should never cache token request responses, and the
     STS SHOULD set the Cache-Control field accordingly to include the the
     following directives:

     *  no-cache, unqualified

     *  max-age set to the number of seconds after which the token should
        not be used due to impending expiration

     *  s-maxage=0 so as to reinforce that shared caches must not cache
        this token

     If the Cache-Control is absent then the user-agent or client MAY
     infer:

     *  no-cache, unqualified

     *  max-age with any lifetime it can glean from the token if that
        metadata is unencrypted in the token

     Similarly, if Cache-Control but no-cache is absent then the user-
     agent or client MAY infer it, and if max-age is absent then the user-
     agent or client MAY infer it as well.

  3.  Extended Redirect Flow

     The extended redirect flow has a normal 3xx response from the server
     but with the WWW-Authenticate field present, possibly including new
     auth-params.

     Note well that some user-agents terminate 3xx response processing as
     soon as they see the expected Location field, and thus may not see a
     WWW-Authenticate field if it comes after, and note that proxies are
     allowed to reorder fields (but not field values for multi-valued
     fields), therefore it is not possible for a server to reliably count
     on the WWW-Authenticate field being seen by the client.

     Still, when a client sees the WWW-Authenticate field then it SHOULD
     act as though the response was a 401 response engaging in an extended
     OAuth 401 flow.






  Williams                   Expires 6 June 2026                 [Page 10]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


  4.  Negotiation of 401 vs Redirect Flows

     A server may only support redirect flows, only 401 flows, or it may
     support negotiation as described here.  Ideally all servers will
     eventually support negotiation, and/or all user-agents will support
     the extended Bearer 401 flow.

     The Token-Request-Pref field has two values: 401 and redirect.  When
     present the server SHOULD use the expressed preference if it needs a
     new token.

     When this field is absent the server must choose a response type
     using configuration and user-agent fingerprinting.

  5.  Local Policy

     Local policy is OPTIONAL.  When present, local policy expresses:

     *  whether to enable automatic token request handling when using the
        extended Bearer 401 flow

     *  allow lists for issuers and/or realms

     *  mappings of realms to issuers

     *  authentication methods to allow at each issuer, if any

     *  global and site-specific flow type preferences, and whether to
        express those flow type preferences via the Token-Request-Pref
        field

     *  for each allowed issuer optionally record its authentication
        method preferences so that the user-agent or client application
        may pre-flight an Authorization field in the token requests to
        that issuer

  6.  New fields

     *  Token-Request-Pref is a structured field of kind Item with a value
        of "401" or "redirect"

     *  Token-Request is a structured field of kind Item with a value of
        "true" if present

     *  Token-Request-Token is a structured field of kind Item with a
        token as its value





  Williams                   Expires 6 June 2026                 [Page 11]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     *  Token-Request-Auth-Params is a structured field of kind List with
        the 401 response's auth-params from the WWW-Authenticate: Bearer
        field

     *  Token-Request-URI is a field of kind Item containing the URI that
        requested the token

  7.  New auth-params

     *  issuer

     *  server_token_type

     *  server_token

     *  state

     See section 2 (Section 2) for details.

  8.  Wider Applicability: Negotiate Auth w/o GSS or Kerberos
      Implementations!

     This section is INFORMATIONAL.

     A similar extension design can be applied to the Negotiate HTTP auth
     method that would allow user-agents to support Negotiate without
     having a local implementation of the GSS-API [GSSAPI], Kerberos
     [KERBEROS], or other GSS mechanisms.  All that would be needed is an
     STS-like service that itself can issue Kerberos tickets or can
     impersonate users to a Kerberos Key Distribution Center (KDC) and
     thus obtain tickets on their behalf, then the STS can mint GSS-API
     tokens for the Kerberos mechanism [GSSKRB5].  The rest of the flow
     would be remarkably similar to the extended Bearer 401 flow.

     An implementation of such an Negotiate token issuer could have a
     certification authority credential to mint user certificates for use
     with PKINIT [PKINIT] to impersonate users to a Kerberos KDC.  Thus
     such a service would not need intimate access to the KDC's key
     database, and can be interoperate with any KDC implementation that
     supports PKINIT.  In all cases such a service would be as security-
     sensitive as a KDC, and would best be seen as part of the KDC, and
     for discovery purposes should probably be co-located with the KDC.

     As in the case of Bearer an issuer URI auth-param for Negotiate might
     be useful, though perhaps the user will have to have selected an
     issuer from a server-provided list of choices.  In the case of
     Kerberos, for example, the choice of token issuer will be dependent
     on the user's credentials' issuer, thus local configuration at the



  Williams                   Expires 6 June 2026                 [Page 12]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     user-agent will be the best source of an issuer value for a Negotiate
     401 flow that resembles the extended Bearer 401 flow.  But even in
     the case of Kerberos if the user-agent can help the server include
     the correct issuer auth-param value then the flow can work in spite
     of the lack of local configuration.

  9.  Single Sign-On

     This section is INFORMATIVE.

     When engaging in an OIDC or SAML redirect flow, or an extended
     401/407 flow as in this document, ultimately the user-agent, the
     client, and/or the user will have to authenticate the user to an
     issuer.  How that is done initially (e.g., with passwords, smartcards
     and PINs, etc.) is out of scope here, but for Single Sign-On (SSO)
     one will want to distinguish between "initial authentication" and
     non-initial authentication (i.e., _not_ passwords, smartcards, PINs,
     etc.), much like Kerberos [KERBEROS] does.  A user-agent could use
     cookies, or a "token-granting token" (similar to a Kerbero ticket-
     granting ticket, both sharing the same acronym of 'TGT') to
     repeatedly authenticate to an issuer for a limited time after which
     the user has to once again engage in "initial authentication".

  10.  IANA Considerations

     As there is no registry of HTTP auth method auth-params, we do not
     register any of the new auth-params created here.  However, it might
     be desirable to create such a registry before this document's
     publication as an RFC.

     This document registers several new HTTP fields listed below.

  10.1.  HTTP Field Registrations

     *  Field Name: Token-Request-Pref

        Status: permanent

        Structured Type: Item

        Reference: this document

     *  Field Name: Token-Request

        Status: permanent

        Structured Type: Item




  Williams                   Expires 6 June 2026                 [Page 13]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


        Reference: this document

     *  Field Name: Token-Request-Token

        Status: permanent

        Structured Type: Item

        Reference: this document

     *  Field Name: Token-Request-Auth-Params

        Status: permanent

        Structured Type: Item

        Reference: this document

     *  Field Name: Token-Request-URI

        Status: permanent

        Structured Type: Item

        Reference: this document

  11.  Security Considerations

     Existing user-agents that support redirect flows usually trust all
     redirects.  As a result we make local policy OPTIONAL for use in the
     automatic the extended Bearer 401 flow.  The specification of an
     "abstract schema" for local policy is an improvement.

     User-agents such as browsers MUST NOT allow scripts embedded or
     injected into web pages to access to the STS responses from extended
     Bearer 401 flow.  This is already the case, thus this requirement is
     not a new requirement and does not impose on other working groups or
     standards development organizations.

     Apart from the above this document does not add new security
     considerations beyond those of OAuth and OIDC, but it does remove the
     need for "codes" and PKCE [PKCE] by not abusing URI q-params to carry
     tokens or token-like "codes", instead carrying tokens only in the
     Authorization field and in the STS response body invisible to scripts
     on web pages.  As well by not abusing URI q-params no sensitive
     cryptographic material such as "codes" and tokens can end up in user-
     agent history nor in client- or server-side logs.




  Williams                   Expires 6 June 2026                 [Page 14]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     Thus this extended Bearer 401 flow is strictly an improvement in
     security for OAuth.

     But note that when the server does not implement the extended Bearer
     401 flow then a fallback to a redirect flow may happen, thus user-
     agents and/or clients still need to implement PKCE [PKCE].

  12.  References

  12.1.  Normative References

     [BEARER]   Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/info/rfc6750>.

     [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/info/rfc9110>.

     [OAUTH2]   Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  12.2.  Informative References

     [GSSAPI]   Linn, J., "Generic Security Service Application Program
                Interface Version 2, Update 1", RFC 2743,
                DOI 10.17487/RFC2743, January 2000,
                <https://www.rfc-editor.org/info/rfc2743>.

     [GSSKRB5]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
                Version 5 Generic Security Service Application Program
                Interface (GSS-API) Mechanism: Version 2", RFC 4121,
                DOI 10.17487/RFC4121, July 2005,
                <https://www.rfc-editor.org/info/rfc4121>.





  Williams                   Expires 6 June 2026                 [Page 15]


  Internet-Draft     HTTP Bearer Auth Method Extensions      December 2025


     [KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
                Kerberos Network Authentication Service (V5)", RFC 4120,
                DOI 10.17487/RFC4120, July 2005,
                <https://www.rfc-editor.org/info/rfc4120>.

     [NEGOTIATE]
                Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
                Kerberos and NTLM HTTP Authentication in Microsoft
                Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
                <https://www.rfc-editor.org/info/rfc4559>.

     [PKCE]     Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
                for Code Exchange by OAuth Public Clients", RFC 7636,
                DOI 10.17487/RFC7636, September 2015,
                <https://www.rfc-editor.org/info/rfc7636>.

     [PKINIT]   Zhu, L. and B. Tung, "Public Key Cryptography for Initial
                Authentication in Kerberos (PKINIT)", RFC 4556,
                DOI 10.17487/RFC4556, June 2006,
                <https://www.rfc-editor.org/info/rfc4556>.

     [SCRAM]    Melnikov, A., "Salted Challenge Response HTTP
                Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
                March 2016, <https://www.rfc-editor.org/info/rfc7804>.

  Appendix A.  Acknowledgements

  Author's Address

     Nico Williams
     Austin
     United States
     Email: nico@cryptonector.com


















  Williams                   Expires 6 June 2026                 [Page 16]


name: draft-schulze-ecap
rev: 00
title: The Ethical Crawler Agreement Protocol (ECAP)
time: 2025-12-10T10:41:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-13T10:41:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774076+00:00
source: ietf
abstract:
  This document specifies the Ethical Crawler Agreement Protocol (ECAP),
     an application-layer protocol for managing consent and ethical
     verification between web hosts and automated agents (crawlers, AI
     scrapers).  Unlike the voluntary robots.txt standard, ECAP utilizes
     cryptographic signatures and a declarative policy handshake to ensure
     verifiable, consent-based access to web resources.

full_text:
  Internet-Draft                                         A. Schulze-Hueneke
  Intended status: Experimental                                   JamOne-DE
  Expires: June 13, 2026                                  December 10, 2025


                The Ethical Crawler Agreement Protocol (ECAP)
                           draft-schulze-ecap-00

  Abstract

     This document specifies the Ethical Crawler Agreement Protocol (ECAP),
     an application-layer protocol for managing consent and ethical
     verification between web hosts and automated agents (crawlers, AI
     scrapers).  Unlike the voluntary robots.txt standard, ECAP utilizes
     cryptographic signatures and a declarative policy handshake to ensure
     verifiable, consent-based access to web resources.

  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 June 13, 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Revised BSD License text as described in Section 4.e of the
     Trust Legal Provisions and are provided without warranty as described
     in the Revised BSD License.

  Table of Contents

     1.  Introduction
     2.  Terminology
     3.  Protocol Overview
     4.  The ECAP Handshake
     5.  Data Formats
         5.1.  HTTP Headers
         5.2.  Policy File
     6.  Security Considerations
     7.  IANA Considerations
     8.  References
     Author's Address

  1.  Introduction

     The proliferation of automated agents, particularly for AI training
     and data harvesting, has rendered traditional access control
     mechanisms like robots.txt insufficient.  ECAP proposes a new
     standard where access is negotiated via a cryptographic handshake,
     ensuring that agents explicitly declare their intent and hosts
     explicitly grant consent.

  2.  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, and only when, they appear in all
     capitals, as shown here.

     Agent:  The automated client initiating the request.
     Host:   The server hosting the resource.
     Intent: The declared purpose of the data access (e.g., "research").

  3.  Protocol Overview

     ECAP operates over HTTP/1.1 or HTTP/2.  It introduces a set of
     headers and a well-known policy file located at
     "/.well-known/ecap-policy".

  4.  The ECAP Handshake

     The handshake consists of the following steps:

     1.  The Agent requests "/.well-known/ecap-policy".
     2.  The Host returns the JSON policy containing allowed intents and
         a public key.
     3.  The Agent sends a signed request to the protected resource using
         ECAP headers.
     4.  The Host verifies the signature and intent against its policy.
     5.  The Host responds with "210 Accepted" or an appropriate error
         code (e.g., "403E Ethical Denied").

  5.  Data Formats

  5.1.  HTTP Headers

     This document defines the following HTTP headers:

     ECAP-Agent-ID:  A unique identifier for the crawler (e.g., email).
     ECAP-Intent:    The purpose of the crawl (e.g., "indexing").
     ECAP-Signature: Ed25519 signature of the request metadata.
     ECAP-Timestamp: ISO 8601 timestamp to prevent replay attacks.

  5.2.  Policy File

     The policy file MUST be a JSON document containing version, allowed
     intents, and cryptographic material.

  6.  Security Considerations

     Implementations MUST use secure signature algorithms (Ed25519 recommended).
     Hosts MUST validate timestamps to prevent replay attacks (max skew
     +/- 60 seconds).

  7.  IANA Considerations

     This document requests the registration of the HTTP headers listed
     in Section 5.1 in the "Permanent Message Header Field Names" registry.

  8.  References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, May 2017.

  Author's Address

     Adnan Schulze-Hueneke
     JamOne-DE
     Schwuelper
     Germany

     Email: hallo@jamone.de
     URI:   https://ecap-protocol.com


name: draft-li-dmsc-mcps-agw
rev: 00
title: Multi-agent Collaboration Protocol Suite based on Agent Gateway
time: 2026-02-06T00:50:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-10T00:50:23Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774080+00:00
source: ietf
abstract:
  This document specifies a Multi-agent Collaboration Protocol Suite
     based on Agent Gateway, which enables scalable, secure, and
     semantically driven collaboration among distributed agents across
     heterogeneous networks.  The protocol suite introduces Agent Gateways
     as control-plane entities responsible for agent registration,
     authentication, capability management, semantic routing and other
     functions, while preserving direct peer-to-peer semantic interactions
     among agents.

full_text:
  DMSC Working Group                                                 X. Li
  Internet-Draft                                             China Telecom
  Intended status: Standards Track                         5 February 2026
  Expires: 9 August 2026


      Multi-agent Collaboration Protocol Suite based on Agent Gateway
                         draft-li-dmsc-mcps-agw-00

  Abstract

     This document specifies a Multi-agent Collaboration Protocol Suite
     based on Agent Gateway, which enables scalable, secure, and
     semantically driven collaboration among distributed agents across
     heterogeneous networks.  The protocol suite introduces Agent Gateways
     as control-plane entities responsible for agent registration,
     authentication, capability management, semantic routing and other
     functions, while preserving direct peer-to-peer semantic interactions
     among agents.

  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 9 August 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.










  Li                        Expires 9 August 2026                 [Page 1]


  Internet-Draft                  MCPS-AGW                   February 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions used in this document . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Multi-Agent Collaboration Protocol Suite Overview . . . . . .   3
       4.1.  Agent Registration and Authorization Process  . . . . . .   5
       4.2.  Capability Digest and Synchronization Process . . . . . .   5
       4.3.  Semantic Resolution and Routing Process . . . . . . . . .   6
       4.4.  Task-based Multi-Agent Invocation Process . . . . . . . .   6
     5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     As multi-agent systems become increasingly distributed across
     heterogeneous networks and administrative domains, efficient, secure,
     and semantically meaningful collaboration among agents becomes a
     critical challenge.  Traditional service-oriented or message-based
     interaction models are insufficient to capture agent-level
     capabilities, dynamic task decomposition, and semantic intent-driven
     communication.

     This document specifies a Multi-agent Collaboration Protocol Suite
     based on Agent Gateway (AGW).  The suite defines a set of coordinated
     protocols that enable agent registration, authentication, capability
     synchronization, semantic routing, task-based invocation, and peer-
     to-peer semantic interaction.  The architecture leverages Agent
     Gateways as first-class network entities that mediate control, policy
     enforcement, and orchestration, while allowing agents to directly
     exchange semantic information once authorized.

     The protocol suite is aligned with the architectural principles of
     control/forwarding plane separation, least-privilege authorization,
     and session-scoped semantic communication.




  Li                        Expires 9 August 2026                 [Page 2]


  Internet-Draft                  MCPS-AGW                   February 2026


  2.  Conventions used in this document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119] .

  3.  Terminology

     The following terms are defined in this draft:

     *  AGW: Agent Gateway.  A network-resident control and forwarding
        entity responsible for agent registration, local binding,
        capability management, semantic routing, and policy enforcement.

     *  Agent: An autonomous software entity capable of perception,
        planning, decision-making, and execution.

     *  Semantic Routing: The process of routing an Agent request based on
        the meaning or intent of the request, rather than solely on a pre-
        defined address or identifier.

     *  Central Auth: Central Authentication Service: A logically
        centralized authority that performs identity verification and
        authorization decisions for agents and gateways.

  4.  Multi-Agent Collaboration Protocol Suite Overview

     The Multi-Agent Collaboration Protocol Suite based on Agent Gateway
     defines a set of coordinated protocols as shown in figure 1 that
     collectively enable secure agent onboarding, ,distributed capability
     visibility, semantic request resolution, peer-to-peer semantic
     interaction, and task-oriented multi-agent orchestration.  Rather
     than operating independently, these protocols are designed to be
     executed in a tightly coupled manner along the agent lifecycle and
     collaboration workflows.  The Agent Gateway (AGW) serves as the
     anchoring point for control-plane coordination, while semantic
     interactions are progressively delegated to agents once resolution
     and authorization are completed.

     The protocol suite consists of the following functional components::

     *  Agent Registration Protocol (ARP) and Agent Authentication and
        Authorization Protocol (AAAP), which jointly establish agent
        identity, trust, and operational scope.

     *  Capability Synchronization Protocol (CSP), which maintains
        distributed visibility of agent capability digest across gateways.




  Li                        Expires 9 August 2026                 [Page 3]


  Internet-Draft                  MCPS-AGW                   February 2026


     *  Semantic Resolution and Routing Protocol (SRRP), which enables
        semantic request discovery and routing across gateway domains.

     *  Task-based Invocation Protocol (TIP), which extends semantic
        routing to multi-agent task decomposition and orchestration.

     Each protocol operates at a specific phase of the collaboration
     lifecycle and may be invoked independently or in combination with
     others.  The following sections describe how these protocols are
     integrated into coherent operational flows.

   User        Agent A      AGW1          AGW3        Central Auth        AGW2        Agent B    Agent C
    |             |            |             |               |              |<--------------Register|
    |             |Register--->|             |               |              |<--Register|           |
    |             |            |--Auth Req------------------>|<---Auth Req--|           |           |     +-----------------------------+
    |             |            |<-----------------Auth Grant |--Auth Grant->|           |           |<----| Agent Registration process  |
    |             |<-Local Bind|             |               |              |           |           |     +-----------------------------+
    |             |            |             |               |              |--Local Bind (B,C)---->|
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |     +-----------------------------+
    |             |            |<----------->|<-----Capa Digest and Sync -->|           |           |<----| Agent Gateway Interaction   |
    |             |            |             |               |              |           |           |     +-----------------------------+
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    | --Req-----> |-SemR Req-->|             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |---SemR Req->|----------------------------->|           |           |
    |             |            |<------------|<------SemR Resp--------------|           |           |
    |             |<-SemR Resp |             |               |              |           |           |     +-----------------------------+
    |             |============================ Semantic Session========================|           |<----| Semantic Routing process    |
    |             |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|           |     +-----------------------------+
    |             |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<|           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |--Task Req-->|               +-----------------------------+           |           |           |
    |             | ---------->   | Semantic Routing process    |---------->|           |           |
    |             |               + ----------------------------+           |           |           |     +-----------------------------+
    |             |--------------------------------------Invoke------------------------------------>|<----|Task-based Invocation process|
    |             |<--------------------------------------Executing---------------------------------|     +-----------------------------+
    |             |            |             |               |              |           |           |

                             Figure 1 The overall sequence diagram of MCPS-AGW







  Li                        Expires 9 August 2026                 [Page 4]


  Internet-Draft                  MCPS-AGW                   February 2026


  4.1.  Agent Registration and Authorization Process

     An agent MUST register with its locally attached Agent Gateway before
     participating in any collaboration.  This process is governed jointly
     by ARP and AAAP and establishes the agent’s identity, trust status,
     and capability binding.  Upon receiving a registration request, the
     Agent Gateway performs preliminary validation of the agent’s identity
     attributes and initial capability description, and creates a
     provisional local binding.  The gateway then initiates an
     authentication and authorization request to the Central
     Authentication Service, conveying the agent identity, gateway
     identity, and requested operational scope.

     The Central Authentication Service evaluates the request and returns
     an authorization grant or denial.  Upon successful authorization, the
     Agent Gateway finalizes the registration by assigning the agent a
     globally unique Agent Identifier and Capability Identifier(s).  An
     agent MUST NOT be considered active, discoverable, or invocable until
     this process completes successfully.  This combined registration and
     authorization procedure ensures that all subsequent semantic routing
     and task invocation operate on authenticated identities and policy-
     approved capability scopes.

  4.2.  Capability Digest and Synchronization Process

     Each Agent Gateway maintains detailed capability information only for
     its locally registered agents.  Gateways do not synchronize full
     agent capability states with each other.  Instead, to support inter-
     gateway semantic resolution, gateways exchange capability digests
     using the Capability Synchronization Protocol (CSP).  A capability
     digest is a locally generated, abstract summary of available
     capabilities, designed solely to indicate what kinds of capabilities
     exist behind a gateway, rather than how those capabilities are
     internally implemented or executed by agents.The structure and
     semantics of capability digests are intentionally decoupled from
     agent-internal capability representations, allowing gateways to
     evolve local capability models without impacting inter-gateway
     interoperability.

     CSP distributes these capability digests incrementally.  An initial
     exchange establishes basic inter-gateway visibility, while subsequent
     updates convey only digest changes, such as newly advertised
     capabilities, capability updates, or withdrawals.  Digest updates are
     versioned and acknowledged to support consistency and conflict
     resolution.  Through this digest-based mechanism, gateways maintain a
     scalable and privacy-preserving view of distributed agent
     capabilities without requiring centralized directories or full
     capability replication.



  Li                        Expires 9 August 2026                 [Page 5]


  Internet-Draft                  MCPS-AGW                   February 2026


  4.3.  Semantic Resolution and Routing Process

     When a user issues a request to an agent (e.g., Agent A), the agent
     abstracts the request into a semantic request and submits it to its
     locally attached Agent Gateway (AGW1).  This interaction is governed
     by the Semantic Resolution and Routing Protocol (SRRP).  Upon
     receiving the semantic request, AGW1 performs semantic parsing and
     normalization and consults its local capability directory.  If no
     matching capability identifier is found, AGW1 forwards the semantic
     request to a peer or upstream gateway (e.g., AGW3), which repeats the
     same resolution procedure.  If the request remains unresolved, it is
     further forwarded to another gateway (e.g., AGW2).

     When a gateway identifies a matching capability in its local
     directory, it generates a semantic resolution response containing the
     resolved capability identifier and the corresponding target agent
     information.  This response is propagated hop-by-hop back to the
     originating gateway and ultimately delivered to Agent A.

     Following successful resolution, Agent A and the target agent (e.g.,
     Agent B) directly establish a semantic session.  During the lifetime
     of this session, semantic data is exchanged directly between agents
     in a peer-to-peer manner, while gateways remain responsible for
     resolution, authorization scope enforcement, and security policy
     application during session establishment.

  4.4.  Task-based Multi-Agent Invocation Process

     Task-based collaboration extends semantic resolution to scenarios
     requiring multiple agents and coordinated execution, as defined by
     the Task-based Invocation Protocol (TIP).  When a user initiates a
     task request, the request is delivered to Agent A, which performs
     semantic understanding of the task and decomposes it into one or more
     sub-tasks along with the required capabilities.  If Agent A does not
     possess task decomposition capabilities, its attached Agent Gateway
     MAY act as a proxy to analyze and decompose the task on behalf of the
     agent.

     For each sub-task, Agent A submits a semantic request to its local
     gateway, triggering the same multi-hop semantic resolution process
     defined by SRRP.  Unlike pure point-to-point semantic communication,
     gateways additionally apply task-level constraints, policy
     considerations, and capability selection logic to identify suitable
     target agents.

     The resolved results are returned to Agent A, which then directly
     invokes the selected agents and establishes the necessary semantic
     sessions for execution.  Through this mechanism, multiple agents can



  Li                        Expires 9 August 2026                 [Page 6]


  Internet-Draft                  MCPS-AGW                   February 2026


     be dynamically selected and coordinated to collaboratively execute
     complex tasks, while maintaining consistent authorization and
     security enforcement through gateway-mediated control-plane
     functions.

  5.  Conclusion

     By explicitly separating control-plane functions from semantic
     interaction flows, and leveraging gateways as control-plane
     coordination points, the proposed protocol suite enables scalable and
     secure multi-agent collaboration without compromising agent autonomy.

  6.  IANA Considerations

     TBD

  7.  Acknowledgement

     TBD

  8.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

  Author's Address

     Xueting Li
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: lixt2@foxmail.com















  Li                        Expires 9 August 2026                 [Page 7]


name: draft-romanchuk-normative-admissibility
rev: 00
title: Normative Admissibility Framework for Agent Speech Acts
time: 2026-01-06T19:35:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-10T19:35:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774112+00:00
source: ietf
abstract:
  This document defines a normative framework for evaluating the
     admissibility of speech acts produced by autonomous agents in goal-
     directed activity.  The framework establishes rules for determining
     whether an agent's statement is admissible based on its modality
     (assertive, conditional, refusal, descriptive) and its grounding
     state, independent of semantic truth.

     This framework enables deterministic, auditable evaluation of agent
     contributions without requiring truth verification or semantic
     interpretation.

full_text:
  Network Working Group                                       O. Romanchuk
  Internet-Draft                                               Independent
  Intended status: Informational                            6 January 2026
  Expires: 10 July 2026


          Normative Admissibility Framework for Agent Speech Acts
                 draft-romanchuk-normative-admissibility-00

  Abstract

     This document defines a normative framework for evaluating the
     admissibility of speech acts produced by autonomous agents in goal-
     directed activity.  The framework establishes rules for determining
     whether an agent's statement is admissible based on its modality
     (assertive, conditional, refusal, descriptive) and its grounding
     state, independent of semantic truth.

     This framework enables deterministic, auditable evaluation of agent
     contributions without requiring truth verification or semantic
     interpretation.

  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 10 July 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.








  Romanchuk                 Expires 10 July 2026                  [Page 1]


  Internet-Draft           Normative Admissibility            January 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Model Overview  . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Evaluation Flow . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  Separation of Concerns  . . . . . . . . . . . . . . . . .   5
     4.  Statement Model . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Statement Structure . . . . . . . . . . . . . . . . . . .   5
       4.2.  Statement Admissibility Conditions  . . . . . . . . . . .   6
     5.  Modality Classification . . . . . . . . . . . . . . . . . . .   6
       5.1.  Modality Types  . . . . . . . . . . . . . . . . . . . . .   6
       5.2.  Modality Determination  . . . . . . . . . . . . . . . . .   7
       5.3.  Formal Indicators . . . . . . . . . . . . . . . . . . . .   7
     6.  Grounding Model . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  GroundSet Structure . . . . . . . . . . . . . . . . . . .   8
       6.2.  Ground Scope  . . . . . . . . . . . . . . . . . . . . . .   8
       6.3.  Strength Derivation . . . . . . . . . . . . . . . . . . .   8
       6.4.  Scope Strength Aggregation  . . . . . . . . . . . . . . .   9
       6.5.  License Derivation  . . . . . . . . . . . . . . . . . . .   9
     7.  Normative Axioms  . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Axiom A5: Prohibition of Ungrounded Assertive Claims  . .  10
       7.2.  Axiom A6: Admissibility of Refusal  . . . . . . . . . . .  10
       7.3.  Axiom A7: Conditional Admissibility . . . . . . . . . . .  11
       7.4.  Axiom A4: Grounding Requirement . . . . . . . . . . . . .  11
       7.5.  Axiom Evaluation Order  . . . . . . . . . . . . . . . . .  11
     8.  Evaluation Outcomes . . . . . . . . . . . . . . . . . . . . .  11
       8.1.  Status Values . . . . . . . . . . . . . . . . . . . . . .  11
       8.2.  Evaluation Result Structure . . . . . . . . . . . . . . .  12
     9.  Evaluation Algorithm  . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Algorithm . . . . . . . . . . . . . . . . . . . . . . . .  12
       9.2.  Determinism Guarantee . . . . . . . . . . . . . . . . . .  13
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  13
       10.1.  Modality Detection Errors  . . . . . . . . . . . . . . .  13
       10.2.  Grounding Manipulation . . . . . . . . . . . . . . . . .  14
       10.3.  Self-Licensing Prevention  . . . . . . . . . . . . . . .  14
       10.4.  Limitations  . . . . . . . . . . . . . . . . . . . . . .  14



  Romanchuk                 Expires 10 July 2026                  [Page 2]


  Internet-Draft           Normative Admissibility            January 2026


     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
       12.2.  Informative References . . . . . . . . . . . . . . . . .  14
     13. Appendix A: Rationale (Non-Normative) . . . . . . . . . . . .  15
       13.1.  Why Form-Based Evaluation  . . . . . . . . . . . . . . .  15
       13.2.  Why Modality Matters . . . . . . . . . . . . . . . . . .  15
       13.3.  Conservative Assumptions . . . . . . . . . . . . . . . .  15
       13.4.  Theoretical Foundation . . . . . . . . . . . . . . . . .  15
     14. Appendix B: Examples (Non-Normative)  . . . . . . . . . . . .  16
       14.1.  Assertive Claim with Strong Grounding  . . . . . . . . .  16
       14.2.  Assertive Claim with Weak Grounding  . . . . . . . . . .  16
       14.3.  Conditional Claim with Weak Grounding  . . . . . . . . .  16
       14.4.  Explicit Refusal . . . . . . . . . . . . . . . . . . . .  16
     15. Author's Address  . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction

  1.1.  Problem Statement

     Autonomous agents operating in goal-directed environments produce
     statements that require evaluation before being acted upon.
     Traditional evaluation approaches rely on semantic truth
     verification, which is either impossible (no oracle exists) or
     circular (using another model to judge model outputs).

     This document specifies an alternative approach: evaluating
     admissibility of agent speech acts based on their logical form
     (modality) and evidential basis (grounding), without requiring truth
     verification.

  1.2.  Scope

     This framework:

     *  Defines admissibility conditions for agent-generated statements
     *  Specifies modality classification rules
     *  Establishes grounding requirements for each modality
     *  Provides deterministic evaluation axioms

     This framework does NOT:

     *  Verify semantic truth of statements
     *  Model agent reasoning or intent
     *  Provide domain-specific knowledge validation
     *  Replace human judgment in high-stakes decisions





  Romanchuk                 Expires 10 July 2026                  [Page 3]


  Internet-Draft           Normative Admissibility            January 2026


  1.3.  Design Goals

     1.  *Determinism*: Same input produces same evaluation outcome
     2.  *Auditability*: Full trace from input to evaluation result
     3.  *Non-circularity*: No agent-generated content validates itself
     4.  *Modality-sensitivity*: Different statement forms have different
         requirements

  2.  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, and only when, they appear in all
     capitals, as shown here.

  2.1.  Definitions

     *Statement*: A linguistic unit consisting of a subject (what is being
     discussed) and a predicate (what is claimed about the subject).

     *Modality*: The logical form of a statement that determines its
     manner of participation in normative evaluation.  One of: ASSERTIVE,
     CONDITIONAL, REFUSAL, DESCRIPTIVE.

     *Grounding*: The evidential basis for a statement, consisting of
     knowledge nodes with associated epistemic status.

     *Ground Scope*: Classification of grounding as FACTUAL (observable
     world state) or CONTEXTUAL (user goals, preferences, situational
     factors).

     *Strength*: Epistemic quality of grounding: STRONG (observed,
     confirmed) or WEAK (hypothesized, inferred).

     *License*: The set of modalities permitted for a statement given its
     grounding state.

     *Admissibility*: Property of a statement whose modality is within its
     permitted license.

     *Non-admissible*: Property of a statement whose modality exceeds its
     permitted license.

  3.  Model Overview






  Romanchuk                 Expires 10 July 2026                  [Page 4]


  Internet-Draft           Normative Admissibility            January 2026


  3.1.  Architecture

     The evaluation framework operates on three inputs:

     Inputs:
       ├─ Statement (S)          - Agent-generated linguistic output
       ├─ GroundSet (G)          - Available evidential basis
       └─ Context (C)            - Terms considered as given

     Output:
       └─ EvaluationResult       - Admissibility status with trace

  3.2.  Evaluation Flow

  Statement → Modality Classification → License Derivation → Axiom Check → Status
       │              │                       │                  │           │
       S        Modality(S)             License(G)          Axiom(M,L)    Status

  3.3.  Separation of Concerns

     The framework explicitly separates:

      +===========+===============================+=====================+
      | Layer     | Responsibility                | NOT Responsible For |
      +===========+===============================+=====================+
      | Modality  | Statement form classification | Semantic            |
      |           |                               | interpretation      |
      +-----------+-------------------------------+---------------------+
      | Grounding | Evidential basis assessment   | Truth verification  |
      +-----------+-------------------------------+---------------------+
      | Axioms    | Admissibility rules           | Domain knowledge    |
      +-----------+-------------------------------+---------------------+

                                    Table 1

  4.  Statement Model

  4.1.  Statement Structure

     A Statement is a tuple:

     Statement := ⟨Subject, Predicate⟩

     Where: - Subject: Term denoting the object of the statement -
     Predicate: Term denoting property, relation, or state






  Romanchuk                 Expires 10 July 2026                  [Page 5]


  Internet-Draft           Normative Admissibility            January 2026


  4.2.  Statement Admissibility Conditions

     A statement MUST satisfy all of the following to be well-formed:

     *Condition F1 (Formability)*:

     Subject ≠ ∅ ∧ Predicate ≠ ∅

     *Condition F2 (Contextual Independence)*:

     Meaning(Subject) and Meaning(Predicate) do not depend on Statement

     *Condition F3 (Non-Self-Reference)*:

     Statement does not refer to itself or its generation process

     Violation of any condition results in status ILL_FORMED.

  5.  Modality Classification

  5.1.  Modality Types

     Modality is a function over Statement:

     Modality : Statement → {ASSERTIVE, CONDITIONAL, REFUSAL, DESCRIPTIVE}

                +=============+==============================+
                | Modality    | Definition                   |
                +=============+==============================+
                | ASSERTIVE   | Categorical normative claim  |
                |             | without explicit conditions  |
                +-------------+------------------------------+
                | CONDITIONAL | Normative claim with         |
                |             | explicitly stated conditions |
                +-------------+------------------------------+
                | REFUSAL     | Explicit admission of        |
                |             | inability to determine       |
                +-------------+------------------------------+
                | DESCRIPTIVE | Factual observation without  |
                |             | normative claim              |
                +-------------+------------------------------+

                                   Table 2

     *Note on GOAL-CONDITIONAL*: Goal-conditional statements (e.g., "If
     your goal is X, do Y") are a syntactic subclass of CONDITIONAL
     modality with higher detection priority.  They are classified as
     CONDITIONAL for axiom application purposes.



  Romanchuk                 Expires 10 July 2026                  [Page 6]


  Internet-Draft           Normative Admissibility            January 2026


  5.2.  Modality Determination

     Modality MUST be determined by presence of formal indicators (textual
     patterns) in the statement, NOT by semantic interpretation.

     *Head-Driven Detection*: Modality is determined by the CORE ASSERTION
     only (first paragraph or first sentence).  Supplementary clauses in
     the tail do not change modality classification.

     Example:

     "Prioritize X. [justification]. If you tell me Y..."
       → Core: "Prioritize X"
       → Modality: ASSERTIVE (not CONDITIONAL)

     *Detection Priority* (evaluated in order, MUST NOT be reordered):

  1. REFUSAL           - if refusal indicators present
  2. GOAL-CONDITIONAL  - if goal-conditional structure ("if your goal is...")
  3. ASSERTIVE         - if recommendation indicators present in core
  4. CONDITIONAL       - if condition indicators present in core
  5. DESCRIPTIVE       - if purely factual indicators present
  6. ASSERTIVE         - default (anti-evasion policy)

  5.3.  Formal Indicators

     Formal indicators are textual patterns sufficient for classification.

             +==================+================================+
             | Modality         | Indicator Patterns (examples)  |
             +==================+================================+
             | REFUSAL          | "cannot determine", "need more |
             |                  | information", "insufficient"   |
             +------------------+--------------------------------+
             | GOAL-CONDITIONAL | "if your goal is", "if you     |
             |                  | want to", "assuming you care"  |
             +------------------+--------------------------------+
             | CONDITIONAL      | "if", "unless", "assuming",    |
             |                  | "depends on", "given that"     |
             +------------------+--------------------------------+
             | ASSERTIVE        | "should", "must", "recommend", |
             |                  | "is better", "prioritize"      |
             +------------------+--------------------------------+
             | DESCRIPTIVE      | "has status", "is blocked by", |
             |                  | "due date is", "blocks"        |
             +------------------+--------------------------------+

                                    Table 3



  Romanchuk                 Expires 10 July 2026                  [Page 7]


  Internet-Draft           Normative Admissibility            January 2026


     *Goal-Conditional Override*: Statements beginning with goal-
     conditional structure ("If your goal is X, do Y") MUST be classified
     as CONDITIONAL even if recommendation indicators are present.

     The default to ASSERTIVE is a POLICY CHOICE for safety-critical
     deployments.  Alternative policies (e.g., CONSERVATIVE_REFUSAL) may
     be appropriate for exploratory contexts.

  6.  Grounding Model

  6.1.  GroundSet Structure

     GroundSet := {KnowledgeNode}

     KnowledgeNode := ⟨content, scope, status, confidence⟩

     Where: - content: The propositional content - scope: FACTUAL or
     CONTEXTUAL - status: OBSERVED, CONFIRMED, HYPOTHESIZED, INFERRED -
     confidence: Numeric value [0.0, 1.0]

  6.2.  Ground Scope

        +============+==========================+=====================+
        | Scope      | Definition               | Examples            |
        +============+==========================+=====================+
        | FACTUAL    | Observable world state   | API responses,      |
        |            |                          | database records    |
        +------------+--------------------------+---------------------+
        | CONTEXTUAL | User goals, preferences, | User intent,        |
        |            | situational factors      | business priorities |
        +------------+--------------------------+---------------------+

                                    Table 4

  6.3.  Strength Derivation

     Strength is derived from content properties, NOT from transport
     channel.

     *CRITICAL PRINCIPLE: Content-Based Warrant*

     Tool call ≠ truth acquired.

     The act of invoking a tool or external system is a causal action.
     The epistemic status of a proposition is a property of the content
     returned and its evidential warrant, not of the transport mechanism
     by which it was obtained.




  Romanchuk                 Expires 10 July 2026                  [Page 8]


  Internet-Draft           Normative Admissibility            January 2026


     Accordingly, weakly warranted propositions MUST NOT be upgraded to
     STRONG solely by passing through tools, expert systems, or APIs
     without an explicit improvement in evidential status.

     Strength(node) :=
       STRONG  if status = CONFIRMED ∧ confidence ≥ threshold
       WEAK    otherwise

     The threshold value (e.g., 0.7) is illustrative.  Implementations MAY
     use different thresholds provided the STRONG/WEAK distinction remains
     deterministic and documented.

     For tool-derived observations (API responses, database records):

     status = OBSERVED or CONFIRMED
     confidence = 1.0
     → Strength = STRONG

     For cognitive context (user preferences, inferred goals):

     status = HYPOTHESIZED or CANDIDATE
     confidence < 0.7
     → Strength = WEAK

     This prevents illegitimate upgrading of weakly warranted
     propositions: such propositions cannot acquire STRONG status merely
     by passing through tool boundaries.

  6.4.  Scope Strength Aggregation

     Within a scope, strongest evidence determines scope strength:

    ScopeStrength(scope, G) :=
      STRONG  if ∃ node ∈ G : node.scope = scope ∧ Strength(node) = STRONG
      WEAK    otherwise

  6.5.  License Derivation

     License is derived from GroundSet composition:












  Romanchuk                 Expires 10 July 2026                  [Page 9]


  Internet-Draft           Normative Admissibility            January 2026


         +=============+=========+============+======================+
         | GroundSet   | FACTUAL | CONTEXTUAL | Permitted Modalities |
         | Composition |         |            |                      |
         +=============+=========+============+======================+
         | FACTUAL     | STRONG  | N/A        | ASSERTIVE,           |
         | only        |         |            | CONDITIONAL, REFUSAL |
         +-------------+---------+------------+----------------------+
         | FACTUAL     | WEAK    | N/A        | CONDITIONAL, REFUSAL |
         | only        |         |            |                      |
         +-------------+---------+------------+----------------------+
         | FACTUAL +   | STRONG  | STRONG     | ASSERTIVE,           |
         | CONTEXTUAL  |         |            | CONDITIONAL, REFUSAL |
         +-------------+---------+------------+----------------------+
         | FACTUAL +   | STRONG  | WEAK       | CONDITIONAL, REFUSAL |
         | CONTEXTUAL  |         |            |                      |
         +-------------+---------+------------+----------------------+
         | FACTUAL +   | WEAK    | any        | CONDITIONAL, REFUSAL |
         | CONTEXTUAL  |         |            |                      |
         +-------------+---------+------------+----------------------+
         | CONTEXTUAL  | N/A     | any        | REFUSAL              |
         | only        |         |            |                      |
         +-------------+---------+------------+----------------------+
         | Empty       | N/A     | N/A        | REFUSAL              |
         +-------------+---------+------------+----------------------+

                                    Table 5

  7.  Normative Axioms

  7.1.  Axiom A5: Prohibition of Ungrounded Assertive Claims

     Modality(S) = ASSERTIVE ∧ ASSERTIVE ∉ License(G)
       → Status(S) = VIOLATES_NORM

     Applicability: ASSERTIVE modality only.

     An assertive statement without sufficient grounding is non-
     admissible.

  7.2.  Axiom A6: Admissibility of Refusal

     Modality(S) = REFUSAL → Status(S) = ACCEPTABLE

     Applicability: REFUSAL modality only.

     Explicit refusal to determine is always admissible.





  Romanchuk                 Expires 10 July 2026                 [Page 10]


  Internet-Draft           Normative Admissibility            January 2026


     *Scope Clarification*: This axiom establishes admissibility, not
     desirability.  Excessive or strategic refusal may be undesirable at
     the application layer but is out of scope for this framework.
     Application-layer policies MAY impose additional constraints on
     refusal frequency or patterns.

  7.3.  Axiom A7: Conditional Admissibility

     Modality(S) = CONDITIONAL ∧ ConditionsDeclared(S)
       → Status(S) = CONDITIONALLY_ACCEPTABLE

     Applicability: CONDITIONAL modality only.

     Conditional claims are admissible when conditions are explicit.

  7.4.  Axiom A4: Grounding Requirement

     Normative(S) ∧ GroundSet = ∅ → Status(S) = UNSUPPORTED

     Applicability: ASSERTIVE, CONDITIONAL modalities.

     Normative claims require non-empty grounding.

  7.5.  Axiom Evaluation Order

     Axioms MUST be evaluated in the following order:

  1. A6 (REFUSAL)     - if Modality = REFUSAL, return ACCEPTABLE
  2. A5 (ASSERTIVE)   - if Modality = ASSERTIVE and unlicensed, return VIOLATES_NORM
  3. A7 (CONDITIONAL) - if Modality = CONDITIONAL with conditions, return CONDITIONALLY_ACCEPTABLE
  4. A4 (GROUNDING)   - if normative with empty ground, return UNSUPPORTED
  5. Default          - return ACCEPTABLE

  8.  Evaluation Outcomes

  8.1.  Status Values

           +==========================+============================+
           | Status                   | Meaning                    |
           +==========================+============================+
           | ACCEPTABLE               | Statement is admissible    |
           +--------------------------+----------------------------+
           | CONDITIONALLY_ACCEPTABLE | Statement is admissible    |
           |                          | under stated conditions    |
           +--------------------------+----------------------------+
           | VIOLATES_NORM            | Statement modality exceeds |
           |                          | permitted license          |
           +--------------------------+----------------------------+



  Romanchuk                 Expires 10 July 2026                 [Page 11]


  Internet-Draft           Normative Admissibility            January 2026


           | UNSUPPORTED              | Normative statement lacks  |
           |                          | grounding                  |
           +--------------------------+----------------------------+
           | ILL_FORMED               | Statement fails structural |
           |                          | requirements               |
           +--------------------------+----------------------------+
           | UNDERDETERMINED          | Evaluation not possible    |
           |                          | with available information |
           +--------------------------+----------------------------+

                                    Table 6

     *Terminology Note*: The term VIOLATES_NORM denotes non-admissibility
     under the evaluation rules defined in this framework.  It does NOT
     imply ethical, legal, or security violation.  "Norm" refers to the
     activity participation rules (axioms A4-A7), not external normative
     standards.

  8.2.  Evaluation Result Structure

     EvaluationResult := {
       statement: String,
       modality: Modality,
       license: Set[Modality],
       status: Status,
       applicable_axiom: AxiomId,
       grounding_trace: GroundSet
     }

  9.  Evaluation Algorithm

  9.1.  Algorithm



















  Romanchuk                 Expires 10 July 2026                 [Page 12]


  Internet-Draft           Normative Admissibility            January 2026


  EVALUATE(statement, ground_set):
    1. VALIDATE structure (F1, F2, F3)
       IF violation THEN RETURN ILL_FORMED

    2. DETERMINE modality M := Modality(statement)
       IF modality cannot be determined THEN RETURN UNDERDETERMINED

    3. DERIVE license L := License(ground_set)
       IF grounding incomplete or ambiguous THEN RETURN UNDERDETERMINED

    4. APPLY axioms in order:
       IF M = REFUSAL THEN RETURN ACCEPTABLE (A6)
       IF M = ASSERTIVE AND ASSERTIVE ∉ L THEN RETURN VIOLATES_NORM (A5)
       IF M = CONDITIONAL AND conditions_declared THEN RETURN CONDITIONALLY_ACCEPTABLE (A7)
       IF M ∈ {ASSERTIVE, CONDITIONAL} AND ground_set = ∅ THEN RETURN UNSUPPORTED (A4)
       IF M = DESCRIPTIVE AND factual_grounding_present THEN RETURN ACCEPTABLE
       IF M = ASSERTIVE AND ASSERTIVE ∈ L THEN RETURN ACCEPTABLE

    5. RETURN UNDERDETERMINED

     *Note on UNDERDETERMINED*: This status indicates that the evaluator
     lacks sufficient information or jurisdiction to render a verdict.  It
     is a valid outcome representing honest acknowledgment of evaluation
     limits, not an error condition.  Triggering conditions are
     implementation-defined but MUST include cases where modality
     detection or grounding assessment cannot proceed deterministically.

  9.2.  Determinism Guarantee

     Given identical inputs (statement, ground_set), the algorithm MUST
     produce identical outputs.  No probabilistic components are permitted
     in the evaluation path.

  10.  Security Considerations

  10.1.  Modality Detection Errors

     Incorrect modality classification may result in:

     *  *False ASSERTIVE*: Conditional statement classified as assertive
        may be incorrectly flagged as VIOLATES_NORM
     *  *False CONDITIONAL*: Assertive statement classified as conditional
        may evade A5 enforcement

     Implementations SHOULD log modality determination traces for audit.






  Romanchuk                 Expires 10 July 2026                 [Page 13]


  Internet-Draft           Normative Admissibility            January 2026


  10.2.  Grounding Manipulation

     Adversarial agents may attempt to:

     *  Inject synthetic "strong" grounding to license assertive claims
     *  Omit contextual grounding to avoid scope checks

     Implementations MUST ensure grounding sources are authenticated and
     MUST NOT allow agent-generated content to serve as grounding for the
     same agent's claims.

  10.3.  Self-Licensing Prevention

     This framework explicitly prevents self-licensing:

     *  Agent-generated hypotheses MUST NOT license agent assertions
     *  Tool outputs containing LLM-generated content MUST be typed as
        INFERRED, not OBSERVED

  10.4.  Limitations

     This framework does NOT guarantee:

     *  Semantic correctness of admissible statements
     *  Absence of hallucination in statement content
     *  Domain-specific validity

     Admissibility is necessary but not sufficient for trustworthiness.

  11.  IANA Considerations

     This document has no IANA actions.

  12.  References

  12.1.  Normative References

     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
     1997.

     [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
     Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

  12.2.  Informative References

     [ZINOVIEV] Zinoviev, A.A., "Logical Physics", Reidel Publishing,
     Dordrecht, 1983.



  Romanchuk                 Expires 10 July 2026                 [Page 14]


  Internet-Draft           Normative Admissibility            January 2026


  13.  Appendix A: Rationale (Non-Normative)

  13.1.  Why Form-Based Evaluation

     Traditional AI evaluation approaches assume access to ground truth or
     employ LLM-as-judge patterns.  Both are problematic:

     *  Ground truth is often unavailable in real-world deployments
     *  LLM-as-judge introduces circularity and non-determinism

     This framework evaluates statement form (modality) against evidential
     basis (grounding), avoiding both issues.

  13.2.  Why Modality Matters

     Different statement forms carry different epistemic commitments:

     *  Assertive claims commit the speaker to the truth of the claim
     *  Conditional claims commit only under stated conditions
     *  Refusals commit to inability to determine

     Evaluation must be sensitive to these differences.

  13.3.  Conservative Assumptions

     The framework employs conservative assumptions:

     *  *Presence = Usage*: If contextual grounding is present, it is
        assumed to be used by the statement.  This prevents false
        assertive licenses for contextual claims.

     *  *Default = Assertive*: Ambiguous statements default to assertive
        classification.  This prevents evasion via vague language.

     These assumptions may over-restrict in some cases but ensure safety
     in adversarial conditions.

  13.4.  Theoretical Foundation

     This framework is informed by Zinoviev's Logic of Science, which
     distinguishes:

     *  Logic as rules for operating with linguistic forms
     *  Logic as normative regulation of activity mediated by language

     Axioms A5–A7 implement norms of participation in activity, not laws
     of truth or inference.




  Romanchuk                 Expires 10 July 2026                 [Page 15]


  Internet-Draft           Normative Admissibility            January 2026


     Violation indicates a breach of admissibility conditions within an
     activity, not semantic falsehood.

  14.  Appendix B: Examples (Non-Normative)

  14.1.  Assertive Claim with Strong Grounding

     Statement: "Task X blocks Task Y"
     Modality: DESCRIPTIVE (purely factual)
     GroundSet:
       └─ API response (OBSERVED, FACTUAL, confidence=1.0)
     License: {ASSERTIVE, CONDITIONAL, REFUSAL}
     Status: ACCEPTABLE

  14.2.  Assertive Claim with Weak Grounding

     Statement: "Task X should be prioritized"
     Modality: ASSERTIVE
     GroundSet:
       ├─ API response (OBSERVED, FACTUAL, confidence=1.0)
       └─ User intent (HYPOTHESIZED, CONTEXTUAL, confidence=0.5)
     License: {CONDITIONAL, REFUSAL}
     Status: VIOLATES_NORM (A5)

  14.3.  Conditional Claim with Weak Grounding

  Statement: "If revenue impact is critical, Task X should be prioritized"
  Modality: CONDITIONAL
  GroundSet:
    ├─ API response (OBSERVED, FACTUAL, confidence=1.0)
    └─ User intent (HYPOTHESIZED, CONTEXTUAL, confidence=0.5)
  License: {CONDITIONAL, REFUSAL}
  Status: CONDITIONALLY_ACCEPTABLE (A7)

  14.4.  Explicit Refusal

   Statement: "Cannot determine priority without knowing business context"
   Modality: REFUSAL
   GroundSet: (any)
   License: (any)
   Status: ACCEPTABLE (A6)

  15.  Author's Address

     Oleg Romanchuk Independent Researcher

     Email: [olromanchuk@gmail.com]




  Romanchuk                 Expires 10 July 2026                 [Page 16]


name: draft-hackett-ures
rev: 00
title: Unified Rendering of Email Standard (URES)
time: 2026-01-12T14:19:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T14:19:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774126+00:00
source: ietf
abstract:
  This document specifies requirements for the uniform rendering of
     HTML email content across mail user agents (MUAs).  It addresses
     critical inconsistencies in how email clients interpret HTML and CSS,
     including dark mode adaptation, embedded asset handling, positioning
     constraints, and secure SVG rendering.  The specification aims to
     eliminate the current fragmentation in email rendering while
     maintaining backwards compatibility with existing MIME standards
     (RFCs 2045-2049) and the Internet Message Format (RFC 5322).

full_text:
  Independent Submission                                        W. Hackett
  Internet-Draft                                              January 2026
  Intended status: Standards Track                                        
  Expires: 16 July 2026


                 Unified Rendering of Email Standard (URES)
                           draft-hackett-ures-00

  Abstract

     This document specifies requirements for the uniform rendering of
     HTML email content across mail user agents (MUAs).  It addresses
     critical inconsistencies in how email clients interpret HTML and CSS,
     including dark mode adaptation, embedded asset handling, positioning
     constraints, and secure SVG rendering.  The specification aims to
     eliminate the current fragmentation in email rendering while
     maintaining backwards compatibility with existing MIME standards
     (RFCs 2045-2049) and the Internet Message Format (RFC 5322).

  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 5 July 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.










  Hackett                   Expires 16 July 2026                  [Page 1]


  Internet-Draft                    URES                      January 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Document Structure Requirements . . . . . . . . . . . . . . .   6
       3.1.  HTML Version  . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Required Document Structure . . . . . . . . . . . . . . .   6
       3.3.  Style Placement . . . . . . . . . . . . . . . . . . . . .   7
     4.  CSS Support Requirements  . . . . . . . . . . . . . . . . . .   8
       4.1.  MUST Support Properties . . . . . . . . . . . . . . . . .   8
         4.1.1.  Box Model Properties  . . . . . . . . . . . . . . . .   8
         4.1.2.  Typography Properties . . . . . . . . . . . . . . . .   8
         4.1.3.  Colour and Background Properties  . . . . . . . . . .   8
         4.1.4.  Layout Properties . . . . . . . . . . . . . . . . . .   8
         4.1.5.  CSS Selectors . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Positioning Constraints . . . . . . . . . . . . . . . . .   9
         4.2.1.  Permitted Values  . . . . . . . . . . . . . . . . . .   9
         4.2.2.  Prohibited Values in Web Clients  . . . . . . . . . .   9
       4.3.  z-index Handling  . . . . . . . . . . . . . . . . . . . .  10
         4.3.1.  Stacking Context Isolation  . . . . . . . . . . . . .  10
         4.3.2.  Maximum z-index . . . . . . . . . . . . . . . . . . .  10
       4.4.  Flexbox . . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.5.  CSS Grid (SHOULD Support) . . . . . . . . . . . . . . . .  10
     5.  Dark Mode Adaptation  . . . . . . . . . . . . . . . . . . . .  11
       5.1.  Colour Scheme Meta Tag  . . . . . . . . . . . . . . . . .  11
       5.2.  Media Query Support . . . . . . . . . . . . . . . . . . .  11
       5.3.  Colour Inversion Rules  . . . . . . . . . . . . . . . . .  12
         5.3.1.  Inversion Pairing . . . . . . . . . . . . . . . . . .  12
         5.3.2.  Contrast Preservation . . . . . . . . . . . . . . . .  12
     6.  Image and Asset Handling  . . . . . . . . . . . . . . . . . .  12
       6.1.  Inline Base64 Images  . . . . . . . . . . . . . . . . . .  12
         6.1.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  12
         6.1.2.  Required Support  . . . . . . . . . . . . . . . . . .  12
         6.1.3.  Size Limits . . . . . . . . . . . . . . . . . . . . .  13
         6.1.4.  Rendering Behaviour . . . . . . . . . . . . . . . . .  13
       6.2.  CID (Content-ID) Images . . . . . . . . . . . . . . . . .  13



  Hackett                   Expires 16 July 2026                  [Page 2]


  Internet-Draft                    URES                      January 2026


         6.2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  13
         6.2.2.  Required Behaviour  . . . . . . . . . . . . . . . . .  14
     7.  SVG Rendering . . . . . . . . . . . . . . . . . . . . . . . .  14
       7.1.  Executive-Safe SVG Profile  . . . . . . . . . . . . . . .  14
       7.2.  Prohibited SVG Elements . . . . . . . . . . . . . . . . .  15
         7.2.1.  Script and Event Handlers . . . . . . . . . . . . . .  15
         7.2.2.  External References . . . . . . . . . . . . . . . . .  15
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
       8.1.  Script Execution  . . . . . . . . . . . . . . . . . . . .  15
         8.1.1.  Prohibited Elements . . . . . . . . . . . . . . . . .  15
         8.1.2.  Prohibited Attributes . . . . . . . . . . . . . . . .  16
         8.1.3.  JavaScript URLs . . . . . . . . . . . . . . . . . . .  16
       8.2.  Positioning Attack Prevention . . . . . . . . . . . . . .  16
         8.2.1.  Fixed Position Blocking . . . . . . . . . . . . . . .  16
         8.2.2.  z-index Sandboxing  . . . . . . . . . . . . . . . . .  16
       8.3.  Tracking Prevention . . . . . . . . . . . . . . . . . . .  16
         8.3.1.  Pixel Tracking  . . . . . . . . . . . . . . . . . . .  17
         8.3.2.  Inline Content as Alternative . . . . . . . . . . . .  17
     9.  Accessibility . . . . . . . . . . . . . . . . . . . . . . . .  17
       9.1.  Semantic HTML . . . . . . . . . . . . . . . . . . . . . .  17
       9.2.  Alternative Text  . . . . . . . . . . . . . . . . . . . .  17
       9.3.  Colour Contrast . . . . . . . . . . . . . . . . . . . . .  18
     10. Conformance Levels  . . . . . . . . . . . . . . . . . . . . .  18
       10.1.  URES Level 1 (Baseline)  . . . . . . . . . . . . . . . .  18
       10.2.  URES Level 2 (Enhanced)  . . . . . . . . . . . . . . . .  18
       10.3.  URES Level 3 (Full)  . . . . . . . . . . . . . . . . . .  19
     11. Adoption Considerations . . . . . . . . . . . . . . . . . . .  19
       11.1.  Open Source Reference Implementations  . . . . . . . . .  19
       11.2.  Precedent for Community-Driven Adoption  . . . . . . . .  20
       11.3.  Incremental Adoption Path  . . . . . . . . . . . . . . .  20
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
       13.2.  Informative References . . . . . . . . . . . . . . . . .  22
     Appendix A.  Known Client Inconsistencies . . . . . . . . . . . .  22
       A.1.  CSS Support Matrix (Selected Properties)  . . . . . . . .  23
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

  1.1.  Background

     Email remains one of the most critical communication channels for
     both personal and business communications.  Despite decades of
     development, the rendering of HTML email content remains
     frustratingly inconsistent across mail user agents (MUAs).




  Hackett                   Expires 16 July 2026                  [Page 3]


  Internet-Draft                    URES                      January 2026


     The current standards landscape is fragmented:

     *  RFC 5322 [RFC5322] defines the Internet Message Format, specifying
        header fields and basic body structure.

     *  RFCs 2045-2049 [RFC2045] define MIME, enabling multi-part messages
        with various content types including text/html.

     *  The W3C maintains HTML and CSS specifications, but these are
        designed for web browsers, not email clients.

     *  No RFC or standard body governs how email clients SHOULD or MUST
        render HTML and CSS content.

     This gap has resulted in a situation where email developers must
     maintain extensive compatibility matrices, use archaic techniques
     such as table-based layouts, and accept that their carefully crafted
     emails will appear differently—or broken—across different clients.

  1.2.  Problem Statement

     The following critical issues plague current email rendering:

     1.  *CSS Support Inconsistency:* Properties universally supported in
         browsers (flexbox, grid, CSS variables) have zero or partial
         support in major email clients.  Gmail strips style tags in non-
         AMP contexts.  Outlook uses Microsoft Word's rendering engine.

     2.  *Dark Mode Chaos:* Email clients implement dark mode adaptation
         differently.  Some invert all colours, some honour author
         preferences, some do nothing.  Text becomes illegible when
         foreground colours are inverted but backgrounds are not.

     3.  *Image Handling:* Base64 inline images are blocked by many
         clients citing size concerns.  CID attachments render
         inconsistently.  Remote images enable tracking and are blocked by
         default.

     4.  *SVG Non-Support:* Most email clients strip or fail to render SVG
         entirely, despite it being a W3C standard since 2001.  Executives
         receive emails with missing logos and charts.

     5.  *Positioning Attacks:* In web-based clients (Gmail, Outlook.com),
         malicious use of position:fixed or high z-index values could
         overlay phishing content atop the webmail UI.






  Hackett                   Expires 16 July 2026                  [Page 4]


  Internet-Draft                    URES                      January 2026


     6.  *Layout Primitives:* Modern CSS layout (flexbox, grid) is
         unsupported in Outlook desktop, forcing continued use of nested
         HTML tables—a technique deprecated in web development since 2010.

     7.  *Font Rendering:* @font-face and web fonts work in approximately
         40% of email clients, with no fallback standardisation.

     8.  *Media Queries:* Support for responsive design via @media queries
         is inconsistent, with Gmail notably stripping them entirely.

  1.3.  Requirements Language

     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, and only when, they appear in all
     capitals, as shown here.

  2.  Terminology

     Mail User Agent (MUA)  An application that accesses email on behalf
        of a user.  This includes desktop applications (Apple Mail,
        Outlook, Thunderbird), web-based clients (Gmail, Outlook.com,
        Yahoo Mail), and mobile applications (iOS Mail, Gmail app).

     Rendering Engine  The component of an MUA responsible for
        interpreting and displaying HTML/CSS content.  Some MUAs use web
        browser engines (WebKit, Blink), others use proprietary engines
        (Microsoft Word in Outlook desktop).

     Dark Mode  A display preference where the UI uses a dark background
        with light text.  Email clients may automatically adapt email
        content to match this preference.

     Colour Scheme  The light or dark preference indicated by the email
        author or inferred by the email client.

     Inline Image  An image embedded directly in the HTML using a data:
        URI with base64 encoding, or referenced via Content-ID (CID).

     Executive-Safe  Content that renders correctly in email clients
        commonly used by business executives, particularly Outlook
        desktop, Apple Mail, and Gmail.

     Stacking Context  A three-dimensional conceptualisation of HTML
        elements along an imaginary z-axis relative to the user.  Elements
        with z-index values form stacking contexts.




  Hackett                   Expires 16 July 2026                  [Page 5]


  Internet-Draft                    URES                      January 2026


     Content Isolation  The practice of preventing email content from
        affecting or overlaying the host application's user interface.

  3.  Document Structure Requirements

  3.1.  HTML Version

     Conforming MUAs MUST support HTML5 document structure as defined in
     [HTML5].  The following DOCTYPE declaration MUST be recognised:

     <!DOCTYPE html>

     MUAs MUST also accept and render documents using XHTML and HTML4
     doctypes for backwards compatibility.  However, email authors SHOULD
     use HTML5.

     MUAs MUST NOT require an XML declaration for HTML email content.

  3.2.  Required Document Structure

     MUAs MUST correctly parse and render the following minimal document
     structure:





























  Hackett                   Expires 16 July 2026                  [Page 6]


  Internet-Draft                    URES                      January 2026


     <!DOCTYPE html>
     <html lang="en" xmlns="http://www.w3.org/1999/xhtml"
           xmlns:o="urn:schemas-microsoft-com:office:office">
     <head>
       <meta charset="UTF-8">
       <meta name="viewport" content="width=device-width,initial-scale=1">
       <meta name="color-scheme" content="light dark">
       <meta name="supported-color-schemes" content="light dark">
       <title>Email Subject</title>
       <!--[if mso]>
       <noscript>
         <xml>
           <o:OfficeDocumentSettings>
             <o:PixelsPerInch>96</o:PixelsPerInch>
           </o:OfficeDocumentSettings>
         </xml>
       </noscript>
       <![endif]-->
       <style>
         /* Author styles */
       </style>
     </head>
     <body>
       <!-- Content -->
     </body>
     </html>

     MUAs MUST preserve the html element's lang attribute and make it
     available to accessibility tools.

     MUAs MUST parse and apply the viewport meta tag for responsive
     rendering on mobile devices.

     MUAs supporting Microsoft Office conditional comments SHOULD
     interpret <!--[if mso]> blocks appropriately.

  3.3.  Style Placement

     MUAs MUST support CSS styles in ALL of the following locations:

     1.  Inline styles via the style attribute on any HTML element

     2.  Embedded styles via style elements in the head

     3.  Embedded styles via style elements in the body

     MUAs MUST NOT strip or ignore style elements based on their placement
     in the document.



  Hackett                   Expires 16 July 2026                  [Page 7]


  Internet-Draft                    URES                      January 2026


     MUAs MUST process multiple style elements in document order, applying
     standard CSS cascade rules.

     MUAs SHOULD support link rel="stylesheet" elements referencing
     external stylesheets, subject to security controls defined in
     Section 8.

     When an MUA chooses not to load external stylesheets for security
     reasons, it MUST still apply all inline and embedded styles.

  4.  CSS Support Requirements

  4.1.  MUST Support Properties

     Conforming MUAs MUST support the following CSS properties with full
     specification compliance:

  4.1.1.  Box Model Properties

     margin, margin-top, margin-right, margin-bottom, margin-left,
     padding, padding-top, padding-right, padding-bottom, padding-left,
     border, border-width, border-style, border-color, border-top, border-
     right, border-bottom, border-left, border-radius, border-top-left-
     radius, border-top-right-radius, border-bottom-left-radius, border-
     bottom-right-radius, width, min-width, max-width, height, min-height,
     max-height, box-sizing

  4.1.2.  Typography Properties

     font-family, font-size, font-weight, font-style, line-height, text-
     align, text-decoration, text-decoration-line, text-decoration-color,
     text-decoration-style, text-transform, letter-spacing, word-spacing,
     white-space, vertical-align

  4.1.3.  Colour and Background Properties

     color, background-color, background-image (for gradients and data:
     URIs), background-position, background-repeat, background-size,
     background (shorthand), opacity

  4.1.4.  Layout Properties

     display (block, inline, inline-block, none, table, table-row, table-
     cell, flex, inline-flex), position (static, relative), float, clear,
     overflow, overflow-x, overflow-y






  Hackett                   Expires 16 July 2026                  [Page 8]


  Internet-Draft                    URES                      January 2026


  4.1.5.  CSS Selectors

     MUAs MUST support the following CSS selectors:

     Type selectors (p, div, table), Class selectors (.classname), ID
     selectors (#idname), Descendant combinator (div p), Child combinator
     (div > p), Adjacent sibling combinator (h1 + p), Attribute selectors
     ([attr], [attr=value], [attr~=value], [attr|=value], [attr^=value],
     [attr$=value], [attr*=value]), Pseudo-classes (:first-child, :last-
     child, :nth-child(), :hover, :active, :focus, :visited, :link),
     Pseudo-elements (::before, ::after, ::first-line, ::first-letter)

  4.2.  Positioning Constraints

     For security reasons detailed in Section 8.2, MUAs MUST constrain the
     position property as follows:

  4.2.1.  Permitted Values

     MUAs MUST support:

     *  position: static (default, normal flow)

     *  position: relative (offset from normal position)

  4.2.2.  Prohibited Values in Web Clients

     Web-based MUAs (those running within a web browser context) MUST
     treat the following values as position: static:

     *  position: fixed

     *  position: absolute

     *  position: sticky

     When an email contains these prohibited position values, the MUA MUST
     either:

     a.  Render the element as position: static, OR

     b.  Render the element as position: relative with top, left, right,
         and bottom values clamped to values that cannot cause the element
         to escape its container.







  Hackett                   Expires 16 July 2026                  [Page 9]


  Internet-Draft                    URES                      January 2026


  4.3.  z-index Handling

     The z-index property controls stacking order within a stacking
     context.  MUAs MUST implement z-index handling that prevents
     malicious overlay attacks.

  4.3.1.  Stacking Context Isolation

     MUAs MUST create a new stacking context for email content that is
     isolated from the host application.  This means:

     *  z-index values within email content MUST NOT affect elements
        outside the email content container.

     *  The email content container MUST have a z-index lower than any
        application UI that could be targeted for spoofing.

  4.3.2.  Maximum z-index

     MUAs SHOULD normalise z-index values within email content.  If an
     email specifies z-index: 2147483647 (the maximum 32-bit signed
     integer), this MUST still be rendered below application UI.

     Implementation approaches:

     a.  Contain email content in an iframe with srcdoc

     b.  Apply CSS containment (contain: strict)

     c.  Clamp z-index values to a maximum safe value

     d.  Render email in a separate compositing layer

  4.4.  Flexbox

     MUAs MUST support CSS Flexible Box Layout [CSS-FLEXBOX-1] including:

     display: flex, display: inline-flex, flex-direction, flex-wrap, flex-
     flow, justify-content, align-items, align-content, order, flex-grow,
     flex-shrink, flex-basis, flex, align-self

  4.5.  CSS Grid (SHOULD Support)

     MUAs SHOULD support CSS Grid Layout [CSS-GRID-1].  Where supported,
     MUAs MUST implement:






  Hackett                   Expires 16 July 2026                 [Page 10]


  Internet-Draft                    URES                      January 2026


     display: grid, display: inline-grid, grid-template-columns, grid-
     template-rows, grid-template-areas, grid-gap, gap, row-gap, column-
     gap, grid-column, grid-row, grid-area

  5.  Dark Mode Adaptation

     Dark mode support is critical for email legibility.  This section
     defines requirements for consistent dark mode behaviour.

  5.1.  Colour Scheme Meta Tag

     MUAs MUST recognise and honour the color-scheme meta tag:

     <meta name="color-scheme" content="light dark">

     Valid values:

     *  "light" - Email is designed for light mode only

     *  "dark" - Email is designed for dark mode only

     *  "light dark" - Email supports both modes

     *  "only light" - Email MUST NOT be adapted for dark mode

     *  "only dark" - Email MUST NOT be adapted for light mode

     When color-scheme is set to "only light", MUAs MUST NOT invert,
     adjust, or otherwise modify the colours specified by the email
     author, even when the MUA or operating system is in dark mode.

  5.2.  Media Query Support

     MUAs MUST support the prefers-color-scheme media query:

     @media (prefers-color-scheme: dark) {
       body {
         background-color: #1a1a1a;
         color: #ffffff;
       }
     }

     @media (prefers-color-scheme: light) {
       body {
         background-color: #ffffff;
         color: #1a1a1a;
       }
     }



  Hackett                   Expires 16 July 2026                 [Page 11]


  Internet-Draft                    URES                      January 2026


     When the user has selected dark mode in their MUA or operating
     system, prefers-color-scheme: dark MUST match.

     MUAs MUST NOT strip or ignore @media rules, including @media
     (prefers-color-scheme: ...) rules.

  5.3.  Colour Inversion Rules

     When an MUA applies automatic dark mode adaptation to an email that
     has not opted out, the following rules MUST be followed:

  5.3.1.  Inversion Pairing

     MUAs MUST NOT invert foreground colours without also inverting the
     corresponding background colour.  Specifically:

     *  If text colour is inverted from dark to light, the background
        behind that text MUST also be inverted from light to dark.

     *  If a background is inverted, all foreground elements (text,
        borders) on that background MUST be correspondingly adjusted.

  5.3.2.  Contrast Preservation

     When inverting colours, MUAs MUST maintain a minimum contrast ratio
     of 4.5:1 for normal text and 3:1 for large text, as defined in WCAG
     2.1 [WCAG21].

  6.  Image and Asset Handling

  6.1.  Inline Base64 Images

     Inline images using data: URIs provide a tracking-free method for
     including images directly in email content.  MUAs MUST support this
     mechanism.

  6.1.1.  Syntax

     <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
     AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
     9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">

  6.1.2.  Required Support

     MUAs MUST render inline base64 images for the following MIME types:

     *  image/png




  Hackett                   Expires 16 July 2026                 [Page 12]


  Internet-Draft                    URES                      January 2026


     *  image/jpeg (including image/jpg as an alias)

     *  image/gif

     *  image/webp

     *  image/svg+xml (subject to security restrictions in Section 7)

  6.1.3.  Size Limits

     MUAs MUST support inline images with encoded sizes of at least:

     *  Individual image: 1 MB (after base64 encoding)

     *  Total per email: 10 MB (cumulative across all inline images)

     MUAs MAY support larger sizes but MUST NOT fail to render images
     below these thresholds.

  6.1.4.  Rendering Behaviour

     MUAs MUST render inline base64 images:

     *  Without requiring user interaction to "load images"

     *  Without displaying tracking/privacy warnings for these images

     *  Immediately upon email open (no lazy-load deferral)

     This behaviour is REQUIRED because inline images:

     *  Cannot be used for tracking (no external request is made)

     *  Are already fully downloaded as part of the email content

     *  Provide a privacy-preserving alternative to remote images

  6.2.  CID (Content-ID) Images

     Content-ID references allow images attached to the email to be
     displayed inline.  MUAs MUST support this mechanism as defined in RFC
     2392 [RFC2392].

  6.2.1.  Syntax

     In the HTML body:

     <img src="cid:image001@example.com" alt="Inline image">



  Hackett                   Expires 16 July 2026                 [Page 13]


  Internet-Draft                    URES                      January 2026


  6.2.2.  Required Behaviour

     MUAs MUST:

     *  Resolve cid: URLs to the corresponding MIME part

     *  Render the image inline at the point of reference

     *  Support CID references in both img elements and CSS background-
        image properties

     *  Render CID images without requiring "load images" interaction

  7.  SVG Rendering

     Scalable Vector Graphics provide resolution-independent images
     essential for logos, icons, charts and diagrams.  This section
     defines an "Executive-Safe" SVG profile that balances functionality
     with security.

  7.1.  Executive-Safe SVG Profile

     The Executive-Safe SVG Profile defines a restricted subset of SVG
     that MUST be supported by conforming MUAs.  This profile is named to
     emphasise that SVG content—particularly logos and charts—must render
     correctly in email clients commonly used by business executives.

     The Executive-Safe profile includes:

     *  All SVG 1.1 shape elements

     *  Text elements

     *  Gradients and patterns

     *  Basic filters (subset)

     *  Symbols and use references (internal only)

     *  Styling via presentation attributes and internal stylesheets

     The Executive-Safe profile excludes:

     *  Script elements and event handlers

     *  External references

     *  Animation elements (use CSS animation instead)



  Hackett                   Expires 16 July 2026                 [Page 14]


  Internet-Draft                    URES                      January 2026


     *  ForeignObject element

     *  Certain filter primitives

  7.2.  Prohibited SVG Elements

     MUAs MUST strip or neutralise the following SVG elements:

  7.2.1.  Script and Event Handlers

     The script element and any element with on* attributes (onclick,
     onload, onerror, etc.)  MUST be stripped.

  7.2.2.  External References

     The following MUST NOT be resolved:

     *  use href="external.svg#symbol"

     *  image href="external.png"

     *  a href="javascript:..."

     *  feImage xlink:href="external.svg"

     Note: Internal references within the same SVG document ARE permitted:

     <use href="#internal-symbol">   <!-- OK -->

  8.  Security Considerations

     Email is a primary vector for phishing, malware distribution and
     social engineering attacks.  MUAs MUST implement robust security
     measures while rendering HTML content.

  8.1.  Script Execution

     MUAs MUST NOT execute JavaScript or any other scripting language in
     email content.

  8.1.1.  Prohibited Elements

     The following elements MUST be stripped or rendered inert:

     *  script element

     *  noscript element (SHOULD be displayed)




  Hackett                   Expires 16 July 2026                 [Page 15]


  Internet-Draft                    URES                      January 2026


  8.1.2.  Prohibited Attributes

     The following attributes MUST be stripped from all elements:

     All on* event handlers: onclick, onload, onerror, onmouseover,
     onfocus, onblur, onsubmit, etc.

  8.1.3.  JavaScript URLs

     The following URL schemes MUST NOT be executable:

     *  javascript:

     *  vbscript:

     *  data:text/html (when containing script)

     MUAs MUST either:

     a.  Strip href/src attributes containing these schemes, OR

     b.  Replace them with safe values (e.g., href="#")

  8.2.  Positioning Attack Prevention

     In web-based MUAs, malicious use of CSS positioning could overlay
     deceptive content atop the webmail UI.

  8.2.1.  Fixed Position Blocking

     MUAs MUST NOT render position: fixed as specified.  Such elements:

     *  MUST be rendered as position: static or position: relative

     *  MUST remain within the email content area

     *  MUST NOT overlay any part of the MUA interface

  8.2.2.  z-index Sandboxing

     MUAs MUST ensure that email content z-index values cannot cause
     elements to render above the MUA interface.

     Implementation: Create a new stacking context for email content that
     is positioned below all MUA UI elements.

  8.3.  Tracking Prevention




  Hackett                   Expires 16 July 2026                 [Page 16]


  Internet-Draft                    URES                      January 2026


  8.3.1.  Pixel Tracking

     Remote images are commonly used as tracking pixels.  MUAs SHOULD:

     *  Block remote images by default

     *  Provide clear UI indication when images are blocked

     *  Allow users to load images per-email or per-sender

  8.3.2.  Inline Content as Alternative

     The mandatory support for base64 inline images (Section 6.1) and CID
     images (Section 6.2) provides senders with tracking-free alternatives
     for embedding images.

  9.  Accessibility

     Email content MUST be accessible to users with disabilities.  MUAs
     MUST NOT strip or alter HTML that supports accessibility.

  9.1.  Semantic HTML

     MUAs MUST correctly interpret and render semantic HTML elements:

     header, footer, nav, main, article, section, aside, h1 through h6, p,
     ul, ol, li, dl, dt, dd, table, th, td (with scope attributes),
     figure, figcaption, blockquote, cite, strong, em

     MUAs MUST NOT flatten semantic structure (e.g., converting all
     elements to div or span).

  9.2.  Alternative Text

     MUAs MUST:

     *  Display alt attribute text when images are not loaded

     *  Expose alt text to assistive technologies

     *  Support role and aria-* attributes

     MUAs MUST NOT strip:

     alt, title, role, aria-label, aria-labelledby, aria-describedby,
     aria-hidden, aria-live, aria-atomic, aria-relevant





  Hackett                   Expires 16 July 2026                 [Page 17]


  Internet-Draft                    URES                      January 2026


  9.3.  Colour Contrast

     When MUAs apply automatic dark mode adaptation (Section 5.3), the
     resulting colour combinations MUST maintain WCAG 2.1 AA contrast
     ratios:

     *  Normal text: 4.5:1

     *  Large text: 3:1

     *  UI components and graphics: 3:1

  10.  Conformance Levels

     To facilitate gradual adoption, this specification defines three
     conformance levels.

  10.1.  URES Level 1 (Baseline)

     An MUA conforming to URES Level 1 MUST:

     *  Support all properties in Section 4.1

     *  Support inline base64 images (Section 6.1)

     *  Support CID images (Section 6.2)

     *  Strip all JavaScript (Section 8.1)

     *  Implement positioning constraints (Section 4.2)

     *  Support prefers-color-scheme media query (Section 5.2)

     *  Preserve semantic HTML (Section 9.1)

  10.2.  URES Level 2 (Enhanced)

     An MUA conforming to URES Level 2 MUST:

     *  Meet all Level 1 requirements

     *  Support the Executive-Safe SVG Profile (Section 7)

     *  Support CSS Flexbox (Section 4.4)

     *  Implement dark mode adaptation rules (Section 5.3)

     *  Support picture element



  Hackett                   Expires 16 July 2026                 [Page 18]


  Internet-Draft                    URES                      January 2026


     *  Support CSS custom properties (variables)

  10.3.  URES Level 3 (Full)

     An MUA conforming to URES Level 3 MUST:

     *  Meet all Level 2 requirements

     *  Support CSS Grid (Section 4.5)

     *  Support @font-face

     *  Support CSS animations (with user preference for reduced motion)

     *  Implement full CSP

     *  Provide tracking prevention (Section 8.3)

  11.  Adoption Considerations

     This section addresses practical considerations for adoption of this
     specification by email client vendors.

  11.1.  Open Source Reference Implementations

     The authors recognise that some email client vendors have
     historically been reluctant to invest in standards-compliant
     rendering engines, preferring instead to repurpose existing
     technologies (such as word processing engines) that were never
     designed for standards-compliant HTML/CSS rendering.

     To address this, the community intends to develop and maintain open
     source reference implementations of URES-compliant rendering
     components.  These implementations will be:

     *  Licensed under permissive terms (MIT, Apache 2.0, or similar)

     *  Designed for embedding in both native and web-based clients

     *  Maintained by the community with regular security updates

     *  Tested against the URES conformance test suite

     Vendors who have historically chosen not to invest in standards-
     compliant rendering may simply adopt these community-maintained
     implementations when ready, rather than continuing to maintain
     proprietary solutions that diverge from industry consensus.




  Hackett                   Expires 16 July 2026                 [Page 19]


  Internet-Draft                    URES                      January 2026


  11.2.  Precedent for Community-Driven Adoption

     This approach mirrors successful adoption patterns across the
     software industry, where vendors have benefited from community-
     developed standards and implementations rather than maintaining
     proprietary alternatives:

     *  React (Meta): Now embedded across enterprise applications,
        including those from vendors who initially resisted component-
        based UI architectures.

     *  GraphQL (Meta): Adopted by major cloud platforms after community
        momentum demonstrated clear benefits over proprietary query
        languages.

     *  OpenTelemetry (CNCF): Observability standard now integrated across
        all major cloud providers, replacing fragmented proprietary
        instrumentation.

     *  Chromium (Google): The rendering engine now powers multiple
        browsers from vendors who previously maintained independent
        engines, including Microsoft Edge.

     *  VS Code / Monaco Editor (Microsoft): An acknowledgement that
        community-driven tooling often surpasses proprietary alternatives.

     Vendors currently maintaining non-compliant rendering engines face an
     ongoing maintenance burden for technology that provides no
     competitive advantage.  The availability of URES-compliant open
     source alternatives offers a path to reduced maintenance costs while
     improving interoperability for their users.

  11.3.  Incremental Adoption Path

     Vendors need not adopt all conformance levels simultaneously.  The
     three-tier conformance structure (Section 10) enables:

     1.  Level 1 adoption with minimal investment, addressing the most
         critical rendering inconsistencies.

     2.  Level 2 adoption as community implementations mature, adding
         modern layout and dark mode support.

     3.  Level 3 adoption for full feature parity with web browsers,
         enabled by proven, stable open source components.






  Hackett                   Expires 16 July 2026                 [Page 20]


  Internet-Draft                    URES                      January 2026


     This graduated approach ensures that even conservative vendors can
     adopt URES without significant risk, leveraging battle-tested
     implementations developed and maintained by the broader community.

  12.  IANA Considerations

     This document registers a new media feature for the prefers-color-
     scheme-only media query:

     Name:  prefers-color-scheme-only

     Values:  light | dark

     Applies to:  visual media

     Description:  Indicates that the email author has requested no
        automatic colour scheme adaptation.

     This document requests registration of the following HTTP header for
     use in email content negotiation:

     Header field name:  X-Email-Renderer-Level

     Applicable protocol:  HTTP (for web-based MUAs)

     Status:  Informational

     Author/Change controller:  IETF

     Specification document(s):  This document

     Values:  1 | 2 | 3

     Example:  X-Email-Renderer-Level: 2

  13.  References

  13.1.  Normative References

     [CSS-FLEXBOX-1]
                Atkins Jr., T., Etemad, E., and R. Atanassov, "CSS
                Flexible Box Layout Module Level 1", W3C Candidate
                Recommendation, November 2018,
                <https://www.w3.org/TR/css-flexbox-1/>.







  Hackett                   Expires 16 July 2026                 [Page 21]


  Internet-Draft                    URES                      January 2026


     [CSS-GRID-1]
                Atkins Jr., T., Etemad, E., and R. Atanassov, "CSS Grid
                Layout Module Level 1", W3C Candidate Recommendation,
                December 2020, <https://www.w3.org/TR/css-grid-1/>.

     [HTML5]    WHATWG, "HTML Living Standard",
                <https://html.spec.whatwg.org/>.

     [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, November 1996,
                <https://www.rfc-editor.org/info/rfc2045>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
                Locators", RFC 2392, August 1998,
                <https://www.rfc-editor.org/info/rfc2392>.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                October 2008, <https://www.rfc-editor.org/info/rfc5322>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, May 2017,
                <https://www.rfc-editor.org/info/rfc8174>.

  13.2.  Informative References

     [CANIEMAIL]
                Community project, "Can I email... Support tables for HTML
                and CSS in emails", <https://www.caniemail.com/>.

     [WCAG21]   W3C, "Web Content Accessibility Guidelines (WCAG) 2.1",
                W3C Recommendation, June 2018,
                <https://www.w3.org/TR/WCAG21/>.

  Appendix A.  Known Client Inconsistencies

     This appendix documents specific inconsistencies in current email
     clients that this RFC aims to address.  Data sourced from caniemail
     project [CANIEMAIL] and direct testing as of January 2026.








  Hackett                   Expires 16 July 2026                 [Page 22]


  Internet-Draft                    URES                      January 2026


  A.1.  CSS Support Matrix (Selected Properties)

     +====================+=========+=====+=========+=====+=====+========+
     | Property           | Gmail   |O.com| O.app   |Apple|Yahoo| T-bird |
     +====================+=========+=====+=========+=====+=====+========+
     | style in head      | Partial |Yes  | Yes     |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | display: flex      | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | display: grid      | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | position: fixed    | No      |No   | No      |No   |No   | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | position:          | No      |No   | Yes     |Yes  |No   | Yes    |
     | absolute           |         |     |         |     |     |        |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | background-image   | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | border-radius      | Yes     |Yes  | Partial |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | @media queries     | No      |Yes  | Yes     |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | CSS variables      | Yes     |Yes  | No      |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | @font-face         | No      |Yes  | No      |Yes  |No   | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+
     | ::before/::after   | No      |Yes  | No      |Yes  |Yes  | Yes    |
     +--------------------+---------+-----+---------+-----+-----+--------+

                                    Table 1

     Legend: Gmail (web), O.com (Outlook.com), O.app (Outlook desktop),
     Apple (Apple Mail), Yahoo (Yahoo Mail), T-bird (Thunderbird)

  Acknowledgements

     The author wishes to acknowledge the work of the Email Standards
     Project (2007-2011), the W3C HTML for Email Community Group
     (2014-2023), and the caniemail.com project for documenting the
     inconsistencies that this specification aims to address.

  Author's Address

     Will Hackett
     London
     United Kingdom
     Email: will@willhackett.uk
     URI:   https://willhackett.uk



  Hackett                   Expires 16 July 2026                 [Page 23]


name: draft-liu-dmsc-acps-arc
rev: 03
title: Agent Collaboration Protocols Architecture for Internet of Agents
time: 2026-01-29T11:53:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-02T11:53:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774130+00:00
source: ietf
abstract:
  Internet of Agents (IoA) aims to facilitate interconnection and
     collaboration among heterogeneous agents to address complex tasks and
     support diverse applications.

     This IETF draft proposes the Agent Collaboration Protocols (ACPs)
     architecture, which includes conceptual domains, functional
     components and reference interfaces, to achieve agent interconnection
     and collaboration.  ACPs cover all stages of agents in the network,
     from their access to collaboration, supporting agent trusted
     registration, agent identity authentication, agent discovery, agent
     interaction, tool invocation, and agent monitoring.  The long-term
     vision of ACPs is to support the future large-scale interconnected
     agents and construct the key infrastructure for IoA.

full_text:
  DMSC Working Group                                                J. Liu
  Internet-Draft                                                     K. Yu
  Intended status: Informational                                     K. Li
  Expires: 2 August 2026                                           K. Chen
                        Beijing University of Posts and Telecommunications
                                                           29 January 2026


     Agent Collaboration Protocols Architecture for Internet of Agents
                         draft-liu-dmsc-acps-arc-03

  Abstract

     Internet of Agents (IoA) aims to facilitate interconnection and
     collaboration among heterogeneous agents to address complex tasks and
     support diverse applications.

     This IETF draft proposes the Agent Collaboration Protocols (ACPs)
     architecture, which includes conceptual domains, functional
     components and reference interfaces, to achieve agent interconnection
     and collaboration.  ACPs cover all stages of agents in the network,
     from their access to collaboration, supporting agent trusted
     registration, agent identity authentication, agent discovery, agent
     interaction, tool invocation, and agent monitoring.  The long-term
     vision of ACPs is to support the future large-scale interconnected
     agents and construct the key infrastructure for IoA.

  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 2 August 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.



  Liu, et al.               Expires 2 August 2026                 [Page 1]


  Internet-Draft              ACPs Architecture               January 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  ACPs Architecture from Functional Perspective . . . . . . . .   5
       4.1.  ACPs Architecture Overview  . . . . . . . . . . . . . . .   5
       4.2.  Conceptual Domains  . . . . . . . . . . . . . . . . . . .   6
         4.2.1.  User Domain . . . . . . . . . . . . . . . . . . . . .   6
         4.2.2.  Agent Domain  . . . . . . . . . . . . . . . . . . . .   6
         4.2.3.  Identity Management Domain  . . . . . . . . . . . . .   6
         4.2.4.  Interconnection Service Domain  . . . . . . . . . . .   7
         4.2.5.  Resource Access Domain  . . . . . . . . . . . . . . .   7
       4.3.  Functional Components . . . . . . . . . . . . . . . . . .   7
         4.3.1.  Functional Components in the Agent Domain . . . . . .   8
         4.3.2.  Functional Components in the Identity Management
                 Domain  . . . . . . . . . . . . . . . . . . . . . . .   9
         4.3.3.  Functional Components in the Interconnection Service
                 Domain  . . . . . . . . . . . . . . . . . . . . . . .  10
         4.3.4.  Functional Components in the Resource Access
                 Domain  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.4.  Reference Interfaces  . . . . . . . . . . . . . . . . . .  11
         4.4.1.  Core Interfaces . . . . . . . . . . . . . . . . . . .  11
         4.4.2.  Interface Semantics . . . . . . . . . . . . . . . . .  12
     5.  Typical Operational Scenarios . . . . . . . . . . . . . . . .  13
       5.1.  Agent Onboarding: Identity, Credential, and Capability
             Description . . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  Agent Discovery and Partner Selection . . . . . . . . . .  13
       5.3.  Agent Interaction with Point-to-point and Grouping
             Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
       5.4.  Tool Invocation . . . . . . . . . . . . . . . . . . . . .  14
       5.5.  Agent Monitoring  . . . . . . . . . . . . . . . . . . . .  14
     6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16



  Liu, et al.               Expires 2 August 2026                 [Page 2]


  Internet-Draft              ACPs Architecture               January 2026


  1.  Introduction

     With the rapid development of artificial intelligence (AI),
     particularly large language model (LLM) technology, the number of AI
     agents has grown dramatically.  With the capability of autonomous
     perception, decision-making, and execution, agents' applications are
     becoming increasingly widespread.

     To overcome the limitations of single-agent systems, and to break
     free from the constraints of proprietary multi-agent frameworks
     developed by various vendors, the Internet of Agents (IoA) has
     emerged.  IoA aims to enable seamless connectivity and efficient
     collaboration among agents, through standardized communication
     protocols and interfaces.

     This draft proposes the functional architecture of Agent
     Collaboration Protocols (ACPs) [ACPs-Github], which is designed for
     IoA to enable wide-area connectivity, cross-domain interoperability,
     and secure collaboration among heterogeneous agents.  The main
     characteristics of ACPs are as follows:

     *  Multi-centralized architecture, which consists of multiple
        autonomous domains, each domain containing its own management
        nodes (such as registration, authentication, and discovery
        functions), to support efficient, reliable, and manageable large-
        scale agent interconnection scenarios.

     *  Standardized communication mechanisms with peer-to-peer and
        grouping mode, allowing agents to self-organize and negotiate
        autonomously, to facilitate rapid and accurate information
        exchange, as well as efficient task Collaboration.

     *  Robust registration and authentication mechanisms, to ensure the
        trusted access of agents and prevent unauthorized access and data
        breaches.

     *  Reliable registration and management of agent capability, along
        with intra-domain and cross-domain discovery based on capability
        matching, to support universal and efficient discovery of
        collaborative agents.

     *  Real-time monitoring of agent status and behavior, to support more
        complex application requirements such as agent auditing and
        transactions.

     ACPs cover all stages of agents in the IoA, from their access to
     collaboration, to construct the key infrastructure for agent
     communication, task collaboration and resource allocation.



  Liu, et al.               Expires 2 August 2026                 [Page 3]


  Internet-Draft              ACPs Architecture               January 2026


  2.  Conventions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

  3.  Terminology

     Agent: An agent is a software or hardware entity with autonomous
     decision-making and execution capabilities, capable of perceiving the
     environment, acquiring contextual information, reasoning, and
     learning.  Agent can perform tasks independently or collaboratively
     with other agents.  Each agent is created by a specific agent
     provider and needs to complete processes such as registration and
     authentication before providing services to obtain a legitimate
     identity and relevant credentials.

     Agent Identity Code (AIC): AIC is a certifiable, globally unique
     identity that represents the identity of an agent.  AIC MAY contain
     the following information: the registration service center, the agent
     provider, the serial number of agent entity and instance, and the
     check code.

     Agent Capability Specification (ACS): ACS is a detailed description
     of an agent's capabilities and information that can be saved and
     retrieved.  ACS MAY use the JSON [RFC8259] format, typically
     including the following information: AIC, the functional capabilities
     of agent, the technical characteristics, and the service interfaces.

     Agent Credential: Agent Credential is a tamper-resistant data object
     issued by a credential authority (e.g., certificate, token) , used by
     an agent to prove identity attributes and/or authorization to a
     relying party.

     Tool: A tool is a device, software component, or service that
     provides a specific function and can be accessed and used by an
     agent.

     Agent Autonomous Domain: Agent Autonomous Domain is an administrative
     and governance domain organized and managed by a specific IoA service
     provider.  It MAY include service functions such as identity
     management, credential management, capability description management,
     agent discovery, message distribution, and agent monitoring.








  Liu, et al.               Expires 2 August 2026                 [Page 4]


  Internet-Draft              ACPs Architecture               January 2026


  4.  ACPs Architecture from Functional Perspective

     This section defines a functional architecture for agent autonomous
     domain in IoA.  The interconnection environment is divided into
     different conceptual domains.  Each conceptual domain includes
     several functional components, and there are different interfaces
     between functional components.

  4.1.  ACPs Architecture Overview

     The overall functional architecture of ACPs is as follows.

     +--------------------------+        +--------------------------+
     | Identity Management      |        | Interconnection Service  |
     | Domain                   |        | Domain                   |
     |                          |        |                          |
     |   +-------+  +-------+   |--------|   +-------+  +-------+   |
     |   | AIMgF |  | CMgF  |   |        |   | ADMgF |  |  ADF  |   |
     |   +-------+  +-------+   |        |   +-------+  +-------+   |
     |   +-------+              |        |   +-------+  +-------+   |
     |   |  IVF  |              |        |   |  MDF  |  | DTMgF |   |
     |   +-------+              |        |   +-------+  +-------+   |
     +-------------+------------+        +-------------+------------+
                   |                                   |
                   |                                   |
                   |                                   |
     +-------------+-----------------------------------+------------+
     |                         Agent Domain                         |
     |                                                              |
     |     +------+ +------+ +------+ +------+ +------+ +------+    |
     |     | AIMF | | ADMF | | IAF  | | AIF  | | TAF  | | AMF  |    |
     |     +------+ +------+ +------+ +------+ +------+ +------+    |
     +-------------+-----------------------------------+------------+
                   |                                   |
                   |                                   |
                   |                                   |
     +-------------+------------+        +-------------+------------+
     | Resource Access Domain   |        |        User Domain       |
     |                          |        |                          |
     |         +------+         |        |                          |
     |         | TSF  |         |        |                          |
     |         +------+         |        |                          |
     +--------------------------+        +--------------------------+

                     Figure 1: ACPs functional architecture

     The agent interconnection environment is organized into five
     conceptual domains:



  Liu, et al.               Expires 2 August 2026                 [Page 5]


  Internet-Draft              ACPs Architecture               January 2026


     1.  User Domain

     2.  Agent Domain

     3.  Identity Management Domain

     4.  Interconnection Service Domain

     5.  Resource Access Domain

     The lines between conceptual domains represent information exchange
     relationships.

     Domains are not necessarily physical network segments; they represent
     responsibility and governance boundaries.  A deployment MAY collapse
     multiple domains into one system, or MAY distribute them across
     multiple organizations.

  4.2.  Conceptual Domains

  4.2.1.  User Domain

     The User Domain is the set of users and user environments that
     initiate tasks and consume final results.  A user MAY be a person or
     an organization.

  4.2.2.  Agent Domain

     The Agent Domain contains agents and agent-side functions required
     for agent interconnection and collaboration, such as agent
     description, agent interaction, agent identity maintenance,
     interconnection authentication, and tool access.

     The agent is the core execution unit of agent interconnection and
     collaboration.  An agent is typically provided and operated by an
     agent provider.  Agents in this domain MUST be able to present
     identity and comply with authentication / authorization decisions
     when interacting with other domains.

  4.2.3.  Identity Management Domain

     The Identity Management Domain contains functions for identity
     lifecycle management, credential lifecycle management, and identity
     verification.  It provides services for registering agents, issuing
     credentials, and verifying identity claims during interconnection.






  Liu, et al.               Expires 2 August 2026                 [Page 6]


  Internet-Draft              ACPs Architecture               January 2026


  4.2.4.  Interconnection Service Domain

     The Interconnection Service Domain contains functions that enable
     agents to find and collaborate with each other, including agent
     capability description management, agent discovery, and message
     distribution for group interactions.

  4.2.5.  Resource Access Domain

     The Resource Access Domain contains tool and resource service
     functions that agents can invoke, such as tool registries, tool
     execution services, data services, and other external resources.

  4.3.  Functional Components

     The functional components are grouped by conceptual domains.  The
     list below is a quick index.  The detailed descriptions are provided
     in Table 1.

     User Domain
       - User

     Agent Domain
       - Agent
       - Agent Identity Maintenance Function (AIMF)
       - Agent Description Maintenance Function (ADMF)
       - Interconnection Authentication Function (IAF)
       - Agent Interaction Function (AIF)
       - Tool Access Function (TAF)
       - Agent Monitoring Function (AMF)

     Identity Management Domain
       - Agent Identity Management Function (AIMgF)
       - Credential Management Function (CMgF)
       - Identity Verification Function (IVF)

     Interconnection Service Domain
       - Agent Description Management Function (ADMgF)
       - Agent Discovery Function (ADF)
       - Message Distribution Function (MDF)
       - Domain Trust Management Function (DTMgF)

     Resource Access Domain
       - Tool Service Function (TSF)

           Figure 2: Functional component index by conceptual domain
                                 (informative)




  Liu, et al.               Expires 2 August 2026                 [Page 7]


  Internet-Draft              ACPs Architecture               January 2026


        +=================+=============+=============================+
        | Conceptual      | Functional  | Function Description        |
        | Domain          | Components  |                             |
        +=================+=============+=============================+
        | User Domain     | User        | Initiate tasks; provide     |
        |                 |             | authorization and policy    |
        |                 |             | input; consume results.     |
        +-----------------+-------------+-----------------------------+
        | Agent Domain    | Agent,      | Execute tasks; maintain     |
        |                 | AIMF, ADMF, | local identity and          |
        |                 | IAF, AIF,   | capability description;     |
        |                 | TAF, AMF    | interact with other agents; |
        |                 |             | access tools; record logs.  |
        +-----------------+-------------+-----------------------------+
        | Identity        | AIMgF,      | Manage identity and         |
        | Management      | CMgF, IVF   | credential lifecycle;       |
        | Domain          |             | verify identity claims and  |
        |                 |             | credential status.          |
        +-----------------+-------------+-----------------------------+
        | Interconnection | ADMgF, ADF, | Manage/publish capability   |
        | Service Domain  | MDF, DTMgF  | descriptions; enable        |
        |                 |             | discovery; support group    |
        |                 |             | messaging and domain        |
        |                 |             | federation policies.        |
        +-----------------+-------------+-----------------------------+
        | Resource Access | TSF         | Expose and control access   |
        | Domain          |             | to tools/resources; obtain  |
        |                 |             | results.                    |
        +-----------------+-------------+-----------------------------+

                     Table 1: Functional components summary

     The functional boundaries defined here are intended to support
     interoperability and clear interface definition.  A deployment MAY
     realize a functional component as software, hardware, or a managed
     service, and MAY consolidate multiple functional components into one
     product.

  4.3.1.  Functional Components in the Agent Domain

     *1.  Agent Identity Maintenance Function (AIMF)*

     AIMF maintains the agent's identity information (e.g., AIC) and
     credentials.  AIMF SHOULD support secure storage and update of
     identity.

     *2.  Agent Description Maintenance Function (ADMF)*




  Liu, et al.               Expires 2 August 2026                 [Page 8]


  Internet-Draft              ACPs Architecture               January 2026


     ADMF maintains agent capability description information (e.g., ACS)
     used for interconnection.  It supports creating, updating, and
     withdrawing descriptions.  ADMF SHOULD ensure that descriptions
     remain consistent with the agent's current identity and capability
     state.

     *3.  Interconnection Authentication Function (IAF)*

     IAF performs authentication and authorization checks for
     interconnection, including mutual verification of peer agents and
     validation of presented credentials.  IAF SHOULD support multiple
     authentication mechanisms.  Deployments are RECOMMENDED to use
     standardized security protocols such as TLS 1.3 [RFC8446] and mutual
     authentication where appropriate.

     *4.  Agent Interaction Function (AIF)*

     AIF provides standardized interaction semantics for agent-to-agent
     communication.  It is responsible for session establishment, message
     exchange, task/context management, and applying security
     requirements.  AIF SHOULD support at least one of point-to-point and
     grouping interaction patterns between agents.

     *5.  Tool Access Function (TAF)*

     TAF provides the agent-side capability to invoke tools and resources
     in the Resource Access Domain.  It supports discovering available
     tools, invoking a selected tool, handling tool results, and enforcing
     access control decisions.

     *6.  Agent Monitoring Function (AMF)*

     AMF exports monitoring and logging data produced by the agent and
     agent-side functions.  It SHOULD support integrity protection and
     privacy controls.

  4.3.2.  Functional Components in the Identity Management Domain

     *1.  Agent Identity Management Function (AIMgF)*

     AIMgF performs identity lifecycle management for agents, including
     allocation, update, and de-registration of AICs.  AIMgF MUST define
     the policies for uniqueness and governance of issued AICs within its
     scope.

     *2.  Credential Management Function (CMgF)*





  Liu, et al.               Expires 2 August 2026                 [Page 9]


  Internet-Draft              ACPs Architecture               January 2026


     CMgF issues and manages Agent Credentials associated with AICs.  CMgF
     SHOULD support credential issuance, renewal, suspension, revocation,
     and status query.

     *3.  Identity Verification Function (IVF)*

     IVF verifies identity claims and credential validity for relying
     parties.  IVF MAY be offered by the same operator as CMgF or by an
     independent third party.  IVF SHOULD support validation of credential
     authenticity, validity period, and status (e.g., revoked/suspended).

  4.3.3.  Functional Components in the Interconnection Service Domain

     *1.  Agent Description Management Function (ADMgF)*

     ADMgF manages the lifecycle of agent capability descriptions in the
     interconnection ecosystem.  It supports accepting capability
     description submissions, validating required fields, reviewing and
     approving publication policies, publishing descriptions, and de-
     listing descriptions.

     *2.  Agent Discovery Function (ADF)*

     ADF enables capability-based discovery of candidate partner agents.
     It receives discovery queries, matches them against available agent
     descriptions, and returns a candidate set.  ADF SHOULD support in-
     domain discovery; and cross-domain discovery is OPTIONAL, within a
     configured trust scope.

     *3.  Message Distribution Function (MDF)*

     MDF provides message distribution services for group interactions,
     such as publish/subscribe or queue-based delivery.  MDF is typically
     used when agents interact in grouping mode.

     *4.  Domain Trust Management Function (DTMgF)*

     DTMgF maintains trust relationships between autonomous domains (e.g.,
     trusted peer domain lists, federation policy).  If present, it
     constrains cross-domain discovery and service-to-service
     interactions.

  4.3.4.  Functional Components in the Resource Access Domain

     *1.  Tool Service Function (TSF)*






  Liu, et al.               Expires 2 August 2026                [Page 10]


  Internet-Draft              ACPs Architecture               January 2026


     TSF provides access to tools and resources for agents.  TSF SHOULD
     support tool registration or exposure, tool invocation handling,
     result return, and access control enforcement.  TSF MAY represent a
     single tool, a tool gateway, or a tool execution environment.

  4.4.  Reference Interfaces

     The reference interfaces between functional components are identified
     as ACP-IF-XX.  An ACP-IF interface definition specifies what
     information is exchanged and what behavior is expected.  It does not
     mandate a specific protocol.

  4.4.1.  Core Interfaces

         +===========+==========+==========+=========================+
         | Interface | Function | Function | Interface description   |
         | ID        | A        | B        |                         |
         +===========+==========+==========+=========================+
         | ACP-IF-01 | AIMF     | AIMgF    | Apply for / update /    |
         |           |          |          | de-register an AIC;     |
         |           |          |          | synchronize identity    |
         |           |          |          | lifecycle state.        |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-02 | AIMF     | CMgF     | Apply for / renew /     |
         |           |          |          | revoke Agent            |
         |           |          |          | Credentials bound to an |
         |           |          |          | AIC.                    |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-03 | IAF      | IVF      | Verify a peer agent's   |
         |           |          |          | claimed identity and    |
         |           |          |          | presented credentials;  |
         |           |          |          | obtain a verification   |
         |           |          |          | result / assertion.     |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-04 | AIMgF    | CMgF     | Coordinate identity-to- |
         |           |          |          | credential binding;     |
         |           |          |          | synchronize identity    |
         |           |          |          | and credential status.  |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-05 | CMgF     | IVF      | Query credential status |
         |           |          |          | and validation material |
         |           |          |          | (e.g., issuer keys,     |
         |           |          |          | revocation state).      |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-06 | ADMF     | ADMgF    | Submit / update /       |
         |           |          |          | withdraw Agent          |
         |           |          |          | Descriptions; receive   |
         |           |          |          | publication status.     |



  Liu, et al.               Expires 2 August 2026                [Page 11]


  Internet-Draft              ACPs Architecture               January 2026


         +-----------+----------+----------+-------------------------+
         | ACP-IF-07 | ADMgF    | ADF      | Synchronize published   |
         |           |          |          | Agent Descriptions and  |
         |           |          |          | metadata for discovery  |
         |           |          |          | indexing.               |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-08 | AIF      | AIF      | Agent-to-agent          |
         |           |          |          | interaction (session,   |
         |           |          |          | task, message exchange) |
         |           |          |          | under an agreed         |
         |           |          |          | interaction mode.       |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-09 | AIF      | MDF      | Group interaction via   |
         |           |          |          | message distribution    |
         |           |          |          | (create / join group,   |
         |           |          |          | publish / subscribe,    |
         |           |          |          | deliver messages).      |
         +-----------+----------+----------+-------------------------+
         | ACP-IF-10 | TAF      | TSF      | Tool / resource         |
         |           |          |          | invocation (discover    |
         |           |          |          | tools, invoke tools,    |
         |           |          |          | obtain results, manage  |
         |           |          |          | context).               |
         +-----------+----------+----------+-------------------------+

                     Table 2: Reference interfaces summary

  4.4.2.  Interface Semantics

     *  *Identity and credential interfaces (ACP-IF-01..05)* provide the
        basis for trust establishment.  Implementations SHOULD support
        auditability of lifecycle operations.

     *  *Description and discovery interfaces (ACP-IF-06..07)* enable
        capability-based agent discovery.  Implementations SHOULD support
        versioning and de-listing of descriptions.

     *  *Agent interaction interfaces (ACP-IF-08..09)* define how agents
        exchange tasks, messages, and context.  Implementations SHOULD
        support confidentiality, integrity, replay protection, and access
        control.

     *  *Tool access interface (ACP-IF-10)* enables secure invocation of
        external tools or resources.  Implementations SHOULD support
        least-privilege access and result integrity.






  Liu, et al.               Expires 2 August 2026                [Page 12]


  Internet-Draft              ACPs Architecture               January 2026


  5.  Typical Operational Scenarios

     This section illustrates how the functional architecture with
     conceptual domains, functional components, and interfaces is applied
     in typical operational scenarios.

  5.1.  Agent Onboarding: Identity, Credential, and Capability Description

     A typical agent onboarding workflow includes:

     1.  The agent (via AIMF) registers identity with AIMgF (ACP-IF-01)
         and obtains an AIC.

     2.  The agent (via AIMF) obtains credentials from CMgF (ACP-IF-02).
         CMgF and AIMgF coordinate binding and status (ACP-IF-04).

     3.  The agent (via ADMF) submits an ACS to ADMgF (ACP-IF-06).  The
         ACS links to the agent's AIC and includes access and capability
         information.

     4.  ADMgF publishes the ACS and synchronizes to ADF (ACP-IF-07) for
         discovery indexing.

  5.2.  Agent Discovery and Partner Selection

     In ACPs, the interaction between agents is task-driven, based on
     which agents can be divided into two roles:

     *  Leader: Agent who issues tasks and organizes interactions.  There
        should only be one Leader in a complete task execution process.

     *  Partner: Agent who accepts tasks and provides services.  After
        Partner receives a task from the Leader, it executes and returns
        the execution result.

     A typical agent discovery workflow includes:

     1.  A Leader determines required capabilities for a task.

     2.  The Leader queries ADF with constraints derived from the task
         (discovery request semantics are realized by ADP).

     3.  ADF returns a ranked candidate set of Partner agents.

     4.  The Leader (via IAF) authenticates selected Partners (ACP-IF-03)
         before starting interaction.





  Liu, et al.               Expires 2 August 2026                [Page 13]


  Internet-Draft              ACPs Architecture               January 2026


  5.3.  Agent Interaction with Point-to-point and Grouping Mode

     In AIP, there are three interaction modes between the Leader and the
     Partner: peer-to-peer mode, grouping mode and hybrid mode.

     *  peer-to-peer mode: In this mode, the Leader maintains separate
        communication connections with each Partner, ensuring context
        isolation.  Each message in this mode has only one sender and
        receiver.

     *  Grouping mode: In this mode, interaction messages between agents
        are distributed through a message queue.  A message in this mode
        has only one sender but may has multiple receivers.

     *  Hybrid mode: In this mode, the Leader and Partner may interact
        directly or through the message queue according to the Leader's
        task planning.

     In point-to-point mode, the Leader and each Partner communicate
     directly via ACP-IF-08.

     In grouping mode, a message distribution service (MDF) is used.
     Agents create/join groups and exchange messages via ACP-IF-09, while
     still using ACP-IF-03 for authentication / authorization decisions.

  5.4.  Tool Invocation

     When an agent needs external tools / resources, a typical tool
     invocation workflow includes:

     1.  The agent uses TAF to discover available tools (locally cached or
         via TSF).

     2.  The agent invokes a tool (ACP-IF-10).

     3.  TSF executes or brokers the tool and returns results to the
         agent.

  5.5.  Agent Monitoring

     If agent monitoring is required, agents and services export logs /
     events via AMF.  Monitoring data can be used for troubleshooting,
     policy enforcement, auditing, and governance.








  Liu, et al.               Expires 2 August 2026                [Page 14]


  Internet-Draft              ACPs Architecture               January 2026


  6.  Conclusions

     This draft introduces the Agent Collaboration Protocols (ACPs)
     architecture for Internet of Agents.  By defining a functional
     architecture with conceptual domains, functional components and
     reference interfaces, ACPs can support trusted registration, identity
     authentication, agent discovery, agent interaction, tool invocation,
     and agent monitoring.  ACPs address the core requirements for
     interoperability and secure collaboration among heterogeneous agents.
     The long-term goal of the ACPs is to enable IoA to serve as the
     critical infrastructure for agent collaboration on complex tasks, as
     well as to support the future large-scale and diverse applications.

  7.  Security Considerations

     This document focuses on the Agent Collaboration Protocols
     architecture for IoA.  Security of IoA is not detailed in this
     document.  Security considerations relevant to deployment with
     multiple agent service providers are suggested to be deeply discussed
     through other proposals.

  8.  IANA Considerations

     This document makes no request for IANA action.

  9.  References

  9.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

  9.2.  Informative References

     [ACPs-Github]
                "ACPs GitHub repository", n.d.,
                <https://github.com/AIP-PUB>.



  Liu, et al.               Expires 2 August 2026                [Page 15]


  Internet-Draft              ACPs Architecture               January 2026


  Authors' Addresses

     Jun Liu
     Beijing University of Posts and Telecommunications
     10 Xitucheng Road, Haidian District
     Beijing
     100876
     China
     Email: liujun@bupt.edu.cn


     Ke Yu
     Beijing University of Posts and Telecommunications
     10 Xitucheng Road, Haidian District
     Beijing
     100876
     China
     Email: yuke@bupt.edu.cn


     Ke Li
     Beijing University of Posts and Telecommunications
     10 Xitucheng Road, Haidian District
     Beijing
     100876
     China
     Email: like1990@bupt.edu.cn


     Keliang Chen
     Beijing University of Posts and Telecommunications
     10 Xitucheng Road, Haidian District
     Beijing
     100876
     China
     Email: chenkl@bupt.edu.cn















  Liu, et al.               Expires 2 August 2026                [Page 16]


name: draft-vandoulas-aidp
rev: 02
title: Agent Interaction & Delegation Protocol (AIDP)
time: 2026-01-18T09:11:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-22T09:11:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774134+00:00
source: ietf
abstract:
  This document specifies the Agent Interaction & Delegation Protocol
     (AIDP), a control-plane protocol for secure, auditable, and
     interoperable software agents.  AIDP defines standardized mechanisms
     for expressing intent, enforcing authority, delegating capabilities,
     executing actions, and binding execution results to agent reasoning
     across heterogeneous systems and administrative domains.

full_text:
  Internet-Draft                                           Ioannis Vandoulas
  Intended status: Informational                                 January 2026
  Expires: 15 July 2026


               Agent Interaction & Delegation Protocol (AIDP)
                   draft-vandoulas-aidp-02


  Abstract

     This document specifies the Agent Interaction & Delegation Protocol
     (AIDP), a control-plane protocol for secure, auditable, and
     interoperable software agents.  AIDP defines standardized mechanisms
     for expressing intent, enforcing authority, delegating capabilities,
     executing actions, and binding execution results to agent reasoning
     across heterogeneous systems and administrative domains.


  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."


  License Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

          This document is subject to BCP 78 and the IETF Trust's Legal Provisions
          Relating to IETF Documents
          (https://trustee.ietf.org/license-info) in effect on the date of
          publication of this document.  Please review these documents
          carefully, as they describe your rights and restrictions with
          respect to this document.

  Table of Contents

     1.  Introduction
     2.  Terminology and Conventions
     3.  Architecture Overview
     4.  Relation to Existing Work
     5.  Agent Identity Model
     6.  Authority & Capability Model
     7.  Intent Envelope
     8.  Execution Model
     9.  Observation & Feedback Binding
     10.  Multi-Agent Interaction
     11. Security Considerations
     12. Governance & Compliance
     13. Extensibility
     14. IANA Considerations
     15. Acknowledgements
     16. References
     17. Wire Format
     18. Message Schemas
     19. Example Messages
     20. Example Flows
     21. Reference Architecture
     22. HTTP Transport Binding
         22.1 Overview
         22.2 Media Types
         22.3 Endpoints
         22.4 Error Handling
         22.5 Webhook Verification
         22.6 Reference Validation Pipeline
     23. Conformance Test Suite Outline


  1. Introduction
  1.1 Motivation
  Recent advances in Large Language Models (LLMs) have enabled the construction of software agents capable of complex reasoning,
  planning, and adaptive behavior. While such agents increasingly participate in real-world computational
  processes—interacting with servers, services, and other agents—there exists no standardized protocol governing how agents express intent,
  exercise authority, delegate capabilities, or bind execution outcomes to their internal reasoning.
  Current implementations rely on ad-hoc mechanisms that lack formal identity, revocation semantics,
  delegation safety, and cross-domain trust guarantees. This absence of standardization creates systemic risks,
  including privilege escalation, confused-deputy vulnerabilities, audit failures, and uncontrolled delegation chains.
  The Agent Interaction & Delegation Protocol (AIDP) defines a formal, interoperable framework for agent-based interaction,
  enabling secure, auditable, and revocable agency across heterogeneous systems and administrative domains.

  1.2 Goals
  AIDP defines a protocol that:
  -	Enables agents to express verifiable intent toward external systems.
  -	Provides formal identity and authority models for agents.
  -	Supports constrained, revocable delegation across trust boundaries.
  -	Binds execution results to originating intent.
  -	Enables deterministic, auditable agent control loops.
  -	Remains transport-agnostic and model-agnostic.

  1.3 Non-Goals
  AIDP does not specify:
  -	Specific cryptographic algorithms.
  -	Concrete serialization formats.
  -	Transport protocols.
  -	LLM architectures or prompting strategies.
  These concerns are explicitly layered beneath the AIDP control plane.

  2. Terminology and Conventions

  2.1 Definitions
  The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119.
  Agent:
  An autonomous software entity capable of producing Intent Envelopes and processing Observations.
  Intent Envelope:
  A protocol message expressing a requested action, including its governance and security context.
  Authority:
  A verifiable capability granting an Agent permission to perform specific actions under defined constraints.
  Delegation:
  The controlled transfer of a subset of authority from one Agent to another.
  Execution Boundary:
  The component responsible for enforcing authorization, executing actions, and producing Observations.
  Observation:
  A protocol message binding the outcome of execution to the originating Intent Envelope.
  Trust Boundary:
  A boundary across which identity, authority, and delegation MUST be revalidated.


  3. Architecture Overview

  3.1 System Components
  An AIDP-compliant system consists of the following logical components:
  -	Reasoning Engine: Produces Intent Envelopes and consumes Observations.
  -	Agent Runtime: Hosts the Reasoning Engine and manages agent state.
  -	Execution Boundary: Enforces authority, executes actions, and emits Observations.
  -	Authority Service: Issues, validates, and revokes authority objects.
  -	Observation Channel: Delivers bound execution outcomes to agents.
  These components MAY be co-located or distributed.

  3.2 Layered Model
  AIDP defines a layered architecture:
  Layer               Description
  ------------------  -----------------------------------
  Agency Control      Intent, Delegation, Authority
  Trust               Identity, Validation, Revocation
  Execution           Action dispatch and enforcement
  Transport           Delivery mechanism (out of scope)

  Each layer MUST operate independently of specific transport or serialization technologies.

  3.3 Control Loop
  The normative agent control loop is:
  A.IntentEnvelope B.Authority Validation C.Execution D.Observation E.Reasoning F.Next IntentEnvelope
  An Agent MAY have multiple outstanding Intent Envelopes at any given
  time.

  An Agent MUST NOT generate a new Intent Envelope whose semantics
  causally depend on the outcome of a prior outstanding Intent Envelope
  unless the corresponding Observation has been received and validated.

  This constraint applies only to causally dependent intents and does not
  prohibit parallel or independent intent dispatch.

  4. Relation to Existing Work

     This section describes how AIDP relates to existing work in the areas
     of authorization, identity management, and capability-based security.
     The intent is to clarify scope and positioning, and to avoid
     ambiguity regarding overlap with prior protocols.

  4.1  Grant Negotiation and Authorization Protocol (GNAP)

     AIDP shares architectural similarities with GNAP in that both define
     a control-plane interaction model based on structured requests and
     policy evaluation, rather than static, scope-based authorization.

     GNAP focuses on negotiating authorization grants for access to
     protected resources among clients, authorization servers, and
     resource servers.  AIDP, by contrast, addresses delegated agentic
     action, where autonomous or semi-autonomous agents express intent,
     exercise constrained authority, and receive execution-bound
     observations.

     Execution semantics, post-execution observation, reasoning failure
     handling, and runtime accountability are explicitly within scope for
     AIDP and are outside the scope of GNAP.  GNAP may therefore be used as
     an authorization mechanism within an AIDP-compliant system, but it
     does not define the full interaction lifecycle specified by AIDP.

  4.2  OAuth 2.0 Rich Authorization Requests (RAR)

     OAuth 2.0 Rich Authorization Requests define a mechanism for
     expressing fine-grained authorization requirements beyond simple
     scope strings.

     AIDP adopts a similar principle by supporting structured expressions
     of authority, but applies it in a broader context.  In AIDP, such
     expressions are embedded within Intent Envelopes and are evaluated in
     conjunction with agent identity, delegation chains, and execution
     constraints.

     Unlike OAuth RAR, AIDP does not assume a client-resource server
     architecture and is not limited to access control semantics.

  4.3  Capability-Based Authorization (ZCAPs and UCAN)

     AIDP is conceptually aligned with capability-based authorization
     systems such as ZCAPs and UCAN, particularly with respect to explicit
     capabilities and delegation chains.

     As in these systems, authority in AIDP is represented as a
     transferable object that can be delegated across multiple actors
     without reliance on a centralized authorization server.

     AIDP differs in that capability delegation is integrated into an
     agent interaction and execution lifecycle, where capabilities are
     evaluated as part of intent processing and execution rather than
     solely as access credentials.

  4.4  Identity Management and SCIM

     AIDP assumes the existence of stable and verifiable agent identities
     and is compatible with identity provisioning and lifecycle
     management systems such as the System for Cross-domain Identity
     Management (SCIM).

     SCIM defines mechanisms for identity representation, provisioning,
     and synchronization across administrative domains.  AIDP builds upon
     such identity systems to specify how authority is delegated and
     exercised during agent interaction and execution.

  4.5  Summary

     AIDP does not replace existing authorization or identity protocols.
     Instead, it composes concepts from prior work into a unified
     control-plane protocol for agent interaction, delegation, execution,
     and accountability.

     Existing mechanisms such as GNAP, OAuth 2.0 Rich Authorization
     Requests, capability-based authorization systems, and SCIM may be
     used as complementary components within an AIDP-compliant
     architecture.


  5. Agent Identity Model

  5.1 Identity Requirements
  Every Agent participating in AIDP MUST possess a verifiable identity.
  An Agent Identity MUST provide the following properties:
  -	Uniqueness: A globally unique identifier.
  -	Issuance: Identification of the issuing authority.
  -	Lifetime: Explicit validity interval.
  -	Revocability: Capability to be invalidated independently of expiration.
  -	Referencability: Stable reference suitable for inclusion in protocol messages.
  An Agent Identity MUST NOT be implicitly inferred from transport, host, or network context.

  5.2 Identity Resolution and Validation
  Identity references MUST be resolved and validated at every Trust
  Boundary crossing.

  For cross-domain interoperability, an identity reference MUST conform
  to one of the following profiles:

  (A) Dereferenceable Identity Profile:
      The identity_ref MUST be resolvable by the verifying domain via a
      deterministic and reachable resolution mechanism defined by the
      issuer.

  (B) Self-Contained Identity Profile:
      The identity_ref MUST be accompanied by cryptographically verifiable
      identity assertions sufficient to establish authenticity without
      issuer reachability.

  If neither profile can be satisfied, the receiving domain MUST reject
  the request or apply fail-closed behavior according to its risk policy.

  6. Authority & Capability Model
  6.1 Authority Objects
  Authority is represented as a first-class object, hereafter termed a Capability.
  A Capability MUST contain:
  -	Subject: Agent Identity to which authority is granted.
  -	Action: Permitted operation(s).
  -	Resource: Target resource(s).
  -	Constraints: Scope, quantity, temporal, and contextual limits.
  -	Issuer: Authority that issued the capability.
  -	Revocation Pointer: Mechanism for revocation verification.
  Capabilities MUST be evaluated independently of any agent claims.

  6.2 Capability Delegation
  Agents MAY delegate authority only by issuing new Capabilities with strictly reduced scope.
  Delegation MUST satisfy:
  -	Subsetting Rule: Delegated authority MUST NOT exceed original authority.
  -	Traceability: Each delegated capability MUST reference its parent.
  -	Revocability: Revocation of a parent capability MUST invalidate all derived capabilities.
  Delegation chains MUST be preserved and transmitted with each Intent Envelope.

  6.3 Revocation Semantics
  Revocation MUST be supported for:
  -	Agent Identity
  -	Capabilities
  -	Delegation chains
  Revocation MUST take effect immediately upon verification and MUST NOT depend on token expiration alone.

  7. Intent Envelope

  7.1 Envelope Structure
  An Intent Envelope is the fundamental protocol message produced by an Agent.
  Each Intent Envelope MUST contain:
  -	envelope_id: Globally unique, non-reusable identifier.
  -	timestamp: Time of issuance.
  -	actor_ref: Reference to Agent Identity.
  -	authority_ref: Reference to Capability.
  -	intent_body: Declared action, target, and parameters.
  -	constraints: Execution limitations.
  -	delegation_chain: Ordered list of delegated Capabilities.
  -	observability_hooks: Declaration of required observation behavior.

  7.2 Envelope Validation Rules
  Upon receipt, the Execution Boundary MUST verify:
  1.	Actor identity validity.
  2.	Capability authenticity and scope.
  3.	Delegation chain integrity.
  4.	Revocation status for all identities and capabilities.
  5.	Constraint satisfaction.
  6.	Non-reuse of envelope_id (replay protection).
  Failure of any validation step MUST abort execution.

  7.3 Authority Separation Principle
  Agents MUST NOT modify:
  -	actor_ref
  -	authority_ref
  -	delegation_chain
  These elements are managed exclusively by the Authority Service and Execution Boundary.

  8. Execution Model
  8.1 Execution Boundary
  The Execution Boundary is the sole component authorized to perform actions on behalf of an Agent.
  The Execution Boundary MUST:
  -	Enforce identity and authority validation.
  -	Apply constraint verification.
  -	Execute the requested action.
  -	Emit a bound Observation.
  The Execution Boundary MUST NOT accept any action request outside of a validated Intent Envelope.

  8.2 Authorization & Enforcement Flow
  Normative execution flow:
  1.	Receive Intent Envelope.
  2.	Validate identity.
  3.	Validate authority and delegation chain.
  4.	Verify revocation status.
  5.	Enforce constraints.
  6.	Execute action.
  7.	Generate Observation.
  8.	Deliver Observation via Observation Channel.
  Any failure in steps 2–5 MUST result in rejection.

  9. Observation & Feedback Binding

  9.1 Observation Structure
  Each Observation MUST contain:
  -	envelope_id
  -	execution_id
  -	status
  -	result
  -	side_effects
  -	timestamp
  -	attestation

  9.2 Binding Requirements
  Reasoning progression within an Agent MUST be gated on validated
  Observations for all intents upon which subsequent reasoning steps
  depend.

  Independent intents MAY be issued and processed concurrently, provided
  that their resulting Observations are correctly bound to their
  respective envelope_id values.

  9.3 Replay Protection & Determinism
  The tuple (envelope_id, execution_id, timestamp) MUST provide replay protection.
  Agent reasoning loops MUST be deterministic with respect to received Observations.

  10. Multi-Agent Interaction

  10.1 Trust Boundaries
  At every Trust Boundary crossing, the receiving domain MUST independently validate:
  -	Agent Identity
  -	Capability authenticity
  -	Delegation chain
  -	Revocation status
  No implicit trust MAY cross a Trust Boundary.

  10.2 Cross-Domain Delegation
  Delegation across domains MUST follow:
  -	Capability subsetting rules
  -	Explicit delegation chain construction
  -	Independent revocation enforcement
  Shared secrets or inherited credentials MUST NOT be used as delegation mechanisms.

  10.3 Agent-to-Agent Protocol Flow
  Normative multi-agent interaction:
  Agent A → Intent Envelope → Trust Boundary → Agent B
  Agent B → Execution Boundary → Observation → Agent A
  Every stage MUST preserve auditability and authority constraints.

  11. Security Considerations
  11.1 Scope
  This section defines the threat model for AIDP systems, including attacker capabilities, assets, trust boundaries, and normative mitigations. Unless explicitly stated otherwise, all requirements in this section are normative.

  11.2 Assets
  An AIDP deployment MUST treat the following as protected assets:
  -	AIDP Identity Material: Agent Identity objects and their validation artifacts.
  -	Capabilities: Authority objects, including parent/derived relationships and constraint sets.
  -	Delegation Chains: Ordered proof of authority derivation across one or more domains.
  -	Intent Envelopes: Including envelope_id, actor_ref, authority_ref, constraints, and hooks.
  -	Observations: Including attestation and bindings to prior intents.
  -	Audit Trail: Immutable records sufficient to reconstruct intent-execution-observation causality.
  -	Execution Targets: External resources/services whose state can be modified by actions.

  11.3 Trust Boundaries and Security Domains
  AIDP recognizes the following boundaries:
  -	TB-1: Agent Runtime ↔ Execution Boundary
  The Agent Runtime is untrusted for enforcement. The Execution Boundary is the policy enforcement point.
  -	TB-2: Domain A ↔ Domain B
  Cross-domain interactions MUST assume zero implicit trust.
  -	TB-3: Authority Service ↔ Verifiers
  Capability issuance and revocation status MUST be independently verifiable.
  -	TB-4: Observation Channel ↔ Agent
  Observation delivery MUST prevent substitution, replay, and confusion of results.
  Crossing any Trust Boundary MUST trigger independent identity, authority, chain, and revocation validation.

  11.4 Attacker Model
  Attackers MAY possess one or more of the following capabilities:
  -	Network Adversary: Can observe, replay, delay, or reorder messages across a transport.
  -	Malicious Agent: Can generate arbitrary Intent Envelopes and attempt to induce execution.
  -	Compromised Agent Runtime: Can manipulate prompts, local state, tool outputs, and message ordering.
  -	Compromised Execution Target: Can respond with misleading outputs or partial failures.
  -	Insider: Possesses legitimate credentials or access in one domain.
  -	Supply Chain/Implementation Bugs: Leverages parser ambiguities, canonicalization issues, and validation gaps.
  AIDP MUST remain secure against malicious agents and network adversaries. Compromise of the Execution Boundary is out of scope (if it fails, enforcement fails), but audit and containment SHOULD still limit blast radius.

  11.5 Security Goals
  An AIDP system MUST provide:
  -	G-1 Least Privilege: Capabilities constrain what may be executed.
  -	G-2 Non-Repudiation of Control Flow: Audit can reconstruct who requested what and what executed.
  -	G-3 Replay Resistance: Intents and observations cannot be reused to re-trigger actions.
  -	G-4 Delegation Safety: Delegation cannot amplify privileges; revocation propagates.
  -	G-5 Outcome Integrity: Observations are bound to the originating intent and execution.
  -	G-6 Compromise Containment: A compromised agent cannot exceed granted authority.
  -	G-7 Cross-Domain Robustness: No implicit trust crosses domain boundaries.

  11.6 Threats and Mitigations

  11.6.1 Confused Deputy
  Threat: A less-privileged agent induces a more-privileged system/component to perform actions outside the attacker’s authority.
  Mitigations (normative):
  -	The Execution Boundary MUST authorize based solely on validated authority_ref and delegation_chain, not on agent-provided explanations or natural-language intent.
  -	The Execution Boundary MUST verify that the capability subject matches actor_ref (or matches a valid delegation subject in the chain).
  -	Capabilities MUST encode the target resource(s) and permitted action(s) explicitly; wildcards SHOULD be avoided or constrained.

  11.6.2 Privilege Escalation via Delegation
  Threat: An agent delegates authority beyond what it possesses (scope amplification), or a receiver misinterprets delegation semantics.
  Mitigations:
  -	Delegated capabilities MUST be strict subsets of parent capabilities (Subsetting Rule).
  -	Delegation chains MUST be validated end-to-end at execution time.
  -	Receivers MUST reject any chain that contains an invalid or unverifiable link.
  -	Revocation of a parent capability MUST invalidate all derived capabilities.

  11.6.3 Replay of Intent Envelopes
  Threat: Reuse of an Intent Envelope to trigger repeated execution (financial transfers, destructive actions).
  Mitigations:
  -	envelope_id MUST be globally unique and MUST NOT be accepted more than once per relevant replay window.
  -	Execution Boundaries MUST maintain replay state appropriate to the risk profile of the action class.
  -	Constraints SHOULD include explicit idempotency requirements for side-effectful actions.
  -	When an Execution Boundary (EB) receives an Intent Envelope (IE) whose
  envelope_id has already been processed, the EB MUST treat the request
  as a replay and MUST NOT re-execute the intent.

  If a corresponding Observation (OB) has already been produced and is
  still within the EB's observation retention window, the EB SHOULD
  return the previously generated Observation or provide a deterministic
  mechanism for the Agent to retrieve it (e.g., via an observation
  retrieval endpoint).

  A replayed envelope_id MUST NOT result in a new execution or a
  semantically distinct outcome.

  Whether a replayed Intent results in an inline Observation,
  a retrieval pointer, or a REPLAY_DETECTED Problem Details response
  is deployment- and transport-binding-specific. In all cases,
  the EB MUST NOT re-execute the intent.

  11.6.4 Replay or Substitution of Observations
  Threat: An attacker replays a prior Observation or substitutes a different Observation to steer reasoning.
  Mitigations:
  -	Observations MUST include envelope_id and execution_id.
  -	Observations MUST carry an attestation from the Execution Boundary.
  -	Agents MUST reject Observations that do not match an outstanding Intent Envelope.
  -	Agents MUST NOT progress reasoning for an intent until a valid bound Observation is received.

  11.6.5 Parameter Confusion and Canonicalization Attacks
  Threat: Ambiguities in serialization or parsing allow an attacker to smuggle parameters or exploit differences between validators and executors.
  Mitigations:
  -	Implementations MUST define a canonical representation for signing/verifying
  	(even if encoding is out of scope, the “to-be-verified” form MUST be unambiguous).
  -	Validators and executors MUST share identical parsing and validation logic.
  -	Unknown fields in security-relevant sections MUST be rejected or handled by strict extension rules.

  11.6.6 Time-of-Check / Time-of-Use (TOCTOU) on Revocation
  Threat: A capability is valid at validation time but revoked before execution completes; or cache staleness causes use of revoked authority.
  Mitigations:
  -	Execution Boundaries MUST check revocation status at execution time, not solely at receipt time, for high-risk actions.
  -	Revocation mechanisms MUST support near-immediate effect.
  -	Deployments SHOULD define risk tiers: low-risk actions MAY tolerate bounded staleness; high-risk actions MUST NOT.

  11.6.7 Compromised Agent Runtime / Prompt Injection
  Threat: The agent runtime is manipulated so the reasoning engine emits malicious intents or misinterprets observations.
  Mitigations:
  -	Enforcement MUST occur at the Execution Boundary, not in the agent.
  -	Capabilities MUST be constrained such that unintended intents have limited impact.
  -	Observation binding MUST prevent fabricated “success” states.
  -	High-risk capabilities SHOULD require additional policy controls (e.g., approvals) outside agent reasoning.

  11.6.8 Cross-Domain Identity and Issuer Spoofing
  Threat: An attacker forges identities/capabilities from an untrusted issuer or exploits issuer confusion.
  Mitigations:
  -	Domains MUST maintain explicit trust anchors for issuers.
  -	All identities and capabilities MUST include issuer identification.
  -	If issuer validation fails, the intent MUST be rejected.

  11.6.9 Audit Trail Gaps and Non-Attribution
  Threat: Missing logs prevent reconstruction of actions, enabling undetected abuse.
  Mitigations:
  -	Execution Boundaries MUST log Intent Envelope receipt, authorization decision, execution outcome, and Observation emission.
  -	Audit records MUST include envelope_id, execution_id, actor_ref, authority_ref, and a digest of intent_body.

  11.6.10 Denial of Service
  Threat: Flooding the Execution Boundary with envelopes or forcing expensive validation.
  Mitigations:
  -	Implementations SHOULD rate-limit by actor/issuer.
  -	Validation SHOULD be staged (cheap rejection first).
  -	Deployments MAY require preflight checks for costly operations.

  11.7 Residual Risk and Out-of-Scope Conditions
  -	If the Execution Boundary is fully compromised, authorization cannot be trusted. Deployments SHOULD still maintain independent audit and anomaly detection.
  -	If the Execution Target returns misleading results, AIDP can ensure binding/attestation but cannot guarantee target truthfulness beyond attestation scope.
  -	Human approvals, legal policies, and organizational controls are deployment concerns and are not specified by AIDP, though AIDP enables their enforcement hooks.

  11.8 Security Requirements Summary
  Implementations claiming AIDP compliance MUST, at minimum:
  -	Validate identity and issuer trust anchors at each Trust Boundary.
  -	Enforce capabilities and delegation chain subsetting at execution time.
  -	Support revocation with near-immediate effect for high-risk actions.
  -	Provide replay protection for intents and bound observations.
  -	Produce attestable observations linked to intents and executions.
  -	Maintain auditable records sufficient for forensic reconstruction.

  12. Governance & Compliance Considerations
  AIDP deployments SHOULD provide:
  -	Comprehensive audit trails.
  -	Policy-driven revocation procedures.
  -	Capability lifecycle management.
  -	Regulatory compliance support.
  Governance mechanisms MUST remain external to agent reasoning processes.

  13. Extensibility Model
  AIDP is intentionally extensible.
  Extensions MUST:
  -	Preserve all normative validation requirements.
  -	Avoid weakening identity, authority, or revocation semantics.
  -	Declare compatibility with base AIDP semantics.

  14. IANA Considerations
  This document does not require any IANA actions at this time.

  15. Acknowledgements
  The authors acknowledge the emerging agent systems community whose practical challenges motivated the creation of this protocol.

  16. References

  16.1 Normative references

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

  16.2  Informative References

  [GNAP]    Hardt, D., Parecki, A., and T. Lodderstedt,
            "Grant Negotiation and Authorization Protocol",
            Internet-Draft, work in progress,
            draft-ietf-gnap-core.

  [RAR]     Lodderstedt, T., McGloin, M., and P. Hunt,
            "OAuth 2.0 Rich Authorization Requests",
            RFC 9396, August 2023.

  [ZCAP]    Sporny, M., Longley, D., and D. Chadwick,
            "Authorization Capabilities for Linked Data",
            W3C Recommendation,
            https://www.w3.org/TR/vc-data-model/.

  [UCAN]    Fission Codes,
            "User Controlled Authorization Networks (UCAN)",
            https://ucan.xyz/.

  [SCIM]    Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
            and C. Mortimore,
            "System for Cross-domain Identity Management: Core Schema",
            RFC 7643, September 2015.


  17. Wire Format

  17.1 Serialization Families
  AIDP messages MUST be representable in at least one of the following serialization families:
  -	AIDP-JS (JSON): Human-readable encoding for debugging, documentation, and early adoption.
  -	AIDP-CB (CBOR): Binary encoding for production deployments with strict canonicalization.
  An implementation MAY support additional encodings, provided that:
  1.	The semantic model is preserved exactly, and
  2.	A deterministic canonical signing input (Section 16.3) is defined.

  17.2 Message Types
  AIDP defines three primary wire messages:
  -	Intent Envelope (IE): request to execute a governed action.
  -	Observation (OB): bound result of an execution.
  -	Problem Details (PD): structured rejection / error.
  Each message MUST carry:
  -	aidp_version
  -	msg_type
  -	payload

  17.3 Canonical Signing Input
  To prevent canonicalization attacks, AIDP requires an unambiguous signing input.
  Canonical AIDP-JS encoding requires:

  - UTF-8 encoding
  - Deterministic lexicographic ordering of object members
  - No duplicate object member names
  - Deterministic number and string representations
  JSON messages containing duplicate object member names MUST be rejected.
  This rejection MUST occur during parsing, prior to schema validation or
  canonicalization.

  -	For AIDP-CB, the signing input MUST use:
  -	CBOR canonical encoding (deterministic)
  The signing input MUST be computed over the payload object only (not transport metadata). The exact canonicalization profile MUST be declared as canon.

  17.4 Attestations and Proofs
  AIDP supports two proof-bearing fields:
  -	proof: signature or MAC over canonical signing input
  -	proof_chain: optional chain of proofs for delegation links
  Intent Envelopes SHOULD be signed by the Agent Runtime when any
  non-trivial authority is exercised. Observations MUST be attested by
  the Execution Boundary.

  17.5 Common Header
  All AIDP wire messages MUST include:
  -	aidp_version (string, e.g. "1.0-draft")
  -	msg_type (string: "IE" | "OB" | "PD")
  -	canon (string: canonicalization profile identifier)
  -	payload (object)
  -	proof (object, OPTIONAL unless required by local policy)

  18. Wire Schemas
  Below are normative field sets. Implementations MUST reject unknown fields in security-critical sub-objects unless explicitly permitted by the Extensibility Model.

  18.1 Intent Envelope Payload (IE)
  Required:
  -	envelope_id (string/UUID)
  -	timestamp (RFC3339 string)
  -	actor_ref (object)
  -	authority_ref (object)
  -	intent_body (object)
  -	constraints (object)
  -	delegation_chain (array, MAY be empty)
  -	observability_hooks (object)

  18.1.1 actor_ref
  -	agent_id (string)
  -	issuer (string)
  -	identity_ref (string) — dereferenceable URI/URN-like reference (transport-agnostic)

  18.1.2 authority_ref
  -	cap_id (string)
  -	issuer (string)
  -	cap_ref (string) — dereferenceable reference
  -	rev_ref (string) — revocation pointer reference

  18.1.3 intent_body
  -	action (string)
  -	target (object)
  -	parameters (object)
  target MUST include at least:
  -	resource (string)
  -	domain (string) — security domain identifier

  18.1.4 constraints
  Constraints SHOULD include (as applicable):
  -	not_before / not_after (RFC3339)
  -	max_cost (number)
  -	max_uses (integer)
  -	risk_tier (string: "low"|"med"|"high", OPTIONAL but RECOMMENDED)
  -	idempotency_key (string, OPTIONAL)

  The idempotency_key is OPTIONAL and is intended for application-level
  idempotency across transport retries or envelope re-issuance scenarios.

  Protocol-level replay protection and execution idempotency are
  primarily enforced via the envelope_id. Implementations MUST NOT
  require the presence of idempotency_key to provide replay safety or
  result recovery.


  18.1.5 delegation_chain
  Each element MUST include:
  -	cap_id
  -	issuer
  -	cap_ref
  -	parent_cap_id (string)
  -	rev_ref
  -	link_proof (object) — proof binding child to parent

  18.1.6 observability_hooks
  The return_to field specifies the destination for Observation delivery.

  The specified endpoint MUST be pre-registered, pre-approved, or
  otherwise explicitly authorized for the identity identified by
  actor_ref.

  Execution Boundaries MUST NOT deliver Observations to arbitrary or
  unverified endpoints supplied dynamically by an Agent.

  18.2 Observation Payload (OB)
  Required:
  -	envelope_id
  -	execution_id (string)
  -	timestamp (RFC3339)
  -	status (string: accepted|rejected|executed|failed|partially_executed)
  -	result (object, MAY be empty)
  -	side_effects (array, MAY be empty)
  -	attestation (object)

  18.2.1 attestation
  -	boundary_id (string)
  -	issuer (string)
  -	attest_profile (string)
  -	decision (string: authorized|not_authorized|constraint_violation|invalid_chain|revoked|replay)
  -	policy_digest (string) — hash/reference to policy version used
  -	evidence (object, OPTIONAL) — minimal additional evidence (non-sensitive by default)
  Observations MUST be signed/attested by the Execution Boundary (i.e., proof REQUIRED for OB by default).

  18.2.x execution_advice (OPTIONAL)

  The execution_advice object provides non-binding guidance to the Agent
  Runtime regarding retry, backoff, or revision expectations following
  an Observation that does not represent successful execution.

  The execution_advice object MAY include:
  - retriable (boolean):
      Indicates whether retrying the same intent MAY succeed.
  - retry_after_sec (integer):
      Suggested minimum delay before attempting a retry.
  - reason_code (string):
      Machine-readable classification of the failure condition
      (e.g., CONSTRAINT_VIOLATION, BUDGET_EXCEEDED, RATE_LIMITED,
      POLICY_REFUSED, NOT_AUTHORIZED).

  18.3 Problem Details Payload (PD)
  Required:
  -	envelope_id (if applicable)
  -	timestamp
  -	error_code (string)
  -	error_message (string)
  -	details (object, OPTIONAL)
  Recommended error_code values:
  -	INVALID_IDENTITY
  -	UNTRUSTED_ISSUER
  -	REVOKED
  -	INVALID_CAPABILITY
  -	INVALID_DELEGATION_CHAIN
  -	CONSTRAINT_VIOLATION
  -	REPLAY_DETECTED
  -	MALFORMED_MESSAGE
  -	UNSUPPORTED_VERSION

  Problem Details messages MAY include an execution_advice object
  with the same semantics as defined for Observation messages.

  When present, execution_advice applies to the failed Intent Envelope
  identified by envelope_id.

  19. Example Wire Messages (AIDP-JS)

  19.1 Intent Envelope (single-agent → server)
  {
    "aidp_version": "1.0-draft",
    "msg_type": "IE",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:00+02:00",
      "actor_ref": {
        "agent_id": "agent:alpha",
        "issuer": "did:example:issuerA",
        "identity_ref": "urn:aidp:id:issuerA:agent-alpha"
      },
      "authority_ref": {
        "cap_id": "cap:alpha:pay-v1",
        "issuer": "did:example:authA",
        "cap_ref": "urn:aidp:cap:authA:cap-alpha-pay-v1",
        "rev_ref": "urn:aidp:rev:authA:list-01"
      },
      "intent_body": {
        "action": "payment.create",
        "target": { "domain": "svc:payments", "resource": "acct:merchant-123" },
        "parameters": { "amount": 50, "currency": "EUR", "memo": "invoice-8841" }
      },
      "constraints": {
        "not_before": "2026-01-13T09:14:00+02:00",
        "not_after": "2026-01-13T09:19:00+02:00",
        "max_uses": 1,
        "risk_tier": "high",
        "idempotency_key": "idem-3d7f0d"
      },
      "delegation_chain": [],
      "observability_hooks": {
        "delivery_mode": "push",
        "return_to": { "type": "inbox", "ref": "urn:aidp:inbox:agent:alpha" },
        "required_fields": ["envelope_id", "execution_id", "status", "attestation"],
        "timeout_sec": 30
      }
    },
    "proof": {
      "alg": "ed25519",
      "kid": "key:agent-alpha-1",
      "sig": "BASE64URL(...)"
    }
  }

  19.2 Observation (Execution Boundary → agent)
  {
    "aidp_version": "1.0-draft",
    "msg_type": "OB",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "execution_id": "exec-9c2d1a",
      "timestamp": "2026-01-13T09:14:02+02:00",
      "status": "executed",
      "result": { "payment_id": "pay_7712", "state": "captured" },
      "side_effects": [
        { "resource": "acct:merchant-123", "delta": { "captured_eur": 50 } }
      ],
      "attestation": {
        "boundary_id": "boundary:payments-gw-1",
        "issuer": "did:example:paymentsDomain",
        "attest_profile": "AIDP-OB-Attest1",
        "decision": "authorized",
        "policy_digest": "sha256:5d3a...e91"
      }
    },
    "proof": {
      "alg": "ed25519",
      "kid": "key:boundary-payments-1",
      "sig": "BASE64URL(...)"
    }
  }

  19.3 Problem Details (rejection example)
  {
    "aidp_version": "1.0-draft",
    "msg_type": "PD",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:01+02:00",
      "error_code": "REVOKED",
      "error_message": "Capability or identity has been revoked.",
      "details": { "rev_ref": "urn:aidp:rev:authA:list-01", "cap_id": "cap:alpha:pay-v1" }
    },
    "proof": {
      "alg": "ed25519",
      "kid": "key:boundary-payments-1",
      "sig": "BASE64URL(...)"
    }
  }

  20. Example Flows

  20.1 Flow 1 — Single-Agent Action (Agent ↔ Server)
  Goal: Agent requests a state-changing action on an external service with bounded authority.
  Steps (normative):
  1.	Agent Runtime obtains/holds a capability authority_ref.
  2.	Agent produces an Intent Envelope (IE) referencing actor_ref and authority_ref.
  3.	Execution Boundary validates: identity, issuer trust anchors, capability scope, revocation, constraints, replay.
  4.	Execution Boundary executes the action on the target service.
  5.	Execution Boundary emits an Observation (OB) bound to envelope_id and execution_id.
  6.	Agent MUST NOT proceed for that intent until OB is received and validated.
  Key security properties:
  -	Enforcement at Execution Boundary, not the LLM
  -	Replay resistance via envelope_id
  -	Outcome integrity via OB attestation

  20.2 Flow 2 — Delegation (Agent A → Agent B → Execution)
  Goal: Agent A delegates limited authority to Agent B to perform a specific action.
  Steps:
  1.	Agent A possesses parent capability cap:A0.
  2.	Authority Service issues delegated capability cap:B1 with:
  -	parent_cap_id = cap:A0
  -	scope subset (e.g., only resource=X, only max_uses=1, only within 2 minutes)
  3.	Agent A sends IE to Agent B with delegation_chain = [cap:B1 link proof ...]
  4.	Agent B either:
  -	accepts responsibility and forwards IE to its Execution Boundary, or
  -	rejects (policy/local risk)
  5.	Execution Boundary validates entire chain end-to-end (including parent/child linkage proofs).
  6.	Execution produces OB, returned to the return_to hook (Agent A and/or B depending on hook policy).
  Key security properties:
  -	No credential sharing
  -	Subsetting rule enforced at execution
  -	Revocation propagates along chain

  20.3 Flow 3 — Revocation Mid-Flight (TOCTOU)
  Goal: Capability revoked after IE issuance but before execution finalization.
  Steps:
  1.	IE is received and preliminarily validated.
  2.	Before executing high-risk action, Execution Boundary MUST re-check revocation status (per risk tier/policy).
  3.	If revoked, execution MUST abort and PD returned with REVOKED.
  4.	Audit record MUST note decision and revocation evidence used.
  Key security properties:
  -	Near-immediate revocation effect
  -	Clear failure semantics and auditability

  20.4 Flow 4 — Observation Substitution Attempt
  Goal: Network attacker tries to replay an old OB to trick the agent.
  Steps:
  1.	Attacker replays OB with mismatched or already-settled envelope_id.
  2.	Agent validates OB proof and checks if envelope_id is outstanding.
  3.	Agent MUST reject OB if:
  o	envelope_id not outstanding, or
  o	OB proof invalid, or
  o	attestation issuer untrusted
  4.	Agent continues waiting or initiates recovery (out of scope).
  Key security properties:
  -	OB binding prevents confusion
  -	Agent loop does not advance without valid OB

  20.5 Flow 5 — Multi-Domain Boundary Crossing
  Goal: Agent in Domain A requests execution in Domain B.
  Steps:
  1.	Domain B applies TB rules: zero implicit trust.
  2.	Domain B validates issuer trust anchors for identities and capabilities.
  3.	Domain B validates revocation pointers accessible/acceptable under its policy.
  4.	If any issuer untrusted, reject with UNTRUSTED_ISSUER.

  21. Reference Architecture

  21.1 Overview
  This section defines a reference architecture for AIDP deployments. The architecture is model-agnostic (LLM vendor-independent) and transport-agnostic. It separates reasoning from enforcement and binds execution outcomes to originating intents.
  AIDP systems MUST implement an Execution Boundary as the enforcement point. Agent reasoning components MUST NOT be relied upon for authorization, revocation, replay prevention, or audit integrity.

  21.2 Logical Components
  An AIDP deployment consists of the following logical components. Components MAY be co-located or distributed.
  1.	Reasoning Engine (RE)
  Produces Intent Envelopes and consumes Observations. (Often an LLM, but not required.)
  2.	Agent Runtime (AR)
  Hosts the RE; manages local state, memory, and tool mediation. The AR is not a policy enforcement point.
  3.	Execution Boundary (EB)
  Policy enforcement and action execution component. Validates identity/capabilities/delegation, checks revocation, prevents replay, executes actions, and attests Observations.
  4.	Authority Service (AS)
  Issues Capabilities, manages lifecycle, and provides revocation status via rev_ref.
  5.	Identity Provider / Issuer (IdP)
  Issues Agent Identity artifacts referenced by actor_ref.
  6.	Observation Channel (OC)
  Delivers Observations to agents via push and/or pull. (e.g., inbox, queue, webhook)
  7.	Audit Log (AL)
  Append-only event record of intent receipt, authorization decisions, execution results, and observation emission.
  8.	Execution Targets (ET)
  External systems acted upon (APIs, services, websites via automation, databases, etc.).

  21.3 Trust Boundaries
  AIDP defines explicit trust boundaries. Crossing a trust boundary MUST trigger independent validation.
  -	TB-AR/EB: Agent Runtime to Execution Boundary
  AR is untrusted for enforcement; EB MUST validate all incoming IEs regardless of origin.
  -	TB-Domain: Cross-domain boundary
  Identity, capabilities, issuer trust, and revocation MUST be revalidated in the receiving domain.
  -	TB-OC: Observation Channel boundary
  Observations MUST be attested by EB and verified by the Agent Runtime/RE.

  21.4 Reference Architecture Diagram
  +--------------------- Domain A ----------------------+
  |                                                     |
  |  +-----------+      +----------------------------+  |
  |  | Reasoning  |      | Agent Runtime (AR)        |  |
  |  | Engine (RE)|<---->| - builds IE payload       |  |
  |  +-----------+      | - validates OB proofs      |  |
  |        ^            | - manages local state      |  |
  |        |            +--------------+-------------+  |
  |        |                           | IE (AIDP)      |
  |        |                           v                 |
  |  +-----+-----+          TB-AR/EB  +----------------+|
  |  | Observation|<------------------| Execution       ||
  |  | Channel (OC)|   OB (AIDP)      | Boundary (EB)   ||
  |  +-----------+-+                  | - validates IE  ||
  |              |                    | - checks rev    ||
  |              |                    | - replay store  ||
  |              |                    | - executes      ||
  |              |                    | - attests OB    ||
  |              |                    +---+---------+---+|
  |              |                        |         |    |
  |              |                        |         |    |
  |              |                    +---v--+   +--v---+|
  |              |                    | Audit |   | Auth ||
  |              |                    | Log   |   |Svc(AS)|
  |              |                    +------+   +-------+|
  |              |                                 ^      |
  |              |                                 | rev_ref
  |              |                                 |
  |              |                           +-----+-----+
  |              |                           | Identity  |
  |              |                           | Issuer(IdP)|
  |              |                           +-----------+
  |              |
  |              | actions
  |              v
  |        +----------------+
  |        | Execution      |
  |        | Targets (ET)   |
  |        +----------------+
  +-----------------------------------------------------+

  21.5 Normative Interfaces
  This section defines the conceptual interfaces between components.

  21.5.1 IE Submission Interface (AR → EB)
  -	Input: AIDP Intent Envelope (IE)
  -	Output: Immediate PD or async OB (or both if policy allows)
  EB MUST implement:
  -	Identity validation for actor_ref
  -	Capability validation for authority_ref
  -	Delegation chain validation
  -	Revocation checks via rev_ref
  -	Replay detection for envelope_id
  -	Constraint enforcement
  AR MAY implement preflight validation, but EB validation is authoritative.

  21.5.2 Authority Resolution Interface (EB ↔ AS)
  -	EB dereferences cap_ref and rev_ref
  -	EB verifies:
  -	capability authenticity
  -	scope/constraints
  -	revocation status (including parents in chain)
  -	issuer trust anchor
  AS MUST support:
  -	capability retrieval (or verification artifacts)
  -	revocation status lookup with bounded latency for high-risk actions

  21.5.3 Identity Validation Interface (EB ↔ IdP)
  -	EB dereferences identity_ref and validates issuer trust
  -	EB checks identity revocation status
  IdP MUST support:
  -	identity verification artifacts
  -	revocation status

  21.5.4 Observation Delivery Interface (EB → OC → AR)
  -	EB emits Observation (OB) with attestation proof
  -	OC delivers via:
  -	push (webhook/queue) and/or
  -	pull (inbox retrieval)
  AR MUST verify:
  -	OB proof (attestation)
  -	envelope_id matches outstanding intent
  -	issuer trust anchor for the EB attestation

  21.5.5 Audit Interface (EB → AL)
  EB MUST record:
  -	receipt of IE (digest)
  -	authorization decision and reasons
  -	execution_id
  -	status/outcome
  -	emitted OB digest
  AL SHOULD be append-only. Tamper-evidence is RECOMMENDED.

  21.6 Data Flow Specifications

  21.6.1 Standard Single-Domain Flow
  RE -> AR: propose action
  AR -> EB: IE(envelope_id, actor_ref, authority_ref, constraints, hooks)
  EB -> AS/IdP: validate capability + identity + revocation
  EB -> ET: execute action
  EB -> AL: write audit events
  EB -> OC: emit OB(attested)
  OC -> AR: deliver OB
  AR -> RE: provide validated OB for next-step reasoning

  21.6.2 Cross-Domain Flow (Domain A → Domain B)
  Domain A: AR_A -> EB_B (IE)
            (crosses TB-Domain)
  Domain B: EB_B validates issuers/trust anchors independently
            EB_B executes, attests OB
            OB delivered back per hooks (possibly to OC_A and/or OC_B)
  Receiving domains MUST NOT assume trust in issuer sets unless explicitly configured.

  21.7 Policy Enforcement Points
  EB is the required enforcement point. The following controls MUST be enforced at EB:
  -	Revocation checks (risk-tier dependent strictness)
  -	Replay protection
  -	Constraint verification (time, uses, scope)
  -	Delegation chain integrity
  -	Audit emission
  AR/RE controls are advisory only.

  21.8 Minimal Deployment Profiles

  21.8.1 Minimal Profile (Single Domain)
  Required: RE, AR, EB, AS (or embedded capability verifier), OC, AL
  Optional: external IdP (can be embedded issuer)

  21.8.2 Multi-Domain Profile
  Required: EB and trust anchor policy per domain, cross-domain issuer validation, revocation accessibility policy, OC bridging rules.

  21.9 Failure Modes and Required Behaviors
  -	If AS/IdP is unreachable for a high-risk action, EB MUST fail closed (reject) unless local policy explicitly permits bounded staleness.
  -	If OB delivery fails, EB SHOULD support pull-based retrieval via OC to avoid “lost observations”.
  -	If replay is detected, EB MUST reject with REPLAY_DETECTED and log the attempt.

  22. Concrete Transport Binding: HTTP (AIDP-HTTP)

  22.1 Overview
  This section specifies a concrete transport binding for AIDP using HTTP. It defines:
  -	submission of Intent Envelopes (IE) to an Execution Boundary (EB),
  -	delivery/retrieval of Observations (OB),
  -	structured error reporting (PD),
  -	minimal requirements for replay safety and correlation.
  This binding is compatible with AIDP-JS (JSON) payloads as specified in Sections 16–19. AIDP-CB (CBOR) MAY be supported via content negotiation.

  22.2 Resources and Roles
  -	Client: Agent Runtime (AR) or Agent-facing proxy.
  -	Server: Execution Boundary (EB).
  -	Observation Channel: either:
  -	push: EB calls an AR webhook, or
  -	pull: AR polls an EB-hosted inbox.

  22.3 Media Types
  Implementations MUST support JSON.
  -	IE: application/aidp+json; msg=IE
  -	OB: application/aidp+json; msg=OB
  -	PD: application/aidp+json; msg=PD
  Servers MAY additionally support CBOR:
  -	application/aidp+cbor; msg=IE|OB|PD

  22.4 Common HTTP Headers
  Clients and servers MUST use:
  -	Content-Type: as above
  -	Accept: one or more supported AIDP media types
  The following headers are RECOMMENDED:
  -	Idempotency-Key: value of constraints.idempotency_key (when present)
  -	X-AIDP-Envelope-ID: mirrors payload.envelope_id (for tracing; not authoritative)

  22.5 Authorization at HTTP Layer
  AIDP authorization is enforced via authority_ref/capabilities at the AIDP layer. However, the HTTP channel itself MUST be authenticated to prevent anonymous flooding and to enable policy decisions.
  EB deployments MUST require at least one of:
  -	mutual TLS (mTLS), or
  -	OAuth 2.0 Bearer token, or
  -	another mutually authenticated mechanism.
  Important: HTTP-layer auth MUST NOT be treated as sufficient authorization for actions. EB MUST still validate AIDP identity/capability/delegation/revocation per the core spec.

  22.6 Endpoint: Submit Intent Envelope
  POST /v1/aidp/intents
  Request body: an IE message.
  Success responses:
  -	202 Accepted: intent accepted for processing; OB will be delivered via hooks (push) and/or made available for pull.
  -	200 OK: intent executed synchronously and OB is returned in the response body (allowed for low latency operations).
  Failure responses:
  -	400 Bad Request: malformed AIDP message (PD returned)
  -	401 Unauthorized: HTTP-layer auth failure (PD OPTIONAL; may be plain HTTP)
  -	403 Forbidden: AIDP authorization failure (PD returned)
  -	409 Conflict: replay detected / envelope_id reuse (PD returned)
  -	415 Unsupported Media Type: unsupported encoding
  -	429 Too Many Requests: rate limiting (PD OPTIONAL but RECOMMENDED)
  -	500/503: server failure / dependency failure (PD RECOMMENDED)
  Response body:
  -	For 200: an OB
  -	For 202: either empty or a minimal acknowledgment object (OPTIONAL). If included, it MUST NOT claim execution success.
  -	For failures: a PD SHOULD be returned.

  22.6.1 Correlation Rules
  -	EB MUST treat payload.envelope_id as authoritative.
  -	If X-AIDP-Envelope-ID is present and does not match the payload, EB MUST reject with MALFORMED_MESSAGE.

  22.6.2 Synchronous vs Asynchronous Execution
  EB MAY execute synchronously (200) when:
  -	action is low-risk and low-latency, and
  -	revocation checks can be performed inline.
  Otherwise EB SHOULD default to 202 + asynchronous OB.

  22.7 Endpoint: Retrieve Observation (Pull Mode)
  GET /v1/aidp/observations/{envelope_id}
  Returns:
  -	200 OK + OB if available
  -	404 Not Found if unknown (or not yet available)
  -	410 Gone if envelope_id is known but observation expired/garbage-collected (PD RECOMMENDED)
  -	409 Conflict if multiple observations exist and client must page (see 21.7.1)
  EB SHOULD retain observations for a configurable retention window.

  Execution Boundaries MUST retain Observations for a deployment-defined
  retention period sufficient to allow Agents to recover results in the
  presence of delivery failure, Agent restarts, or network partition.

  If an Observation cannot be returned inline due to replay detection,
  the EB MUST expose a deterministic retrieval mechanism bound to the
  envelope_id.


  22.7.1 Multiple Observations per Envelope
  In advanced deployments, an envelope may yield multiple OBs (e.g., accepted then executed). If multiple are retained, EB MUST support:
  GET /v1/aidp/observations?envelope_id=...&after=...&limit=...
  Returning either:
  -	a single latest OB (default), or
  -	a list of OBs when mode=all.

  22.8 Endpoint: Observation Inbox (Pull Mode, Queue Semantics)
  GET /v1/aidp/inbox
  Query params:
  -	cursor (opaque)
  -	limit (1–100)
  Returns 200 OK with:
  -	items: array of OB messages
  -	next_cursor: cursor for pagination
  EB MUST only deliver observations intended for the authenticated caller per observability_hooks.return_to.

  22.9 Observation Delivery (Push Mode)
  If observability_hooks.delivery_mode = "push", return_to MUST include a webhook URL reference or a resolvable endpoint reference.
  EB will deliver via:
  POST <agent_webhook_url>
  Body: an OB message.
  Expected responses by AR:
  -	200 OK: received and accepted
  -	409 Conflict: duplicate delivery (idempotent accept)
  -	410 Gone: endpoint deprecated (EB SHOULD fall back to pull if configured)
  EB MUST implement retries with backoff. Duplicate deliveries MUST be possible; AR MUST handle idempotently using (envelope_id, execution_id).

  Execution Boundaries MUST enforce SSRF protections when performing
  Observation delivery, including but not limited to:

  - Rejection of loopback, link-local, private, or non-globally routable
    addresses
  - Domain allowlisting or identity-bound endpoint registration
  - Protection against DNS rebinding

  If an endpoint cannot be validated or authorized, the EB MUST fall back
  to inbox-based or pull-based Observation retrieval.

  22.10 Problem Details over HTTP
  PD is carried as the response body for AIDP-layer errors.
  Mapping guidance:
  -	INVALID_IDENTITY, UNTRUSTED_ISSUER, REVOKED, INVALID_DELEGATION_CHAIN → 403
  -	CONSTRAINT_VIOLATION → 403 (or 409 if semantic conflict)
  -	REPLAY_DETECTED → 409
  -	MALFORMED_MESSAGE, UNSUPPORTED_VERSION → 400
  -	UNSUPPORTED_MEDIA_TYPE → 415

  22.11 HTTP Caching
  Responses containing OB or PD MUST include headers preventing intermediary caching:
  -	Cache-Control: no-store

  22.12 Transport-Level Integrity and Confidentiality
  AIDP-HTTP MUST be carried over TLS. mTLS is RECOMMENDED for high-risk tiers.

  22.13 Minimal HTTP Sequence Examples

  22.13.1 Submit IE (Async)
  1.	AR → EB
  POST /v1/aidp/intents with IE
  EB → AR
  202 Accepted
  2.	EB → AR webhook
  POST https://agent.example/aidp/ob with OB
  AR → EB
  200 OK

  22.13.2 Submit IE (Sync)
  AR → EB
  POST /v1/aidp/intents with IE
  EB → AR
  200 OK with OB

  22.13.3 Pull OB
  AR → EB
  GET /v1/aidp/observations/{envelope_id}
  EB → AR
  200 OK with OB (or 404 Not Found until ready)

  22.14 Full HTTP Examples
  All of the above assume:
  -	TLS active
  -	Content-Type: application/aidp+json; msg=...
  -	canon: AIDP-JS-Canon1
  -	sig are placeholders

  22.14.1 Async Success (202 + webhook OB)
  Request (AR → EB)
  POST /v1/aidp/intents HTTP/1.1
  Host: eb.payments.example
  Content-Type: application/aidp+json; msg=IE
  Accept: application/aidp+json; msg=OB, application/aidp+json; msg=PD
  Idempotency-Key: idem-3d7f0d
  X-AIDP-Envelope-ID: 0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10
  Authorization: Bearer eyJ... (transport auth; not sufficient for AIDP auth)
  Cache-Control: no-store

  {
    "aidp_version": "1.0-draft",
    "msg_type": "IE",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:00+02:00",
      "actor_ref": { "agent_id": "agent:alpha", "issuer": "did:example:issuerA", "identity_ref": "urn:aidp:id:issuerA:agent-alpha" },
      "authority_ref": { "cap_id": "cap:alpha:pay-v1", "issuer": "did:example:authA", "cap_ref": "urn:aidp:cap:authA:cap-alpha-pay-v1", "rev_ref": "urn:aidp:rev:authA:list-01" },
      "intent_body": {
        "action": "payment.create",
        "target": { "domain": "svc:payments", "resource": "acct:merchant-123" },
        "parameters": { "amount": 50, "currency": "EUR", "memo": "invoice-8841" }
      },
      "constraints": {
        "not_before": "2026-01-13T09:14:00+02:00",
        "not_after": "2026-01-13T09:19:00+02:00",
        "max_uses": 1,
        "risk_tier": "high",
        "idempotency_key": "idem-3d7f0d"
      },
      "delegation_chain": [],
      "observability_hooks": {
        "delivery_mode": "push",
        "return_to": { "type": "webhook", "ref": "https://agent.example/aidp/ob" },
        "required_fields": ["envelope_id", "execution_id", "status", "attestation"],
        "timeout_sec": 30
      }
    },
    "proof": { "alg": "ed25519", "kid": "key:agent-alpha-1", "sig": "BASE64URL(...)" }
  }
  Response (EB → AR)
  HTTP/1.1 202 Accepted
  Cache-Control: no-store
  Content-Type: application/aidp+json; msg=PD

  {
    "aidp_version": "1.0-draft",
    "msg_type": "PD",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:01+02:00",
      "error_code": "ACCEPTED_ASYNC",
      "error_message": "Accepted for processing; observation will be delivered via hooks.",
      "details": { "estimated": "not_provided" }
    },
    "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
  }
  Note: use of PD as “ack” for 202 to have a structured message. Alternatively it can be blank.
  Webhook Delivery (EB → AR endpoint)
  POST /aidp/ob HTTP/1.1
  Host: agent.example
  Content-Type: application/aidp+json; msg=OB
  Accept: application/aidp+json; msg=PD
  Cache-Control: no-store
  X-AIDP-Delivery-ID: deliv-77a1
  X-AIDP-Envelope-ID: 0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10

  {
    "aidp_version": "1.0-draft",
    "msg_type": "OB",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "execution_id": "exec-9c2d1a",
      "timestamp": "2026-01-13T09:14:02+02:00",
      "status": "executed",
      "result": { "payment_id": "pay_7712", "state": "captured" },
      "side_effects": [{ "resource": "acct:merchant-123", "delta": { "captured_eur": 50 } }],
      "attestation": {
        "boundary_id": "boundary:payments-gw-1",
        "issuer": "did:example:paymentsDomain",
        "attest_profile": "AIDP-OB-Attest1",
        "decision": "authorized",
        "policy_digest": "sha256:5d3a...e91"
      }
    },
    "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
  }
  Webhook Response (AR → EB)
  HTTP/1.1 200 OK
  Cache-Control: no-store
  Content-Type: application/aidp+json; msg=PD

  {
    "aidp_version": "1.0-draft",
    "msg_type": "PD",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:03+02:00",
      "error_code": "DELIVERY_OK",
      "error_message": "Observation received."
    }
  }

  22.14.2 Revoked Capability (403 + PD)
  HTTP/1.1 403 Forbidden
  Cache-Control: no-store
  Content-Type: application/aidp+json; msg=PD

  {
    "aidp_version": "1.0-draft",
    "msg_type": "PD",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:01+02:00",
      "error_code": "REVOKED",
      "error_message": "Capability or identity has been revoked.",
      "details": {
        "rev_ref": "urn:aidp:rev:authA:list-01",
        "cap_id": "cap:alpha:pay-v1",
        "decision": "revoked"
      }
    },
    "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
  }

  22.14.3 Replay Detected (409 + PD)
  HTTP/1.1 409 Conflict
  Cache-Control: no-store
  Content-Type: application/aidp+json; msg=PD

  {
    "aidp_version": "1.0-draft",
    "msg_type": "PD",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:14:01+02:00",
      "error_code": "REPLAY_DETECTED",
      "error_message": "Envelope ID has already been processed.",
      "details": { "replay_window": "configured", "first_seen": "2026-01-13T09:14:00+02:00" }
    },
    "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
  }

  22.14.4 Constraint Violation (403 + PD)
  HTTP/1.1 403 Forbidden
  Cache-Control: no-store
  Content-Type: application/aidp+json; msg=PD

  {
    "aidp_version": "1.0-draft",
    "msg_type": "PD",
    "canon": "AIDP-JS-Canon1",
    "payload": {
      "envelope_id": "0f2e3c1a-9b9a-4a8c-8c2b-2f3b9f3c5a10",
      "timestamp": "2026-01-13T09:20:10+02:00",
      "error_code": "CONSTRAINT_VIOLATION",
      "error_message": "Constraint check failed.",
      "details": {
        "violations": [
          { "field": "constraints.not_after", "reason": "expired" },
          { "field": "constraints.max_uses", "reason": "already_consumed" }
        ]
      }
    },
    "proof": { "alg": "ed25519", "kid": "key:boundary-payments-1", "sig": "BASE64URL(...)" }
  }

  22.15 Webhook Verification Model (Push Observations)

  22.15.1 Trust Anchors
  Each Agent Runtime (AR) MUST maintain a set of trust anchors for validating incoming Observation deliveries. These trust anchors MUST include:
  -	Approved issuers of Execution Boundary (EB) attestations (e.g., did:example:paymentsDomain)
  -	(OPTIONAL) Explicit allowlists of specific EB instances identified by boundary_id
  The AR MUST reject any webhook-delivered Observation if:
  -	attestation.issuer is not included in the trust anchors, or
  -	the public key referenced by proof.kid cannot be resolved for the declared issuer, or
  -	the boundary_id is disallowed by local policy.

  22.15.2 Required Verification Steps (AR-side)
  Upon receipt of an Observation via webhook, the Agent Runtime MUST perform the following steps, in order:
  1.	Parse and schema-validate the Observation message using strict validation rules.
  2.	Verify the attestation proof (proof) over the canonical signing input.
  3.	Validate issuer trust, ensuring attestation.issuer is trusted.
  4.	Bind the Observation to an outstanding Intent:
  o	payload.envelope_id MUST correspond to a currently pending Intent Envelope, otherwise the Observation MUST be rejected or quarantined according to policy.
  5.	Enforce replay protection:
  o	The tuple (envelope_id, execution_id) MUST be accepted at most once.
  6.	OPTIONAL but RECOMMENDED: Verify attestation.policy_digest against a locally known policy registry when available.
  If any verification step fails, the AR MUST NOT accept the Observation and MUST respond with a non-2xx HTTP status code.

  22.15.3 Delivery Idempotency
  Execution Boundaries MUST treat webhook delivery as retry-safe.
  Agent Runtimes MUST process webhook Observations idempotently, keyed by:
  (envelope_id, execution_id)
  If a duplicate delivery is received, the AR MUST NOT re-apply any state transition and SHOULD return either:
  -	409 Conflict (duplicate), or
  -	200 OK with a Problem Details payload indicating duplicate acceptance.

  22.15.4 Webhook Channel Authentication
  In addition to cryptographic attestation inside the Observation itself, the webhook transport channel SHOULD be protected using:
  -	Mutual TLS (mTLS), or
  -	An HTTP authentication mechanism that cryptographically binds the EB identity to the TLS session.
  Channel-level authentication mitigates denial-of-service attacks and prevents unauthenticated injection of traffic toward the AR.

  22.15.5 Anti-Substitution Rules
  The Agent Runtime MUST enforce the following anti-substitution rules:
  -	The payload.envelope_id in the Observation MUST correspond exactly to the pending Intent Envelope.
  -	If the AR maintains a local digest of the submitted Intent Envelope, it SHOULD ensure the received Observation corresponds to that digest entry.
  -	All fields declared in observability_hooks.required_fields MUST be present before the Observation is accepted.
  Failure of any rule MUST cause the Observation to be rejected.

  22.15.6 Error Responses from Webhook Endpoint
  The AR webhook endpoint MUST use the following status codes:
  HTTP Code	Meaning
  200	Observation accepted
  409	Duplicate delivery
  400	Malformed Observation
  403	Untrusted issuer or invalid proof
  410	Endpoint deprecated
  429	Rate limited

  22.15.7 Fallback to Pull Mode
  If repeated webhook deliveries fail, the Execution Boundary SHOULD:
  -	Retain the Observation for retrieval via GET /v1/aidp/observations/{envelope_id}, and
  -	Optionally emit a Problem Details message indicating push delivery failure.

  22.16 Reference Validation Pipeline
  This section defines the normative validation and execution pipeline that every AIDP-compliant Execution Boundary (EB) and Agent Runtime (AR) MUST implement.
  Any deviation from this sequence constitutes a protocol violation.

  22.16.1 Execution Boundary Validation Pipeline
  Upon receipt of an Intent Envelope over HTTP, the EB MUST execute the following steps in order:
  1. Transport Authentication
  2. Message Parsing
  3. Canonicalization
  4. Proof Verification
  5. Schema Validation
  6. Identity Validation
  7. Capability Resolution
  8. Delegation Chain Validation
  9. Revocation Checks
  10. Constraint Enforcement
  11. Replay Protection
  12. Authorization Decision
  13. Execution
  14. Observation Construction
  15. Attestation & Emission
  16. Audit Recording

  22.16.2 Detailed Step Semantics

  1. Transport Authentication
  The EB MUST verify HTTP-layer authentication (mTLS, OAuth, etc.) and reject unauthenticated clients.
  Transport authentication does not grant execution authority.

  2. Message Parsing
  The EB MUST parse the incoming message strictly.
  Malformed messages MUST be rejected with MALFORMED_MESSAGE.
  During message parsing, Execution Boundaries and Agent Runtimes MUST use
  a JSON parser configuration that detects and rejects duplicate object
  member names.

  Messages that contain duplicate keys MUST be rejected before any
  validation, canonicalization, or cryptographic verification is
  performed.


  3. Canonicalization
  The EB MUST canonicalize the payload using the declared canon profile.
  Failure MUST abort processing.

  4. Proof Verification
  If present, proof MUST be verified against the canonical payload.
  Failure MUST abort processing.

  5. Schema Validation
  The EB MUST validate the payload against the AIDP schema for the declared message type.
  Unknown fields in security-critical objects MUST cause rejection.

  6. Identity Validation
  The EB MUST resolve and validate actor_ref.identity_ref and issuer trust.
  Failures MUST result in INVALID_IDENTITY or UNTRUSTED_ISSUER.

  7. Capability Resolution
  The EB MUST resolve authority_ref.cap_ref, validate issuer trust, and load associated constraints.

  8. Delegation Chain Validation
  If delegation_chain is present, the EB MUST:
  -	Validate every link’s proof
  -	Enforce subsetting rules
  -	Verify parent-child relationships
  -	Reject any amplification of authority
  Failures MUST result in INVALID_DELEGATION_CHAIN.

  9. Revocation Checks
  The EB MUST consult all rev_ref references (identity, capability, delegation parents).
  For high-risk actions, revocation checks MUST be performed immediately prior to execution.

  10. Constraint Enforcement
  All constraints MUST be enforced:
  -	time windows
  -	usage limits
  -	resource scope
  -	risk tier policies
  Failures MUST result in CONSTRAINT_VIOLATION.

  11. Replay Protection
  The EB MUST verify that envelope_id has not been previously accepted.
  Replay MUST result in REPLAY_DETECTED.

  12. Authorization Decision
  If and only if all prior steps succeed, the EB MUST authorize the action.

  13. Execution
  The EB executes the action on the target system.
  Execution failures MUST still produce an Observation with status = failed.

  14. Observation Construction
  The EB MUST construct an Observation bound to:
  -	envelope_id
  -	execution_id
  -	decision
  -	result
  -	side effects
  -	applied policy

  15. Attestation & Emission
  The EB MUST:
  -	attach an attestation
  -	sign the Observation
  -	deliver it via the configured Observation Channel

  16. Audit Recording
  The EB MUST record:
  -	envelope digest
  -	decision
  -	execution_id
  -	final status
  -	emitted Observation digest

  22.16.3 Agent Runtime Validation Pipeline (OB/PD)
  Upon receiving an Observation or Problem Details message, the AR MUST perform:
  1. Parse & Schema Validate
  2. Canonicalize
  3. Verify Attestation Proof
  4. Verify Issuer Trust
  5. Bind to Outstanding Intent
  6. Enforce Replay Protection
  7. Accept and Release Intent
  8. Failure Classification and Retry Suppression

  If an Observation or Problem Details message indicates a deterministic
  failure (including but not limited to CONSTRAINT_VIOLATION,
  NOT_AUTHORIZED, POLICY_REFUSED, or any non-retriable execution_advice),
  the Agent Runtime MUST NOT re-issue an Intent Envelope whose canonical
  payload is identical to the failed intent.

  The Agent Runtime MUST either:
  - revise the intent semantics (e.g., constraints or intent_body), or
  - abort the reasoning path, or
  - require explicit operator or policy override.
  To enforce retry suppression deterministically, the Agent Runtime
  SHOULD maintain a cache of recently failed intent digests, computed as
  a hash over the canonical signing input of the Intent Envelope payload.

  Re-issuance of an Intent with an identical digest following a
  deterministic failure SHOULD be suppressed for a deployment-defined
  cooldown period.

  If any step fails, the Observation MUST be rejected and MUST NOT advance agent reasoning.

  Deterministic failures are failures for which re-execution of an
  identical intent is not expected to yield a different outcome, absent
  a change in constraints, authority, or policy state.

  Examples include constraint violations, authorization failures, and
  explicit policy refusals.

  22.16.4 Deterministic Agent Loop Guarantee
  An agent loop is compliant if and only if:
  No agent reasoning step that causally depends on an Intent Envelope
  occurs without a validated Observation for that Intent.

  22.16.5 Minimal Conformance Checklist
  An implementation claiming AIDP-HTTP compliance MUST implement:
  -	full EB pipeline
  -	full AR pipeline
  -	replay store
  -	revocation resolver
  -	attestation verification
  -	audit logging

  23. AIDP Conformance Test Suite — Outline

  23.1 Purpose
  This document defines the test framework for validating whether an implementation is compliant with the AIDP specification.
  It enables:
  -	certification of implementations,
  -	interoperability between vendors,
  -	objective security verification.

  23.2. Certification Levels
  Level 1 — AIDP-Core
  Minimal functional compliance.
  Level 2 — AIDP-Secure
  Includes full security & revocation semantics.
  Level 3 — AIDP-Enterprise
  Includes auditability, cross-domain, governance & recovery.

  23.3 Test Domains
  Domain	        Focus
  -----------     -------------------------
  Identity	Agent identity validation
  Authority	Capability enforcement
  Delegation	Subsetting & chain validation
  Revocation	Immediate invalidation

  Intent	Schema & canonicalization
  Execution	Enforcement correctness
  ------------    ------------------------
  Observation	Binding & integrity
  Replay	        Duplicate detection
  Audit	        Traceability & non-repudiation
  Cross-Domain	Trust boundary handling

  23.4 Core Test Categories

  23.4.1 Identity & Trust
  -	T-ID-01: Reject invalid issuer
  -	T-ID-02: Reject expired identity
  -	T-ID-03: Enforce trust anchors
  -	T-ID-04: Revalidate across trust boundary

  23.4.2 Capability & Authority
  -	T-AUTH-01: Enforce action scope
  -	T-AUTH-02: Enforce resource scope
  -	T-AUTH-03: Enforce constraints
  -	T-AUTH-04: Reject capability amplification

  23.4.3 Delegation
  -	T-DEL-01: Validate delegation chain
  -	T-DEL-02: Reject broken chain
  -	T-DEL-03: Enforce subsetting rule
  -T-DEL-04: Revoke parent invalidates children

  23.4.4 Revocation
  -	T-REV-01: Immediate revocation enforcement
  -	T-REV-02: Revocation after acceptance but before execution
  -	T-REV-03: Revocation during execution (high risk path)

  23.4.5 Intent Envelope
  -	T-IE-01: Canonicalization correctness
  -	T-IE-02: Proof verification
  -	T-IE-03: Reject malformed envelope
  -	T-IE-04: Enforce required fields

  23.4.6 Execution & Enforcement
  -	T-EX-01: Reject without valid authority
  -	T-EX-02: Enforce constraints before execution
  -	T-EX-03: Execute only after full validation
  -	T-EX-04: Reject on replay

  23.4.7 Observation & Feedback Binding
  -	T-OB-01: Bind OB to correct envelope_id
  -	T-OB-02: Reject mismatched OB
  -	T-OB-03: Enforce deterministic agent loop
  -	T-OB-04: Reject unsigned OB

  23.4.8 Replay & Ordering
  -	T-RPL-01: Detect duplicate envelope_id
  -	T-RPL-02: Reject reused execution_id
  -	T-RPL-03: Maintain replay window

  23.4.9 Audit & Compliance
  -	T-AUD-01: Record full action trace
  -	T-AUD-02: Reconstruct causal chain
  -	T-AUD-03: Verify non-repudiation

  23.4.10 Cross-Domain & Federation
  -	T-XD-01: Enforce trust boundary
  -	T-XD-02: Reject untrusted issuer
  -	T-XD-03: Preserve delegation semantics across domains

  23.5 Failure Injection Tests
  -	Network failure mid-execution
  -	Revocation during processing
  -	Observation delivery failure
  -	Duplicate webhook delivery
  -	Corrupted attestation
  -	Malicious agent input

  23.6 Required Artifacts for Certification
  An implementation seeking certification MUST provide:
  -	Test harness access
  -	Public verification endpoints
  -	Audit logs
  -	Policy configuration
  -	Revocation interface
  -	Capability issuance interface

  23.7 Compliance Declaration
  An implementation MAY claim:
  “AIDP-Compliant: Level X”
  only after passing all tests for that certification level.


  Appendix A. Changes Since draft-vandoulas-aidp-00

  This section summarizes substantive changes introduced since
  draft-vandoulas-aidp-00.

  - Clarified replay semantics to explicitly distinguish replay detection
    from re-execution, and to require deterministic result recovery
    without side effects (Sections 10.6.3, 21.7).

  - Introduced explicit Observation retention and pull-based recovery
    requirements to prevent loss of execution outcomes due to delivery
    failure (Sections 21.7, 20.9).

  - Refined agent control loop semantics to permit parallel,
    causally-independent intents while preserving deterministic reasoning
    for dependent actions (Sections 3.3, 8.2).

  - Hardened canonicalization and parsing requirements by mandating
    rejection of duplicate JSON object member names during parsing,
    prior to validation and cryptographic verification (Sections 16.3,
    21.16.2).

  - Added explicit identity resolution profiles to support interoperable
    cross-domain validation, including dereferenceable and self-contained
    identity models (Section 4.2).

  - Strengthened observability hook security by restricting Observation
    delivery endpoints to pre-authorized destinations and mandating SSRF
    protections with deterministic fallback to pull-based retrieval
    (Sections 17.1.6, 21.9).

  - Introduced execution_advice as an optional, non-binding mechanism for
    communicating retry, backoff, and failure classification guidance in
    both Observation and Problem Details messages (Sections 17.2, 17.3).

  - Added deterministic retry suppression and anti-loop requirements to
    the Agent Runtime validation pipeline to prevent infinite re-issuance
    of semantically identical intents following deterministic failures
    (Section 21.16.3).

  - Clarified deterministic agent loop guarantees to ensure reasoning
    progression is gated only on Observations for causally dependent
    intents, rather than enforcing global serialization (Section 21.16.4).


  Authors' Addresses

     Ioannis Vandoulas
     Email: jvandoul@gmail.com


name: draft-mallick-muacp
rev: 02
title: The Micro Agent Communication Protocol (uACP)
time: 2026-01-17T18:51:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-21T18:51:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774139+00:00
source: ietf
abstract:
  This document specifies the Micro Agent Communication Protocol
     (µACP), a resource-efficient messaging protocol for autonomous agents
     operating on resource-constrained Edge and IoT devices (including
     Class 1 and Class 2 devices per [RFC7228]).  Existing agent
     communication protocols assume unbounded computational and energy
     resources; µACP provides bounded resource consumption guarantees with
     deterministic memory bounds (8-byte header, up to 1024-byte TLV
     region, up to 65535-byte payload) and bounded processing time per
     message, while maintaining expressiveness sufficient for finite-state
     coordination patterns.  The protocol defines four core message types,
     a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE
     security binding for operation in adversarial environments.

full_text:
  Independent Submission                                        A. Mallick
  Internet-Draft                                                I. Chebolu
  Intended status: ExperimentalCentre for Development of Advanced Computing (CDAC)
  Expires: 22 July 2026                                    18 January 2026


               The Micro Agent Communication Protocol (µACP)
                           draft-mallick-muacp-02

  Abstract

     This document specifies the Micro Agent Communication Protocol
     (µACP), a resource-efficient messaging protocol for autonomous agents
     operating on resource-constrained Edge and IoT devices (including
     Class 1 and Class 2 devices per [RFC7228]).  Existing agent
     communication protocols assume unbounded computational and energy
     resources; µACP provides bounded resource consumption guarantees with
     deterministic memory bounds (8-byte header, up to 1024-byte TLV
     region, up to 65535-byte payload) and bounded processing time per
     message, while maintaining expressiveness sufficient for finite-state
     coordination patterns.  The protocol defines four core message types,
     a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE
     security binding for operation in adversarial environments.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.



  Mallick & Chebolu         Expires 22 July 2026                  [Page 1]


  Internet-Draft                    µACP                      January 2026


     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 22 July 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.3.  Document Structure  . . . . . . . . . . . . . . . . . . .   5
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
       2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Message Model and Encoding Rules  . . . . . . . . . . . . . .   6
       3.1.  Message Structure . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Header Format . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  TLV Encoding  . . . . . . . . . . . . . . . . . . . . . .   8
         3.3.1.  TLV Processing Rules  . . . . . . . . . . . . . . . .   9
       3.4.  Payload Encoding  . . . . . . . . . . . . . . . . . . . .   9
       3.5.  Byte Ordering . . . . . . . . . . . . . . . . . . . . . .   9
       3.6.  Fragmentation (Optional Feature)  . . . . . . . . . . . .   9
       3.7.  OSCORE Protection Boundaries  . . . . . . . . . . . . . .  10
       3.8.  Canonical Encoding Rules  . . . . . . . . . . . . . . . .  10
     4.  Protocol Semantics  . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  PING  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.  TELL  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.3.  ASK . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.  OBSERVE . . . . . . . . . . . . . . . . . . . . . . . . .  11



  Mallick & Chebolu         Expires 22 July 2026                  [Page 2]


  Internet-Draft                    µACP                      January 2026


       4.5.  Summary of Normative Requirements . . . . . . . . . . . .  12
     5.  Mandatory Transport Binding: OSCORE/CoAP  . . . . . . . . . .  12
       5.1.  Mapping µACP Messages to CoAP . . . . . . . . . . . . . .  12
       5.2.  OSCORE Protection Requirements  . . . . . . . . . . . . .  13
       5.3.  Establishing OSCORE Security Contexts . . . . . . . . . .  13
       5.4.  CoAP Message Types and Reliability  . . . . . . . . . . .  13
       5.5.  Mapping ASK–TELL to CoAP Request/Response . . . . . . . .  14
       5.6.  Mapping OBSERVE Subscriptions . . . . . . . . . . . . . .  14
       5.7.  Congestion Control Requirements . . . . . . . . . . . . .  14
       5.8.  Transport-Layer Error Handling  . . . . . . . . . . . . .  15
       5.9.  Summary of MTI Requirements . . . . . . . . . . . . . . .  15
     6.  Error Handling, Version Negotiation, and Extensibility  . . .  15
       6.1.  Error Code TLVs . . . . . . . . . . . . . . . . . . . . .  15
       6.2.  Standardized Error Conditions . . . . . . . . . . . . . .  15
       6.3.  Handling Malformed Messages . . . . . . . . . . . . . . .  17
       6.4.  Conversation-Lifetime Error Handling  . . . . . . . . . .  17
       6.5.  Version Negotiation . . . . . . . . . . . . . . . . . . .  18
       6.6.  Downgrade and Version-Rollback Protection . . . . . . . .  19
       6.7.  Extensibility Framework . . . . . . . . . . . . . . . . .  20
       6.8.  Summary of Normative Requirements . . . . . . . . . . . .  20
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
       7.1.  µACP TLV Types Registry . . . . . . . . . . . . . . . . .  20
       7.2.  µACP QoS Codes Registry . . . . . . . . . . . . . . . . .  22
       7.3.  µACP Verb Codes Registry  . . . . . . . . . . . . . . . .  22
       7.4.  µACP Error Codes Registry . . . . . . . . . . . . . . . .  23
       7.5.  CoAP Content-Format Registration  . . . . . . . . . . . .  23
       7.6.  Media Type Registration . . . . . . . . . . . . . . . . .  24
       7.7.  Well-Known CoAP Resource  . . . . . . . . . . . . . . . .  24
       7.8.  Summary of IANA Actions . . . . . . . . . . . . . . . . .  24
     8.  State Machines and Processing Logic . . . . . . . . . . . . .  25
       8.1.  ASK/TELL Conversation State Machine . . . . . . . . . . .  25
       8.2.  PING/TELL State Machine . . . . . . . . . . . . . . . . .  25
       8.3.  OBSERVE Subscription State Machine  . . . . . . . . . . .  26
       8.4.  Error-State Transitions . . . . . . . . . . . . . . . . .  27
       8.5.  Processing Time and Resource Bounds . . . . . . . . . . .  27
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
       9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  27
       9.2.  Authentication, Integrity, and Confidentiality  . . . . .  27
       9.3.  Replay Prevention and Freshness . . . . . . . . . . . . .  28
       9.4.  Denial-of-Service and Resource Exhaustion . . . . . . . .  28
       9.5.  Subscription Security . . . . . . . . . . . . . . . . . .  28
       9.6.  Downgrade Protection  . . . . . . . . . . . . . . . . . .  28
       9.7.  Key Management  . . . . . . . . . . . . . . . . . . . . .  28
       9.8.  Side-Channel Attacks  . . . . . . . . . . . . . . . . . .  29
       9.9.  Safe Failure Modes  . . . . . . . . . . . . . . . . . . .  29
     10. Interoperability and Deployment Profiles  . . . . . . . . . .  29
       10.1.  Minimum Interoperability Profile (MIP) . . . . . . . . .  29
       10.2.  Constrained Node Profile (CNP) . . . . . . . . . . . . .  29



  Mallick & Chebolu         Expires 22 July 2026                  [Page 3]


  Internet-Draft                    µACP                      January 2026


       10.3.  Infrastructure Node Profile (INP)  . . . . . . . . . . .  30
       10.4.  Cross-Profile Interoperability . . . . . . . . . . . . .  30
       10.5.  Feature Negotiation  . . . . . . . . . . . . . . . . . .  30
     11. Wire Examples . . . . . . . . . . . . . . . . . . . . . . . .  31
       11.1.  Minimal PING (unencrypted) . . . . . . . . . . . . . . .  31
       11.2.  ASK/TELL over OSCORE . . . . . . . . . . . . . . . . . .  31
     12. Conformance Tests . . . . . . . . . . . . . . . . . . . . . .  33
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  33
       13.2.  Informative References . . . . . . . . . . . . . . . . .  35
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  36
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

  1.  Introduction

     The Micro Agent Communication Protocol (µACP) is a compact, resource-
     efficient communication protocol designed for distributed autonomous
     agents operating on resource-constrained Edge and IoT devices
     (including Class 1 and Class 2 devices per [RFC7228]).  It aims to
     bridge the gap between resource-light IoT protocols and semantically
     rich agent communication languages, by offering minimal overhead yet
     expressive interaction semantics.

     Modern IoT, edge, and embedded environments involve devices with
     limited RAM, CPU, energy, and unreliable networks.  Distributed
     applications require coordination, state sharing, event
     subscriptions, and request/response semantics.  Traditional agent-
     communication languages impose heavy overhead unacceptable on
     microcontroller-class platforms, while standard IoT protocols provide
     minimal semantics.

     µACP addresses this by defining a wire-efficient, fixed-header, TLV-
     extensible protocol with four core verbs (PING, TELL, ASK, OBSERVE)
     sufficient for request/response, publish/subscribe, and liveness
     checking.  The protocol enables lean, deterministic implementations
     suitable for microcontroller-class devices while supporting
     structured multi-agent interactions.  Formal foundations including
     resource bounds and safety verification are established in [MUACP].

     This specification mandates CoAP with OSCORE [RFC8613] as the
     mandatory-to-implement transport binding, ensuring end-to-end
     confidentiality, integrity, and replay protection for constrained
     devices.








  Mallick & Chebolu         Expires 22 July 2026                  [Page 4]


  Internet-Draft                    µACP                      January 2026


  1.1.  Goals

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

  1.2.  Scope

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

  1.3.  Document Structure

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

  2.  Conventions and Terminology

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

  2.1.  Terminology

     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



  Mallick & Chebolu         Expires 22 July 2026                  [Page 5]


  Internet-Draft                    µACP                      January 2026


     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 numbered from 0 (MSB) to n-1 (LSB); message
     formats shown using ASCII art diagrams.

  2.3.  Abbreviations

     Abbreviations: CBOR (Concise Binary Object Representation [RFC8949]),
     CID (Correlation ID), CoAP (Constrained Application Protocol), COSE
     (CBOR Object Signing and Encryption [RFC8152]), EDHOC (Ephemeral
     Diffie-Hellman Over COSE [RFC9528]), FSM (Finite State Machine), IANA
     (Internet Assigned Numbers Authority), IoT (Internet of Things), MTI
     (Mandatory to Implement), OSCORE (Object Security for Constrained
     RESTful Environments), QoS (Quality of Service), SID (Sequence ID),
     TLV (Type-Length-Value), URI (Uniform Resource Identifier).

  3.  Message Model and Encoding Rules

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

  3.1.  Message Structure

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

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

                 Figure 1: Figure 1: µACP Message Layout

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

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





  Mallick & Chebolu         Expires 22 July 2026                  [Page 6]


  Internet-Draft                    µACP                      January 2026


  3.2.  Header Format

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

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

     Byte 0-1:   Sequence ID (16 bits, big-endian)
     Byte 2-3:   Correlation ID (16 bits, big-endian)
     Byte 4:     Bits 0-1: QoS (2 bits)
                 Bits 2-3: Verb (2 bits)
                 Bits 4-7: Flags (4 bits)
     Byte 5-7:   Reserved (24 bits, all zeros)

                   Figure 2: Figure 2: µACP Header Bit Layout

     *Sequence ID (16 bits, bytes 0-1):* Monotonically increasing
     identifier used for duplicate detection and replay-window tracking.
     Sequence ID is per-sender (per OSCORE security context) and
     monotonically increases within each sender's message stream.  MUST
     wrap modulo 2^16.  Sequence ID SHOULD be initialized to a random
     value (not 0) to prevent predictability and traffic analysis.
     Initialization to 0 is acceptable only when: (1) establishing a new
     OSCORE security context, (2) no prior communication history exists
     with the peer, and (3) the initialization is synchronized with the
     establishment of the new OSCORE context.  In all other cases,
     Sequence IDs MUST be initialized to a random value.  Sequence IDs
     MUST be unpredictable if security-sensitive traffic requires
     preventing traffic analysis.

     *Correlation ID (16 bits, bytes 2-3):* Identifies all messages
     belonging to the same conversation.  Correlation ID MUST be unique
     among active conversations from the same sender (same OSCORE security
     context).  Different senders may independently use the same
     Correlation ID values, as conversations are scoped per OSCORE
     security context.  SHOULD be randomly generated in security-sensitive
     deployments.

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




  Mallick & Chebolu         Expires 22 July 2026                  [Page 7]


  Internet-Draft                    µACP                      January 2026


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

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

     *Reserved (24 bits, bytes 5-7):* MUST be set to zero on transmission
     and ignored by receivers.  Reserved bits MAY be repurposed by future
     µACP versions but MUST NOT change meaning in this version.

  3.3.  TLV Encoding

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

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

                        Figure 3: Figure 3: TLV Encoding

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

     *Length (8 bits):* Specifies the number of octets in the Value field
     (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:* A future TLV Type range MAY designate critical TLVs.
     Receiving an unknown critical TLV MUST cause message rejection.






  Mallick & Chebolu         Expires 22 July 2026                  [Page 8]


  Internet-Draft                    µACP                      January 2026


  3.3.1.  TLV Processing Rules

     Receivers MUST apply the following rules when processing TLVs:

     *  TLVs MUST be parsed strictly in order.

     *  If Length exceeds remaining buffer size, the message MUST be
        discarded.

     *  Unknown TLV Types MUST be ignored unless they are designated
        critical.

     *  TLV order MUST be strictly increasing by Type; violating this is a
        format error.

     *  TLV Type 0x00 (Raw Octets) MUST NOT appear in encrypted messages;
        its use is restricted to unencrypted PING messages.

  3.4.  Payload Encoding

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

  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 22 July 2026                  [Page 9]


  Internet-Draft                    µACP                      January 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; payload MUST begin immediately after the last
     TLV; 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, unless an application
     explicitly operates in an unauthenticated environment.

     For each verb, this section defines sender behavior, receiver
     behavior, state-machine interactions, mandatory error cases, and
     expected processing-time bounds.

  4.1.  PING

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



  Mallick & Chebolu         Expires 22 July 2026                 [Page 10]


  Internet-Draft                    µACP                      January 2026


     with OSCORE or OSCORE-protected PING.

  4.2.  TELL

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

  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 → TELL(error); security validation
     failure → silent discard; correlation-table limits exceeded →
     resource exhaustion error.

  4.4.  OBSERVE

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









  Mallick & Chebolu         Expires 22 July 2026                 [Page 11]


  Internet-Draft                    µACP                      January 2026


  4.5.  Summary of Normative Requirements

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

  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+binary,
     Payload=Full µACP message.  Each µACP message corresponds to exactly
     one CoAP POST.

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

           Figure 4: Figure 4: CoAP Envelope Carrying a µACP Message




  Mallick & Chebolu         Expires 22 July 2026                 [Page 12]


  Internet-Draft                    µACP                      January 2026


  5.2.  OSCORE Protection Requirements

     All µACP messages except unencrypted PING MUST be protected using
     OSCORE [RFC8613], which uses COSE [RFC8152] 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.  For Class 1 devices, implementations SHOULD
     limit concurrent OSCORE contexts (e.g., 8-16 contexts).

  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:

         +==========+========================+=======================+
         | µACP QoS | Meaning                | CoAP Message Type     |
         +==========+========================+=======================+
         | 0        | fire-and-forget        | NON (Non-confirmable) |
         +----------+------------------------+-----------------------+
         | 1        | at-least-once delivery | CON (Confirmable)     |
         +----------+------------------------+-----------------------+
         | 2        | at-most-once delivery  | NON (Non-confirmable, |
         |          |                        | no retransmission)    |
         +----------+------------------------+-----------------------+

                                    Table 1

     *QoS Semantics:* QoS=0 (fire-and-forget) provides best-effort
     delivery.  QoS=1 (at-least-once) ensures delivery through CoAP
     retransmissions.  QoS=2 (at-most-once) provides a single delivery



  Mallick & Chebolu         Expires 22 July 2026                 [Page 13]


  Internet-Draft                    µACP                      January 2026


     attempt without retransmission, suitable for idempotent operations.
     Both QoS=0 and QoS=2 use CoAP NON messages.  Implementations MUST NOT
     retransmit QoS=2 messages at the µACP layer.

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

  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

  5.6.  Mapping OBSERVE Subscriptions

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

  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 (≤1 per 10 seconds per peer); 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.






  Mallick & Chebolu         Expires 22 July 2026                 [Page 14]


  Internet-Draft                    µACP                      January 2026


  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 → drop message.  Unacknowledged CoAP CON → apply
     µACP QoS semantics for retransmission.  Repeated timeouts →
     conversation enters failure state.  Malformed CoAP envelopes →
     discard.

  5.9.  Summary of MTI Requirements

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

  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
     integers and MUST follow the registry defined in the IANA
     Considerations section.

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

                       Figure 6: Figure 6: Error-Code TLV

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

  6.2.  Standardized Error Conditions

     The following error codes are defined for µACP:





  Mallick & Chebolu         Expires 22 July 2026                 [Page 15]


  Internet-Draft                    µACP                      January 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.        |
     +------+------------------------+-----------------------------------+

                                    Table 2

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










  Mallick & Chebolu         Expires 22 July 2026                 [Page 16]


  Internet-Draft                    µACP                      January 2026


  6.3.  Handling Malformed Messages

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

  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 22 July 2026                 [Page 17]


  Internet-Draft                    µACP                      January 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_MALFORMED if the message appears valid but out-
         of-order).

     This deterministic strategy ensures interoperability while preventing
     resource exhaustion and replay attacks.  Correlation ID collisions
     are rare when Correlation IDs are randomly generated with sufficient
     entropy.  Collisions from different senders (different OSCORE
     contexts) are handled separately, as each OSCORE context maintains
     its own conversation state.  The Sequence ID comparison is secure
     because Sequence IDs are authenticated and integrity-protected by
     OSCORE.

     *Example:* If an active conversation exists with Correlation
     ID=0x1234 and last observed Sequence ID=0x0010 from sender A
     (identified by OSCORE context A), and a new message arrives with
     Correlation ID=0x1234 and Sequence ID=0x0015 from the same sender A,
     the receiver terminates the old conversation and accepts the new one.
     If the new message has Sequence ID=0x0005 from sender A, it is
     rejected as a potential replay.  If a message arrives with
     Correlation ID=0x1234 from sender B (different OSCORE context), it is
     treated as a separate conversation, as conversations are scoped per
     OSCORE security context.

  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).

     Version negotiation follows these rules:

     *  If a message includes a Version-TLV that indicates only
        unsupported versions (i.e., all versions listed in the Version-TLV
        are higher than the receiver's maximum supported version), the
        receiver MUST return ERR_VERSION_MISMATCH in a TELL error
        response.

     *  If the Version-TLV contains at least one supported version, the
        receiver MUST use the highest mutually supported version for
        subsequent messages in the conversation.






  Mallick & Chebolu         Expires 22 July 2026                 [Page 18]


  Internet-Draft                    µACP                      January 2026


     *  When both parties send Version-TLVs (e.g., in ASK and TELL), each
        party MUST independently select the highest mutually supported
        version from the union of both Version-TLV lists.  If no common
        version exists, the receiver MUST return ERR_VERSION_MISMATCH.

     *  The selected version applies to all messages in the conversation
        identified by the Correlation ID.  Once a version is selected, it
        MUST NOT be changed for that conversation.

     *  Version negotiation MUST occur under OSCORE protection.  PING
        messages (which are typically unencrypted) SHOULD NOT carry
        Version-TLV to maintain lightweight operation.  If version
        negotiation is required before OSCORE context establishment,
        implementations SHOULD use ASK/TELL with OSCORE or establish the
        OSCORE context first, then negotiate versions in subsequent
        messages.

  Type:   0x01 (Version)
  Length: N (number of supported versions, 1-255)
  Value:  Sequence of N unsigned 8-bit integers, each representing
          a supported protocol version number (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.

  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.










  Mallick & Chebolu         Expires 22 July 2026                 [Page 19]


  Internet-Draft                    µACP                      January 2026


  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; Types 128–255 are vendor-specific and require no global
     registration.  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.
     All registries use the policies defined in [RFC8126].  Unless
     otherwise stated, values are allocated using the "IETF Review"
     policy.

  7.1.  µACP TLV Types Registry

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

     *  *0–31:* Standards Action (as defined in [RFC8126] Section 4.1)

     *  *32–127:* IETF Review

     *  *128–255:* Vendor-specific (First Come First Served)

     Initial values:









  Mallick & Chebolu         Expires 22 July 2026                 [Page 20]


  Internet-Draft                    µACP                      January 2026


     +=====+=====================+==================+========+===========+
     |Value| Name                | Description      |Format  | Reference |
     +=====+=====================+==================+========+===========+
     |0x00 | RAW_OCTETS          | Unstructured     |Opaque  | This      |
     |     |                     | data; MUST NOT   |        | document  |
     |     |                     | appear in        |        |           |
     |     |                     | encrypted        |        |           |
     |     |                     | messages except  |        |           |
     |     |                     | PING.            |        |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x01 | VERSION             | Advertised       |Array of| This      |
     |     |                     | supported        |integers| document  |
     |     |                     | protocol         |        |           |
     |     |                     | versions.        |        |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x02 | CONTENT_TYPE        | Specifies        |Integer | This      |
     |     |                     | payload          |        | document  |
     |     |                     | encoding.        |        |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x03 | CBOR_PAYLOAD        | Payload encoded  |CBOR    | This      |
     |     |                     | as CBOR.         |data    | document  |
     |     |                     |                  |item    |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x10 | RESERVED            | Reserved for     |N/A     | This      |
     |     |                     | future           |        | document  |
     |     |                     | fragmentation    |        |           |
     |     |                     | specification.   |        |           |
     |     |                     | Implementations  |        |           |
     |     |                     | MUST NOT use     |        |           |
     |     |                     | Type=0x10 until  |        |           |
     |     |                     | fragmentation    |        |           |
     |     |                     | is fully         |        |           |
     |     |                     | specified in a   |        |           |
     |     |                     | future           |        |           |
     |     |                     | extension        |        |           |
     |     |                     | document.        |        |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x20 | TOPIC               | Subscription     |UTF-8   | This      |
     |     |                     | topic for        |string  | document  |
     |     |                     | OBSERVE.         |        |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x21 | CONDITION           | Trigger          |UTF-8 or| This      |
     |     |                     | condition for    |CBOR    | document  |
     |     |                     | OBSERVE.         |        |           |
     +-----+---------------------+------------------+--------+-----------+
     |0x22 | ERROR_CODE          | Error code       |Integer | This      |
     |     |                     | returned in      |        | document  |
     |     |                     | TELL(error).     |        |           |



  Mallick & Chebolu         Expires 22 July 2026                 [Page 21]


  Internet-Draft                    µACP                      January 2026


     +-----+---------------------+------------------+--------+-----------+
     |0xFF | CANCEL_SUBSCRIPTION | Explicit         |Empty   | This      |
     |     |                     | termination of   |        | document  |
     |     |                     | OBSERVE          |        |           |
     |     |                     | subscription.    |        |           |
     +-----+---------------------+------------------+--------+-----------+

                                    Table 3

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

  7.2.  µACP QoS Codes Registry

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

      +=======+=================+===========================+===========+
      | Value | Name            | Description               | Reference |
      +=======+=================+===========================+===========+
      | 0     | FIRE_AND_FORGET | No reliability; mapped to | This      |
      |       |                 | CoAP NON.                 | document  |
      +-------+-----------------+---------------------------+-----------+
      | 1     | AT_LEAST_ONCE   | Retransmissions required; | This      |
      |       |                 | mapped to CoAP CON.       | document  |
      +-------+-----------------+---------------------------+-----------+
      | 2     | AT_MOST_ONCE    | No retransmission; mapped | This      |
      |       |                 | to CoAP NON.              | document  |
      +-------+-----------------+---------------------------+-----------+
      | 3     | RESERVED        | Reserved for future use.  | This      |
      |       |                 |                           | document  |
      +-------+-----------------+---------------------------+-----------+

                                    Table 4

  7.3.  µACP Verb Codes Registry

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












  Mallick & Chebolu         Expires 22 July 2026                 [Page 22]


  Internet-Draft                    µACP                      January 2026


       +=======+=========+============================+===============+
       | Value | Name    | Description                | Reference     |
       +=======+=========+============================+===============+
       | 0     | PING    | Liveness probe.            | This document |
       +-------+---------+----------------------------+---------------+
       | 1     | TELL    | State update,              | This document |
       |       |         | notification, or response. |               |
       +-------+---------+----------------------------+---------------+
       | 2     | ASK     | Request for information or | This document |
       |       |         | action.                    |               |
       +-------+---------+----------------------------+---------------+
       | 3     | OBSERVE | Subscription to events or  | This document |
       |       |         | state changes.             |               |
       +-------+---------+----------------------------+---------------+

                                   Table 5

  7.4.  µACP Error Codes Registry

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

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

  7.5.  CoAP Content-Format Registration

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

      +==============+==============+==========+============+===========+
      | Name         | Media Type   | Encoding | ID         | Reference |
      +==============+==============+==========+============+===========+
      | application/ | application/ | Binary   | TBD (to be | This      |
      | muacp+binary | muacp+binary |          | assigned   | document  |
      |              |              |          | by IANA)   |           |
      +--------------+--------------+----------+------------+-----------+

                                    Table 6

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

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





  Mallick & Chebolu         Expires 22 July 2026                 [Page 23]


  Internet-Draft                    µACP                      January 2026


  7.6.  Media Type Registration

     IANA is requested to register the following media type in the
     "application" registry per [RFC6838]:

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

  7.7.  Well-Known CoAP Resource

     IANA is requested to register the following CoAP Well-Known URI per
     [RFC8615] using the "IETF Review" policy:

         +====================+==========================+===========+
         | URI                | Description              | Reference |
         +====================+==========================+===========+
         | /.well-known/muacp | Discovery resource       | This      |
         |                    | indicating µACP support. | document  |
         +--------------------+--------------------------+-----------+

                                    Table 7

     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 and populate
     initial values; create the µACP QoS Codes registry; create the µACP
     Verb Codes registry; create the µACP Error Codes registry; register
     the CoAP Content-Format application/muacp+binary; register the media
     type application/muacp+binary; register the well-known CoAP resource
     /.well-known/muacp.  These actions enable interoperable deployment
     and ensure long-term extensibility under IETF governance.




  Mallick & Chebolu         Expires 22 July 2026                 [Page 24]


  Internet-Draft                    µACP                      January 2026


  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
     support at least 64 concurrent conversations and MUST reject new
     conversations if resource ceilings are exceeded
     (ERR_RESOURCE_EXHAUSTED).

  8.1.  ASK/TELL Conversation State Machine

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

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

                   Figure 8: Figure 8: ASK/TELL State Machine

  8.2.  PING/TELL State Machine

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




  Mallick & Chebolu         Expires 22 July 2026                 [Page 25]


  Internet-Draft                    µACP                      January 2026


             +--------+
             |  IDLE  |
             +--------+
                 |
                 | send PING
                 v
             +--------------+
             | WAIT_PONG    |
             +--------------+
                 |        ^
        recv TELL|        | timeout
                 v        |
             +--------------+
             |  COMPLETED   |
             +--------------+

                   Figure 9: Figure 9: PING/TELL Liveness FSM

  8.3.  OBSERVE Subscription State Machine

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

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



  Mallick & Chebolu         Expires 22 July 2026                 [Page 26]


  Internet-Draft                    µACP                      January 2026


                 Figure 10: Figure 10: OBSERVE Subscription FSM

  8.4.  Error-State Transitions

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

  8.5.  Processing Time and Resource Bounds

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

  9.  Security Considerations

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

  9.1.  Threat Model

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

  9.2.  Authentication, Integrity, and Confidentiality

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



  Mallick & Chebolu         Expires 22 July 2026                 [Page 27]


  Internet-Draft                    µACP                      January 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 (minimum
     64), maximum OBSERVE subscriptions (minimum 16), rate limits on PING
     and ASK, TLV region size limits (max 1024 bytes), payload size limits
     (max 65535 bytes), and static/preallocated memory pools.  When limits
     are exceeded, agents MUST return ERR_RESOURCE_EXHAUSTED or silently
     drop messages.  CoAP-level DoS mitigation (exponential backoff, NON
     vs CON) MUST also be applied.

  9.5.  Subscription Security

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

  9.6.  Downgrade Protection

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

  9.7.  Key Management

     Implementations MUST provide: secure key provisioning (EDHOC, PSK, or
     manufacturing-time injection), rotation of OSCORE master secrets,
     secure deletion of expired keys, protection against key reuse across
     peers, and protection against side-channel extraction.  Compromise of
     OSCORE keys compromises all µACP security properties.

     *Key Rotation:* OSCORE master secrets SHOULD be rotated periodically
     (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.





  Mallick & Chebolu         Expires 22 July 2026                 [Page 28]


  Internet-Draft                    µACP                      January 2026


  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)

     All µACP implementations MUST support: the 64-bit header format; all
     four verbs (PING, TELL, ASK, OBSERVE); TLV processing with ordering
     and size limits; OSCORE/CoAP transport binding; Content-Format
     application/muacp+binary; conversation state for at least 64 active
     Correlation IDs; subscription state for at least 16 active OBSERVE
     subscriptions; error-handling and state-machine behavior as defined
     in this specification.

  10.2.  Constrained Node Profile (CNP)

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









  Mallick & Chebolu         Expires 22 July 2026                 [Page 29]


  Internet-Draft                    µACP                      January 2026


  10.3.  Infrastructure Node Profile (INP)

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

  10.4.  Cross-Profile Interoperability

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

  10.5.  Feature Negotiation

     Feature discovery uses GET /.well-known/muacp, returning a CBOR map
     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,              ; Maximum TLV region size in bytes
    ? "max-payload-size" => uint,          ; Maximum payload size in bytes
    ? "supported-tlv-types" => [*uint],    ; List of supported TLV Type values
    ? "supported-versions" => [*uint],     ; List of supported protocol versions
    ? "congestion-modes" => [*text],        ; Supported congestion control modes
    ? "conversation-limit" => uint,        ; Maximum concurrent conversations
    ? "subscription-limit" => uint         ; Maximum concurrent subscriptions
  }

          Figure 11: Feature Negotiation Response Format (CDDL)

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








  Mallick & Chebolu         Expires 22 July 2026                 [Page 30]


  Internet-Draft                    µACP                      January 2026


  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).

  11.1.  Minimal PING (unencrypted)

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

     00 01   # Sequence ID = 0x0001
     00 01   # Correlation ID = 0x0001
     00      # QoS = 0 (fire-and-forget), Verb = 0 (PING), Flags = 0
     00 00 00   # Reserved (24 bits, all zeros)

     Total: 8 bytes

                    Figure 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:

















  Mallick & Chebolu         Expires 22 July 2026                 [Page 31]


  Internet-Draft                    µACP                      January 2026


  Step 1: Unencrypted µACP ASK Message (before OSCORE encryption):
    Header (8 bytes):
      00 02              # Sequence ID = 0x0002
      00 03              # Correlation ID = 0x0003
      40                 # QoS = 1 (at-least-once), Verb = 2 (ASK), Flags = 0
      00 00 00           # Reserved (24 bits, all zeros)

    TLVs (optional, none in this example):
      [No TLVs]

    Payload (optional, CBOR-encoded request):
      A1                  # CBOR map with 1 key-value pair
      66 61 63 74 69 6F 6E  # "action" (UTF-8 string)
      64 72 65 61 64        # "read" (UTF-8 string)

    Total µACP message: 8 bytes (header) + 0 bytes (TLVs) + 11 bytes (payload) = 19 bytes

  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"
      11 2A              # Content-Format: application/muacp+binary (0x2A, TBD)
      09 XX              # OSCORE Option (flag byte and partial IV)

    OSCORE-Protected Payload (encrypted µACP message):
      [Encrypted ciphertext - actual value depends on OSCORE context]
      Note: The complete 19-byte µACP message from Step 1 is encrypted here

  Step 3: TELL Response (unencrypted structure before OSCORE):
    Header (8 bytes):
      00 03              # Sequence ID = 0x0003
      00 03              # Correlation ID = 0x0003 (matches ASK)
      10                 # QoS = 0 (fire-and-forget), Verb = 1 (TELL), Flags = 0
      00 00 00           # Reserved (24 bits, all zeros)

    TLVs:
      22 01 00           # Error-Code TLV: Type=0x22, Length=1, Value=0x00 (SUCCESS)

    Payload (optional, CBOR-encoded result):
      A1                  # CBOR map with 1 key-value pair
      65 76 61 6C 75 65    # "value" (UTF-8 string)
      F9 41 AC             # CBOR half-precision float: 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):
      [Encrypted ciphertext - actual value depends on OSCORE context]




  Mallick & Chebolu         Expires 22 July 2026                 [Page 32]


  Internet-Draft                    µACP                      January 2026


             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.

  12.  Conformance Tests

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

     Implementations MUST pass tests in the following categories:

     *  *Header and TLV Encoding:* Correct parsing of all header fields,
        TLV ordering, size limits (1024 bytes TLV region, 65535 bytes
        payload), and handling of unknown TLVs.

     *  *Parser Robustness:* Safe handling of malformed headers, oversized
        payloads, invalid TLV lengths, and resource exhaustion conditions.

     *  *State-Machine Behavior:* ASK/TELL conversation lifecycle, OBSERVE
        subscription management, PING statelessness, and deterministic
        error transitions.

     *  *OSCORE Security:* Authentication and decryption of protected
        messages, replay window enforcement, context isolation, and
        downgrade protection.

     *  *Resource Constraints:* Conversation table limits (minimum 64
        entries), subscription limits (minimum 16), and bounded processing
        time.

     *  *Interoperability:* Successful message exchange between
        independent implementations under the Minimum Interoperability
        Profile.

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

  13.  References

  13.1.  Normative References




  Mallick & Chebolu         Expires 22 July 2026                 [Page 33]


  Internet-Draft                    µACP                      January 2026


     [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>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
                RFC 8152, July 2017,
                <https://www.rfc-editor.org/rfc/rfc8152>.

     [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>.






  Mallick & Chebolu         Expires 22 July 2026                 [Page 34]


  Internet-Draft                    µACP                      January 2026


     [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>.

     [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/>.

     [MUACP]    Mallick, A. and I. Chebolu, "µACP: A Formal Calculus for
                Expressive, Resource-Constrained Agent Communication",
                arXiv 2601.00219, archivePrefix arXiv, primaryClass cs.MA,
                2026, <https://arxiv.org/abs/2601.00219>.

     [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>.

     [AGENT-SURVEY]
                Finin, T., Labrou, Y., and J. Mayfield, "A Survey of Agent
                Communication Languages: Formalisms and Applications",
                Communications of ACM 40(5), DOI 10.1145/265563.265564,
                1997, <https://doi.org/10.1145/265563.265564>.

     [IOT-SURVEY]
                Palattella, M., Accettura, N., Vilajosana, X., Watteyne,
                T., Grieco, L., Boggia, G., and M. Dohler, "IoT Protocols
                for Resource-Constrained Devices: A Comparative Survey",
                IEEE Communications Surveys & Tutorials 18(3),
                DOI 10.1109/COMST.2016.2549528, 2016,
                <https://doi.org/10.1109/COMST.2016.2549528>.






  Mallick & Chebolu         Expires 22 July 2026                 [Page 35]


  Internet-Draft                    µACP                      January 2026


     [RPL]      Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for
                Low-Power and Lossy Networks", RFC 6550, March 2012,
                <https://www.rfc-editor.org/rfc/rfc6550>.

     [DDS]      Group, O. M., "Data Distribution Service (DDS) for Real-
                Time Systems, Version 1.4", OMG Document formal/15-04-10,
                April 2015.

     [DT]       Boschert, S. and R. Rosen, "Digital Twin—The Simulation
                Aspect", Mechatronic Futures: Challenges and Solutions for
                Mechatronic Systems and their Designers Chapter 3,
                Publisher Springer, DOI 10.1007/978-3-319-32156-1_3, 2016,
                <https://doi.org/10.1007/978-3-319-32156-1_3>.

  Acknowledgments

     The design of µACP benefited from feedback across multiple research
     and engineering communities working on IoT systems, multi-agent
     communication, and distributed protocol design.  The authors
     acknowledge the valuable insights provided by early reviewers,
     prototype implementers, and colleagues who explored µACP in
     constrained-device testbeds.

     Special thanks are extended to members of the open-source
     contributors who reviewed early drafts of the µACP calculus and
     provided implementation reports via the project repository.  Their
     feedback led to refinements in the state machines, TLV model, and
     transport bindings.

     The authors also thank participants from constrained-network and
     OSCORE working groups whose discussions influenced the treatment of
     fragmentation, replay protection, and authentication in this
     specification.

     This specification incorporates lessons from deployments in
     microcontroller-based sensing systems, autonomous control nodes, and
     large-scale telemetry environments.  The authors acknowledge these
     deployments for motivating the resource model and deterministic
     behavior guarantees underlying µACP.

     This work is an independent contribution and does not represent the
     views of any organization or government entity.

  Authors' Addresses







  Mallick & Chebolu         Expires 22 July 2026                 [Page 36]


  Internet-Draft                    µACP                      January 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 22 July 2026                 [Page 37]


name: draft-gaikwad-llm-benchmarking-terminology
rev: 00
title: Benchmarking Terminology for Large Language Model Serving
time: 2026-01-20T10:07:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-24T10:07:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-07T06:55:09.774143+00:00
source: ietf
abstract:
  This document defines terminology for benchmarking the performance of
     Large Language Model (LLM) inference serving systems.  It establishes
     a shared vocabulary for latency, throughput, resource utilization,
     and quality metrics applicable to inference engines, application
     gateways, and compound agentic systems.  This document defines
     terminology only and does not prescribe benchmark methodologies or
     acceptance thresholds.

full_text:
  Network Working Group                                         M. Gaikwad
  Internet-Draft                                    Independent Researcher
  Intended status: Informational                              January 2026
  Expires: 24 July 2026


         Benchmarking Terminology for Large Language Model Serving
               draft-gaikwad-llm-benchmarking-terminology-00

  Abstract

     This document defines terminology for benchmarking the performance of
     Large Language Model (LLM) inference serving systems.  It establishes
     a shared vocabulary for latency, throughput, resource utilization,
     and quality metrics applicable to inference engines, application
     gateways, and compound agentic systems.  This document defines
     terminology only and does not prescribe benchmark methodologies or
     acceptance thresholds.

  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 5 July 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.





  Gaikwad                   Expires 24 July 2026                  [Page 1]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Scope and System Under Test Boundary  . . . . . . . . . . . .   5
     3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Request and Response Timing Metrics . . . . . . . . . . .   6
         4.1.1.  End-to-End Latency  . . . . . . . . . . . . . . . . .   6
         4.1.2.  Time to First Token . . . . . . . . . . . . . . . . .   7
         4.1.3.  Inter-Token Latency . . . . . . . . . . . . . . . . .   7
         4.1.4.  Time Between Tokens . . . . . . . . . . . . . . . . .   8
         4.1.5.  Time per Output Token . . . . . . . . . . . . . . . .   9
         4.1.6.  Normalized Latency  . . . . . . . . . . . . . . . . .   9
       4.2.  Phase-Specific Latency Metrics  . . . . . . . . . . . . .  10
         4.2.1.  Prefill Latency . . . . . . . . . . . . . . . . . . .  10
         4.2.2.  Decode Latency  . . . . . . . . . . . . . . . . . . .  11
       4.3.  Throughput and Capacity Metrics . . . . . . . . . . . . .  12
         4.3.1.  Output Token Throughput . . . . . . . . . . . . . . .  12
         4.3.2.  Input Token Throughput  . . . . . . . . . . . . . . .  12
         4.3.3.  Request Throughput  . . . . . . . . . . . . . . . . .  13
         4.3.4.  Non-Padding Token Throughput  . . . . . . . . . . . .  14
         4.3.5.  Offered Load  . . . . . . . . . . . . . . . . . . . .  14
         4.3.6.  Sustainable Load  . . . . . . . . . . . . . . . . . .  15
       4.4.  Latency Distribution Metrics  . . . . . . . . . . . . . .  15
         4.4.1.  Latency Percentiles . . . . . . . . . . . . . . . . .  15
         4.4.2.  Latency Distribution  . . . . . . . . . . . . . . . .  16
         4.4.3.  Token Delivery Jitter . . . . . . . . . . . . . . . .  17
         4.4.4.  Maximum Pause Duration  . . . . . . . . . . . . . . .  17
       4.5.  Scheduling and Multi-Tenancy Metrics  . . . . . . . . . .  18
         4.5.1.  Head-of-Line Blocking . . . . . . . . . . . . . . . .  18
         4.5.2.  Queue Depth . . . . . . . . . . . . . . . . . . . . .  18
         4.5.3.  Queue Wait Time . . . . . . . . . . . . . . . . . . .  19
         4.5.4.  Fairness Index  . . . . . . . . . . . . . . . . . . .  19
         4.5.5.  Batch Utilization . . . . . . . . . . . . . . . . . .  20
         4.5.6.  Admission Rate  . . . . . . . . . . . . . . . . . . .  20
       4.6.  Preemption and Resource Management Metrics  . . . . . . .  21
         4.6.1.  Preemption Rate . . . . . . . . . . . . . . . . . . .  21
         4.6.2.  Preemption Loss . . . . . . . . . . . . . . . . . . .  21
         4.6.3.  Starvation Rate . . . . . . . . . . . . . . . . . . .  22
         4.6.4.  Preemption Recovery Latency . . . . . . . . . . . . .  22
         4.6.5.  KV Cache Swap Rate  . . . . . . . . . . . . . . . . .  23
         4.6.6.  Page Fault Latency  . . . . . . . . . . . . . . . . .  23
       4.7.  Prefix Caching Metrics  . . . . . . . . . . . . . . . . .  24
         4.7.1.  Prefix Cache Hit Rate . . . . . . . . . . . . . . . .  24
         4.7.2.  Prefix Cache Capacity . . . . . . . . . . . . . . . .  24
         4.7.3.  Cache Eviction Rate . . . . . . . . . . . . . . . . .  25
         4.7.4.  TTFT Reduction from Caching . . . . . . . . . . . . .  25
       4.8.  Speculative Decoding Metrics  . . . . . . . . . . . . . .  25



  Gaikwad                   Expires 24 July 2026                  [Page 2]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


         4.8.1.  Draft Acceptance Rate . . . . . . . . . . . . . . . .  26
         4.8.2.  Speculative Speedup . . . . . . . . . . . . . . . . .  26
         4.8.3.  Draft Overhead  . . . . . . . . . . . . . . . . . . .  27
         4.8.4.  Verification Throughput . . . . . . . . . . . . . . .  27
       4.9.  Retrieval-Augmented Generation Metrics  . . . . . . . . .  27
         4.9.1.  Embedding Latency . . . . . . . . . . . . . . . . . .  28
         4.9.2.  Retrieval Latency . . . . . . . . . . . . . . . . . .  28
         4.9.3.  Retrieval Recall  . . . . . . . . . . . . . . . . . .  29
         4.9.4.  Context Injection Overhead  . . . . . . . . . . . . .  29
         4.9.5.  Context Utilization Rate  . . . . . . . . . . . . . .  30
       4.10. Agentic and Compound System Metrics . . . . . . . . . . .  30
         4.10.1.  Task Completion Latency  . . . . . . . . . . . . . .  30
         4.10.2.  Sub-Request Count  . . . . . . . . . . . . . . . . .  31
         4.10.3.  Loop Incidence Rate  . . . . . . . . . . . . . . . .  31
         4.10.4.  Tool Execution Latency . . . . . . . . . . . . . . .  32
         4.10.5.  Agentic Goodput  . . . . . . . . . . . . . . . . . .  32
       4.11. Quality and Policy Enforcement Metrics  . . . . . . . . .  32
         4.11.1.  Policy Violation Rate  . . . . . . . . . . . . . . .  33
         4.11.2.  False Refusal Rate . . . . . . . . . . . . . . . . .  33
         4.11.3.  Guardrail Processing Overhead  . . . . . . . . . . .  34
       4.12. Service Level Objective Metrics . . . . . . . . . . . . .  34
         4.12.1.  Service Level Objective  . . . . . . . . . . . . . .  34
         4.12.2.  SLO Attainment Rate  . . . . . . . . . . . . . . . .  35
         4.12.3.  Goodput  . . . . . . . . . . . . . . . . . . . . . .  35
     5.  Measurement Considerations  . . . . . . . . . . . . . . . . .  36
       5.1.  Workload Specification  . . . . . . . . . . . . . . . . .  36
       5.2.  Warm-up and Steady State  . . . . . . . . . . . . . . . .  36
       5.3.  Measurement Duration  . . . . . . . . . . . . . . . . . .  36
       5.4.  Clock Synchronization . . . . . . . . . . . . . . . . . .  37
       5.5.  System Configuration  . . . . . . . . . . . . . . . . . .  37
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  37
       6.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  37
       6.2.  Side-Channel Information Leakage  . . . . . . . . . . . .  37
       6.3.  Resource Exhaustion Attacks . . . . . . . . . . . . . . .  38
       6.4.  Model Extraction  . . . . . . . . . . . . . . . . . . . .  38
       6.5.  Benchmark Gaming  . . . . . . . . . . . . . . . . . . . .  38
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  39
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  39
     Appendix A.  Supplementary Metrics  . . . . . . . . . . . . . . .  40
       A.1.  Energy and Sustainability Metrics . . . . . . . . . . . .  40
         A.1.1.  Energy per Token  . . . . . . . . . . . . . . . . . .  40
         A.1.2.  Tokens per Joule  . . . . . . . . . . . . . . . . . .  40
         A.1.3.  Instantaneous Power Draw  . . . . . . . . . . . . . .  41
         A.1.4.  Peak Power Draw . . . . . . . . . . . . . . . . . . .  41
         A.1.5.  Idle Power Draw . . . . . . . . . . . . . . . . . . .  42
         A.1.6.  Carbon Intensity  . . . . . . . . . . . . . . . . . .  42
       A.2.  Economic and Cost Metrics . . . . . . . . . . . . . . . .  42



  Gaikwad                   Expires 24 July 2026                  [Page 3]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


         A.2.1.  Cost per Million Tokens . . . . . . . . . . . . . . .  42
         A.2.2.  GPU-Hours per Request . . . . . . . . . . . . . . . .  43
         A.2.3.  Throughput-Cost Ratio . . . . . . . . . . . . . . . .  43
       A.3.  Hardware Utilization Metrics  . . . . . . . . . . . . . .  44
         A.3.1.  Compute Utilization . . . . . . . . . . . . . . . . .  44
         A.3.2.  Memory Bandwidth Utilization  . . . . . . . . . . . .  44
         A.3.3.  KV Cache Memory . . . . . . . . . . . . . . . . . . .  44
         A.3.4.  Memory Fragmentation  . . . . . . . . . . . . . . . .  45
       A.4.  Distributed Serving Metrics . . . . . . . . . . . . . . .  45
         A.4.1.  Tensor Parallel Efficiency  . . . . . . . . . . . . .  45
         A.4.2.  Pipeline Parallel Efficiency  . . . . . . . . . . . .  46
         A.4.3.  Expert Parallel Load Imbalance  . . . . . . . . . . .  46
         A.4.4.  Collective Communication Latency  . . . . . . . . . .  47
       A.5.  Quantization and Precision Metrics  . . . . . . . . . . .  47
         A.5.1.  Precision Mode  . . . . . . . . . . . . . . . . . . .  47
         A.5.2.  Quantization Speedup  . . . . . . . . . . . . . . . .  47
         A.5.3.  Quantization Memory Reduction . . . . . . . . . . . .  48
         A.5.4.  Quantization Accuracy Impact  . . . . . . . . . . . .  48
       A.6.  Operational Lifecycle Metrics . . . . . . . . . . . . . .  49
         A.6.1.  Model Load Time . . . . . . . . . . . . . . . . . . .  49
         A.6.2.  Cold Start Latency  . . . . . . . . . . . . . . . . .  49
         A.6.3.  Warm-up Duration  . . . . . . . . . . . . . . . . . .  49
         A.6.4.  Scale-Up Latency  . . . . . . . . . . . . . . . . . .  50
       A.7.  Long-Context Metrics  . . . . . . . . . . . . . . . . . .  50
         A.7.1.  Maximum Context Length  . . . . . . . . . . . . . . .  50
         A.7.2.  Context Window Utilization  . . . . . . . . . . . . .  51
         A.7.3.  Long-Context Latency Scaling  . . . . . . . . . . . .  51
     Appendix B.  Cross-Reference Index  . . . . . . . . . . . . . . .  51
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  54

  1.  Introduction

     Large Language Model inference serving has emerged as a distinct
     category of network service with performance characteristics unlike
     traditional request-response systems.  The autoregressive generation
     process produces output tokens sequentially, creating a streaming
     response pattern where latency has multiple meaningful definitions.
     The prefill and decode phases exhibit different computational
     profiles.  Memory consumption grows with sequence length due to key-
     value cache requirements.

     Large Language Model serving systems are increasingly deployed as
     Internet-facing services, often exposed via standardized APIs and
     shared infrastructure.  Their performance characteristics influence
     availability, fairness, and side-channel risk in multi-tenant
     environments.  Establishing consistent benchmarking terminology
     enables clearer communication among implementers, operators, and
     researchers.



  Gaikwad                   Expires 24 July 2026                  [Page 4]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Despite widespread deployment of LLM serving systems, no standard
     terminology exists for describing their performance.  Different
     implementations, benchmarks, and academic publications use
     inconsistent definitions for terms such as "throughput," "latency,"
     and "tokens per second."  This inconsistency hinders meaningful
     comparison across systems and creates confusion for practitioners.

     This document addresses the terminology gap by providing precise
     definitions for LLM serving performance metrics.  The structure and
     approach follow [RFC2647], which established benchmarking terminology
     for firewall performance.  Each term includes a definition,
     discussion of context and implementation considerations, unit of
     measurement, open issues, and cross-references to related terms.

     This document defines terminology only.  It does not specify
     benchmark methodologies, workload profiles, or acceptance criteria.
     Companion documents may address those topics.

     The metrics in this document apply to transformer-based
     autoregressive language models.  Other model architectures such as
     diffusion models, encoder-only models, or non-autoregressive decoders
     require different terminology not covered here.

  2.  Scope and System Under Test Boundary

     A prerequisite for benchmarking is defining the System Under Test
     (SUT) boundary.  The same metric measured at different boundaries
     yields different values.  This document identifies three SUT boundary
     categories:

     Model Engine:  The inference runtime executing model forward passes.
        This boundary excludes network transport, authentication, request
        routing, and safety filtering.  Metrics at this boundary reflect
        raw inference capability.

     Application Gateway:  The model engine plus request handling,
        authentication, rate limiting, input validation, output filtering,
        and safety mechanisms.  Metrics at this boundary reflect the
        performance users observe when calling an API endpoint.

     Compound System:  An application gateway plus orchestration logic,
        retrieval components, tool execution, and multi-step reasoning.
        Metrics at this boundary reflect end-to-end task completion
        performance for agentic or retrieval-augmented workloads.

     Testers MUST declare the SUT boundary when reporting metrics.
     Metrics from different SUT boundaries MUST NOT be directly compared
     without adjustment.



  Gaikwad                   Expires 24 July 2026                  [Page 5]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     The measurement point within the SUT also affects results.  For
     latency metrics, testers MUST specify whether measurement occurs at
     the client, at the network edge, or within the serving
     infrastructure.

  3.  Requirements Language

     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, and only when, they appear in all
     capitals, as shown here.

  4.  Terminology

  4.1.  Request and Response Timing Metrics

  4.1.1.  End-to-End Latency

     Definition:  The elapsed time between request initiation by a client
        and receipt of the complete response by that client.

     Discussion:  End-to-end latency encompasses all processing stages:
        network transmission, queuing, prefill computation, decode
        iterations, output filtering, and return transmission.  For
        streaming responses, end-to-end latency is measured until the
        final token is received.

        End-to-end latency depends on output length.  Longer responses
        require more decode iterations and produce higher latency.  When
        comparing systems, testers SHOULD control for output length or
        report latency normalized by output token count.

        Client-side measurement includes network round-trip time.  Server-
        side measurement excludes external network latency but may still
        include internal network hops within a distributed serving system.

     Unit of measurement:  milliseconds (ms) or seconds (s)

     Issues:
        *  Measurement point (client-side vs server-side)

        *  Treatment of failed or truncated responses

        *  Clock synchronization for distributed measurement

     See also:  Time to First Token (Section 4.1.2), Time per Output Token
        (Section 4.1.5), Decode Latency (Section 4.2.2)



  Gaikwad                   Expires 24 July 2026                  [Page 6]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.1.2.  Time to First Token

     Definition:  The elapsed time between request initiation and receipt
        of the first output token.

     Discussion:  Time to First Token (TTFT) measures how long a user
        waits before any response content appears.  For interactive
        applications, TTFT determines perceived responsiveness independent
        of total response length.

        TTFT includes network transmission, authentication, admission
        control, queue wait time, and prefill computation.  Under low load
        with short prompts, prefill dominates TTFT.  Under high load,
        queue wait time may dominate.  With long prompts, prefill
        computation scales with input token count.

        For non-streaming responses, TTFT equals end-to-end latency
        because all tokens arrive together.  Testers SHOULD specify
        whether the response mode is streaming or non-streaming.

        Some systems emit an empty or whitespace-only first token before
        substantive content.  Testers MUST specify whether TTFT measures
        time to any token or time to first non-empty token.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Streaming vs non-streaming response modes

        *  Definition of "first token" when initial tokens lack content

        *  Client-side vs server-side measurement point

     See also:  Prefill Latency (Section 4.2.1), Queue Wait Time
        (Section 4.5.3), End-to-End Latency (Section 4.1.1)

  4.1.3.  Inter-Token Latency

     Definition:  The elapsed time between consecutive output token
        emissions, measured at the server.

     Discussion:  Inter-Token Latency (ITL) measures the generation
        interval between adjacent tokens during the decode phase.  ITL
        reflects decode efficiency and is affected by batch size, model
        architecture, and memory bandwidth.






  Gaikwad                   Expires 24 July 2026                  [Page 7]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        ITL varies across tokens within a single request due to batching
        dynamics.  When other requests join or leave the batch, the per-
        request compute allocation changes.  Testers SHOULD report ITL
        distribution statistics rather than a single value.

        ITL is measured server-side and excludes network transmission
        delay.  For client-observed intervals, see Time Between Tokens
        (Section 4.1.4).

        When aggregating ITL across requests, token-weighted averaging
        counts each token equally.  Request-weighted averaging counts each
        request equally regardless of length.  These methods yield
        different results.  Testers MUST specify the aggregation method.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Token-weighted vs request-weighted aggregation

        *  Variation within a single request due to batching

        *  Exclusion of prefill-to-first-token interval

     See also:  Time Between Tokens (Section 4.1.4), Time per Output Token
        (Section 4.1.5), Batch Utilization (Section 4.5.5)

  4.1.4.  Time Between Tokens

     Definition:  The elapsed time between receipt of consecutive output
        tokens at the client.

     Discussion:  Time Between Tokens (TBT) measures the client-observed
        interval between adjacent tokens.  TBT equals ITL plus network
        transmission variability and buffering effects.

        Network jitter, TCP buffering, and intermediary proxies cause TBT
        to differ from ITL.  Multiple tokens may arrive in a single
        network packet, producing near-zero TBT followed by a longer gap.

        TBT directly affects user-perceived streaming smoothness.  High
        TBT variance creates a "stuttering" appearance even when average
        TBT is acceptable.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Network buffering causing token bunching




  Gaikwad                   Expires 24 July 2026                  [Page 8]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        *  Proxy and CDN effects on delivery timing

        *  Measurement requires client-side instrumentation

     See also:  Inter-Token Latency (Section 4.1.3), Token Delivery Jitter
        (Section 4.4.3)

  4.1.5.  Time per Output Token

     Definition:  The average time to generate each output token after the
        first token, computed as:

        TPOT = (End-to-End Latency - TTFT) / (Output Token Count - 1)

     Discussion:  Time per Output Token (TPOT) summarizes decode-phase
        performance in a single value.  Unlike ITL, which measures each
        interval, TPOT averages across all decode steps for a request.

        TPOT excludes the first token because TTFT captures that interval
        separately.  For single-token outputs, TPOT is undefined.

        TPOT is request-weighted by construction: each request contributes
        one TPOT value regardless of output length.  When aggregating
        across requests, report the distribution rather than only the
        mean.

        TPOT relates to user-perceived generation speed.  A TPOT of 50ms
        corresponds to 20 tokens per second, approximately 900 words per
        minute for English text.

     Unit of measurement:  milliseconds per token (ms/token)

     Issues:
        *  Undefined for single-token outputs

        *  Request-weighted aggregation differs from token-weighted ITL

        *  Denominator uses (Output Token Count - 1)

     See also:  Inter-Token Latency (Section 4.1.3), End-to-End Latency
        (Section 4.1.1), Time to First Token (Section 4.1.2)

  4.1.6.  Normalized Latency

     Definition:  End-to-end latency divided by output token count,
        yielding a length-independent latency measure.

     Discussion:  Normalized latency enables comparison across requests



  Gaikwad                   Expires 24 July 2026                  [Page 9]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        with different output lengths.  It amortizes fixed overhead (TTFT)
        across all tokens.

        For short outputs, TTFT dominates normalized latency.  For long
        outputs, TPOT dominates.  Testers SHOULD report output length
        distribution alongside normalized latency to enable
        interpretation.

        Normalized latency obscures user-facing behavior because users
        experience TTFT and TPOT separately.  Testers SHOULD NOT report
        normalized latency as the sole latency metric.

     Unit of measurement:  milliseconds per token (ms/token)

     Issues:
        *  Obscures distinction between TTFT and decode latency

        *  Sensitive to output length distribution

        *  Not directly interpretable as user experience

     See also:  End-to-End Latency (Section 4.1.1), Time per Output Token
        (Section 4.1.5)

  4.2.  Phase-Specific Latency Metrics

  4.2.1.  Prefill Latency

     Definition:  The elapsed time to process input tokens and compute the
        initial key-value cache prior to generating the first output
        token.

     Discussion:  Prefill performs a forward pass over all input tokens to
        populate the key-value cache.  This computation is parallelizable
        across the input sequence and is compute-bound on current
        hardware.

        Prefill latency scales approximately linearly with input token
        count for uncached inputs.  With prefix caching enabled, prefill
        processes only the uncached suffix, reducing latency for requests
        sharing common prefixes.

        Prefill latency is a component of TTFT.  Other TTFT components
        include queue wait time, network latency, and authentication
        overhead.






  Gaikwad                   Expires 24 July 2026                 [Page 10]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        Chunked prefill implementations split long prefills into smaller
        segments interleaved with decode steps.  This reduces head-of-line
        blocking but increases total prefill time.  Testers MUST specify
        whether chunked prefill is enabled.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Chunked vs monolithic prefill execution

        *  Prefix caching effects on effective prefill length

        *  Distinction from TTFT in reporting

     See also:  Time to First Token (Section 4.1.2), Prefix Cache Hit Rate
        (Section 4.7.1), Head-of-Line Blocking (Section 4.5.1)

  4.2.2.  Decode Latency

     Definition:  The cumulative elapsed time spent generating output
        tokens after the first token.

     Discussion:  Decode latency equals (Output Token Count - 1)
        multiplied by average ITL.  It measures total time in the decode
        phase.

        Decode is memory-bandwidth-bound on current hardware because each
        step reads the full model weights and growing key-value cache
        while producing a single token.

        Decode latency grows linearly with output token count under
        constant batching conditions.  Variable batch membership during
        generation causes decode latency to deviate from simple linear
        scaling.

     Unit of measurement:  milliseconds (ms) or seconds (s)

     Issues:
        *  Variation due to dynamic batching

        *  Growth of key-value cache during decode

     See also:  Inter-Token Latency (Section 4.1.3), End-to-End Latency
        (Section 4.1.1), Prefill Latency (Section 4.2.1)







  Gaikwad                   Expires 24 July 2026                 [Page 11]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.3.  Throughput and Capacity Metrics

  4.3.1.  Output Token Throughput

     Definition:  The number of output tokens generated per second by the
        system across all concurrent requests.

     Discussion:  Output token throughput measures system-wide generation
        capacity.  It increases with offered load until the system
        saturates, then plateaus or declines.

        Throughput measurement requires specifying the token counting
        method.  Subword tokenization produces different counts than word-
        level tokenization for the same text.  Testers MUST identify the
        tokenizer used.

        Some implementations pad sequences to uniform length within a
        batch.  Testers MUST specify whether throughput counts include or
        exclude padding tokens.

        Throughput measurement requires a defined time window.  Short
        windows capture instantaneous throughput.  Longer windows smooth
        over load variations.  Testers MUST specify the measurement window
        duration.

     Unit of measurement:  tokens per second (tok/s)

     Issues:
        *  Tokenizer-dependent token counts

        *  Inclusion or exclusion of padding tokens

        *  Measurement window duration

     See also:  Input Token Throughput (Section 4.3.2), Request Throughput
        (Section 4.3.3), Non-Padding Token Throughput (Section 4.3.4)

  4.3.2.  Input Token Throughput

     Definition:  The number of input tokens processed per second by the
        system across all concurrent requests.

     Discussion:  Input token throughput measures prefill capacity.
        Systems with efficient batched prefill achieve higher input
        throughput than those processing prompts sequentially.






  Gaikwad                   Expires 24 July 2026                 [Page 12]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        Input throughput differs from output throughput because prefill
        and decode have different computational characteristics.  A system
        optimized for long-context prefill may show high input throughput
        but lower output throughput, and vice versa.

        Prefix caching affects input throughput measurement.  With
        caching, input tokens divide into cache hits (not processed) and
        cache misses (processed).  Testers MUST specify whether input
        throughput counts all input tokens or only cache misses.

     Unit of measurement:  tokens per second (tok/s)

     Issues:
        *  Treatment of cached vs processed input tokens

        *  Different from output throughput due to phase characteristics

     See also:  Output Token Throughput (Section 4.3.1), Prefill Latency
        (Section 4.2.1), Prefix Cache Hit Rate (Section 4.7.1)

  4.3.3.  Request Throughput

     Definition:  The number of requests completed per second.

     Discussion:  Request throughput counts completed requests regardless
        of token counts.  A system completing many short requests achieves
        higher request throughput than one completing fewer long requests,
        even at equal token throughput.

        Request throughput is relevant for capacity planning when requests
        have predictable lengths or when per-request overhead dominates.

        Failed requests require specified handling.  Testers MUST specify
        whether request throughput includes only successful completions or
        also counts failures.

     Unit of measurement:  requests per second (req/s)

     Issues:
        *  Treatment of failed or truncated requests

        *  Sensitivity to request length distribution

     See also:  Output Token Throughput (Section 4.3.1), End-to-End
        Latency (Section 4.1.1)






  Gaikwad                   Expires 24 July 2026                 [Page 13]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.3.4.  Non-Padding Token Throughput

     Definition:  Output token throughput excluding padding or alignment
        tokens.

     Discussion:  Batched inference pads sequences to uniform length.
        Padding tokens consume compute but carry no information.  Non-
        padding throughput measures useful work.

        Systems using variable-length batching or continuous batching may
        avoid padding entirely.  For these systems, non-padding throughput
        equals total output throughput.

     Unit of measurement:  tokens per second (tok/s)

     Issues:
        *  Applicable only to padded batching schemes

     See also:  Output Token Throughput (Section 4.3.1), Batch Utilization
        (Section 4.5.5)

  4.3.5.  Offered Load

     Definition:  The request arrival rate or concurrency level imposed on
        the system by the workload generator.

     Discussion:  Offered load characterizes workload intensity.  Two
        forms exist:

        Open-loop load specifies a request arrival rate (requests per
        second) independent of system response.  New requests arrive
        according to a specified distribution regardless of outstanding
        request count.

        Closed-loop load specifies a fixed concurrency level.  Each
        completed request triggers a new request, maintaining constant
        outstanding requests.

        Open-loop load reveals system behavior under overload.  Closed-
        loop load cannot exceed system capacity by construction.  Testers
        MUST specify the load model and its parameters.

     Unit of measurement:  requests per second (req/s) for open-loop;
        concurrent requests for closed-loop

     Issues:
        *  Open-loop vs closed-loop model selection




  Gaikwad                   Expires 24 July 2026                 [Page 14]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        *  Arrival distribution for open-loop (Poisson, uniform, bursty)

        *  Think time between requests for closed-loop

     See also:  Sustainable Load (Section 4.3.6), Queue Depth
        (Section 4.5.2)

  4.3.6.  Sustainable Load

     Definition:  The maximum offered load at which the system continues
        to meet declared service objectives.

     Discussion:  Sustainable load identifies the operating region
        boundary.  Below sustainable load, the system meets latency and
        quality targets.  Above sustainable load, latency increases
        unboundedly or requests fail.

        Sustainable load depends on the service objectives.  Stricter
        latency targets yield lower sustainable load.  Testers MUST
        declare the service objectives when reporting sustainable load.

        Sustainable load also depends on workload characteristics.  Longer
        prompts or outputs reduce sustainable load.  Testers MUST
        characterize the workload profile.

     Unit of measurement:  requests per second (req/s) or concurrent
        requests

     Issues:
        *  Requires declared service objectives

        *  Sensitive to workload characteristics

        *  May differ for different SLO percentiles

     See also:  Offered Load (Section 4.3.5), Service Level Objective
        (Section 4.12.1), SLO Attainment Rate (Section 4.12.2)

  4.4.  Latency Distribution Metrics

  4.4.1.  Latency Percentiles

     Definition:  Values below which a specified percentage of
        observations fall, reported as P50, P90, P95, P99, and P99.9 for
        latency metrics.

     Discussion:  Mean latency obscures distribution shape.  A system with




  Gaikwad                   Expires 24 July 2026                 [Page 15]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        low mean but high variance provides inconsistent user experience.
        Percentiles characterize the distribution.

        P50 (median) indicates typical experience.  P99 indicates worst-
        case experience for most users.  P99.9 indicates extreme tail
        behavior relevant for high-volume services.

        Percentile computation requires sufficient sample size.  For P99
        accuracy, at least 1000 samples are needed.  For P99.9, at least
        10000 samples.  Testers MUST report sample size alongside
        percentiles.

        Percentiles apply to TTFT, TPOT, ITL, and end-to-end latency.
        Testers SHOULD report percentiles for multiple metrics rather than
        a single summary.

     Unit of measurement:  Same as the underlying latency metric (ms)

     Issues:
        *  Sample size requirements for tail percentiles

        *  Appropriate percentile selection for use case

        *  Confidence intervals for reported percentiles

     See also:  End-to-End Latency (Section 4.1.1), Time to First Token
        (Section 4.1.2), Time per Output Token (Section 4.1.5)

  4.4.2.  Latency Distribution

     Definition:  The complete statistical distribution of latency
        observations, represented as a histogram or cumulative
        distribution function.

     Discussion:  Full distributions reveal structure that percentiles
        miss.  Multimodal distributions indicate distinct operating
        regimes.  Heavy tails indicate outlier sensitivity.

        Histogram bin width affects resolution.  Narrow bins reveal detail
        but require more samples.  Testers SHOULD use logarithmic binning
        for latency distributions spanning multiple orders of magnitude.

     Unit of measurement:  Histogram counts or cumulative probability

     Issues:
        *  Bin width selection

        *  Sample size for distribution estimation



  Gaikwad                   Expires 24 July 2026                 [Page 16]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     See also:  Latency Percentiles (Section 4.4.1)

  4.4.3.  Token Delivery Jitter

     Definition:  The variance or standard deviation of inter-token
        intervals within a single request.

     Discussion:  Jitter measures streaming smoothness.  Low jitter
        indicates consistent token pacing.  High jitter indicates
        irregular delivery that users perceive as stuttering.

        Jitter arises from batching dynamics, memory bandwidth contention,
        and garbage collection pauses.  Systems with continuous batching
        show higher jitter than static batching due to variable batch
        membership.

        Jitter is computed per-request, then aggregated.  Report the
        distribution of per-request jitter values.

     Unit of measurement:  milliseconds (ms) as standard deviation

     Issues:
        *  Aggregation method across requests

        *  Separating server-side jitter from network jitter

     See also:  Inter-Token Latency (Section 4.1.3), Time Between Tokens
        (Section 4.1.4)

  4.4.4.  Maximum Pause Duration

     Definition:  The longest inter-token interval observed within a
        single request.

     Discussion:  Maximum pause captures the worst interruption in
        streaming output.  A single long pause degrades user experience
        even when average ITL is acceptable.

        Long pauses arise from garbage collection, KV cache operations,
        batch recomputation after preemption, and request scheduling
        delays.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Distinguishing generation pauses from network delays

        *  Threshold for "pause" vs normal variation



  Gaikwad                   Expires 24 July 2026                 [Page 17]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     See also:  Inter-Token Latency (Section 4.1.3), Token Delivery Jitter
        (Section 4.4.3), Preemption Recovery Latency (Section 4.6.4)

  4.5.  Scheduling and Multi-Tenancy Metrics

  4.5.1.  Head-of-Line Blocking

     Definition:  The additional delay experienced by short requests when
        scheduled behind long requests in a shared queue or batch.

     Discussion:  First-come-first-served scheduling causes head-of-line
        (HOL) blocking.  A long prefill operation delays all subsequent
        requests regardless of their size.

        Chunked prefill mitigates HOL blocking by limiting the maximum
        uninterruptible computation.  Shortest-job-first scheduling
        eliminates HOL blocking but requires output length prediction.

        HOL blocking is measured as the difference between observed
        latency and latency under an idealized scheduler with no blocking.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Requires baseline comparison to quantify

        *  Depends on workload length distribution

     See also:  Prefill Latency (Section 4.2.1), Queue Wait Time
        (Section 4.5.3), Fairness Index (Section 4.5.4)

  4.5.2.  Queue Depth

     Definition:  The number of requests waiting for service at a
        measurement instant.

     Discussion:  Queue depth indicates load relative to capacity.
        Growing queue depth signals approaching overload.  Stable queue
        depth indicates balanced load.

        Queue depth has multiple measurement points: admission queue,
        prefill queue, decode batch wait queue.  Testers MUST specify the
        queue measured.

     Unit of measurement:  requests (count)

     Issues:
        *  Multiple queue stages in serving systems



  Gaikwad                   Expires 24 July 2026                 [Page 18]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        *  Instantaneous vs time-averaged measurement

     See also:  Offered Load (Section 4.3.5), Queue Wait Time
        (Section 4.5.3)

  4.5.3.  Queue Wait Time

     Definition:  The elapsed time between request arrival and scheduling
        for processing.

     Discussion:  Queue wait time is a component of TTFT representing time
        spent waiting rather than computing.  Under low load, queue wait
        approaches zero.  Under high load, queue wait dominates TTFT.

        Systems with multiple queues (admission, prefill, decode) have
        corresponding wait times.  Total queue wait is the sum across
        stages.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Multiple queue stages

        *  Inclusion of admission control delay

     See also:  Time to First Token (Section 4.1.2), Queue Depth
        (Section 4.5.2), Admission Rate (Section 4.5.6)

  4.5.4.  Fairness Index

     Definition:  A measure of equity in latency or throughput across
        concurrent requests or tenants.

     Discussion:  Jain's Fairness Index quantifies allocation equality:

        J(x) = (sum(x_i))^2 / (n * sum(x_i^2))

        where x_i is the allocation to request or tenant i, and n is the
        count.  J ranges from 1/n (maximally unfair) to 1 (perfectly
        fair).

        Fairness applies to latency (lower is better, so use reciprocal),
        throughput, or SLO attainment.  Testers MUST specify the measured
        quantity.

        Multi-tenant systems require per-tenant fairness measurement.
        Single-tenant systems measure fairness across concurrent requests.




  Gaikwad                   Expires 24 July 2026                 [Page 19]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Unit of measurement:  dimensionless, range [1/n, 1]

     Issues:
        *  Choice of measured quantity (latency, throughput, SLO
           attainment)

        *  Tenant definition in multi-tenant systems

     See also:  Head-of-Line Blocking (Section 4.5.1), SLO Attainment Rate
        (Section 4.12.2)

  4.5.5.  Batch Utilization

     Definition:  The ratio of active tokens processed per batch to the
        maximum batch capacity.

     Discussion:  Static batching pads sequences to uniform length.  Batch
        utilization measures the fraction of compute applied to real
        tokens versus padding.

        Continuous batching achieves high utilization by avoiding padding.
        For continuous batching systems, batch utilization approaches 1.0
        and is less informative.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Not meaningful for continuous batching systems

        *  Varies with workload length distribution

     See also:  Non-Padding Token Throughput (Section 4.3.4), Output Token
        Throughput (Section 4.3.1)

  4.5.6.  Admission Rate

     Definition:  The fraction of arriving requests accepted for
        processing.

     Discussion:  Admission control rejects requests to prevent overload.
        Admission rate below 1.0 indicates load shedding.

        Rejected requests may receive an error response or be redirected.
        Testers MUST specify the rejection behavior.

     Unit of measurement:  ratio or percentage





  Gaikwad                   Expires 24 July 2026                 [Page 20]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Issues:
        *  Rejection behavior (error vs redirect)

        *  Distinction from content-based refusals

     See also:  Offered Load (Section 4.3.5), Sustainable Load
        (Section 4.3.6), False Refusal Rate (Section 4.11.2)

  4.6.  Preemption and Resource Management Metrics

  4.6.1.  Preemption Rate

     Definition:  The fraction of in-flight requests evicted from
        processing before completion.

     Discussion:  Memory pressure or priority policies cause request
        preemption.  Preempted requests lose their key-value cache state
        and must recompute it upon resumption.

        High preemption rates indicate memory over-subscription or
        aggressive scheduling.  Preemption degrades latency for affected
        requests.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Distinction between temporary preemption and permanent eviction

        *  Treatment of requests that are preempted multiple times

     See also:  Preemption Loss (Section 4.6.2), Preemption Recovery
        Latency (Section 4.6.4), KV Cache Swap Rate (Section 4.6.5)

  4.6.2.  Preemption Loss

     Definition:  The computational work discarded when a request is
        preempted, measured as tokens generated before preemption that
        must be recomputed.

     Discussion:  Preemption discards key-value cache state.  Upon
        resumption, the system recomputes prefill for all tokens (input
        plus previously generated output).  This recomputation is wasted
        work.

        Preemption loss contributes to tail latency.  Requests preempted
        late in generation lose more work than those preempted early.

     Unit of measurement:  tokens or milliseconds of recomputation



  Gaikwad                   Expires 24 July 2026                 [Page 21]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Issues:
        *  Measurement requires tracking recomputed tokens

        *  Multiple preemptions accumulate loss

     See also:  Preemption Rate (Section 4.6.1), Preemption Recovery
        Latency (Section 4.6.4)

  4.6.3.  Starvation Rate

     Definition:  The fraction of requests waiting longer than a specified
        threshold before receiving any service.

     Discussion:  Starvation occurs when scheduling policies indefinitely
        delay certain requests.  Priority inversion and unbounded queue
        growth cause starvation.

        The starvation threshold depends on application requirements.
        Testers MUST declare the threshold when reporting starvation rate.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Threshold selection is application-dependent

        *  Distinction from queue wait time distribution tail

     See also:  Queue Wait Time (Section 4.5.3), Fairness Index
        (Section 4.5.4)

  4.6.4.  Preemption Recovery Latency

     Definition:  The elapsed time from preemption to resumption of token
        generation.

     Discussion:  Recovery latency includes: wait time for scheduling, KV
        cache reload or recomputation, and prefill of previously generated
        tokens.

        Systems with KV cache offloading to host memory recover faster
        than those requiring full recomputation.  Recovery latency varies
        with the amount of generated output at preemption time.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Variation based on progress at preemption




  Gaikwad                   Expires 24 July 2026                 [Page 22]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        *  Offloading vs recomputation recovery strategies

     See also:  Preemption Rate (Section 4.6.1), Preemption Loss
        (Section 4.6.2), KV Cache Swap Rate (Section 4.6.5)

  4.6.5.  KV Cache Swap Rate

     Definition:  The frequency at which key-value cache blocks are
        migrated between accelerator memory and host memory.

     Discussion:  Memory-constrained systems swap KV cache to host memory
        when accelerator memory is exhausted.  Swapping enables higher
        concurrency at the cost of swap latency.

        Swap rate indicates memory pressure.  High swap rates degrade
        latency due to PCIe transfer overhead.

     Unit of measurement:  swaps per second or bytes per second

     Issues:
        *  Granularity of swap operations (per-request vs per-block)

        *  Distinction between swap-out and swap-in rates

     See also:  Preemption Rate (Section 4.6.1), Page Fault Latency
        (Section 4.6.6)

  4.6.6.  Page Fault Latency

     Definition:  The latency incurred when accessing KV cache blocks not
        resident in accelerator memory.

     Discussion:  Paged attention systems fault in KV cache blocks on
        demand.  Page fault latency includes PCIe transfer time from host
        memory or storage.

        Fault latency increases ITL for affected decode steps.
        Prefetching strategies aim to hide fault latency.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Prefetching effectiveness

        *  Storage tier latency (DRAM vs SSD)

     See also:  KV Cache Swap Rate (Section 4.6.5), Inter-Token Latency
        (Section 4.1.3)



  Gaikwad                   Expires 24 July 2026                 [Page 23]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.7.  Prefix Caching Metrics

  4.7.1.  Prefix Cache Hit Rate

     Definition:  The fraction of input tokens whose key-value
        representations are retrieved from cache rather than computed.

     Discussion:  Prefix caching stores KV cache state for common prompt
        prefixes.  Subsequent requests sharing a cached prefix skip
        prefill for those tokens.

        Hit rate depends on workload locality.  Workloads with shared
        system prompts achieve high hit rates.  Workloads with unique
        prompts achieve low hit rates.

        Hit rate is computed as cached tokens divided by total input
        tokens across requests.  Per-request hit rate varies; report the
        distribution.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Granularity of cache matching (exact prefix vs subsequence)

        *  Multi-tenant cache isolation

     See also:  Prefill Latency (Section 4.2.1), Time to First Token
        (Section 4.1.2), Cache Eviction Rate (Section 4.7.3)

  4.7.2.  Prefix Cache Capacity

     Definition:  The total memory allocated for storing reusable KV cache
        entries.

     Discussion:  Cache capacity limits the number and length of prefixes
        stored.  Larger capacity enables more prefixes or longer prefixes
        at the cost of memory available for active requests.

        Capacity is often expressed as a fraction of total accelerator
        memory or as maximum cacheable token count.

     Unit of measurement:  bytes, tokens, or percentage of accelerator
        memory

     Issues:
        *  Trade-off with memory for active requests

        *  Dynamic vs static allocation



  Gaikwad                   Expires 24 July 2026                 [Page 24]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     See also:  Prefix Cache Hit Rate (Section 4.7.1), Cache Eviction Rate
        (Section 4.7.3)

  4.7.3.  Cache Eviction Rate

     Definition:  The frequency at which cached prefix entries are removed
        to accommodate new entries.

     Discussion:  Eviction occurs when cache capacity is exhausted.  High
        eviction rates indicate insufficient capacity for the workload's
        prefix diversity.

        Eviction policies (LRU, frequency-based) affect which prefixes
        remain cached.  Testers SHOULD specify the eviction policy.

     Unit of measurement:  evictions per second or evictions per request

     Issues:
        *  Eviction policy effects

        *  Distinguishing capacity eviction from staleness eviction

     See also:  Prefix Cache Hit Rate (Section 4.7.1), Prefix Cache
        Capacity (Section 4.7.2)

  4.7.4.  TTFT Reduction from Caching

     Definition:  The reduction in TTFT attributable to prefix cache hits,
        computed as TTFT without caching minus TTFT with caching.

     Discussion:  This metric quantifies caching benefit.  It depends on
        both hit rate and the length of cached prefixes.

        Measurement requires comparing TTFT with caching enabled versus
        disabled, or estimating based on prefill latency per token.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Requires baseline measurement without caching

        *  Varies with cached prefix length

     See also:  Prefix Cache Hit Rate (Section 4.7.1), Time to First Token
        (Section 4.1.2), Prefill Latency (Section 4.2.1)

  4.8.  Speculative Decoding Metrics




  Gaikwad                   Expires 24 July 2026                 [Page 25]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.8.1.  Draft Acceptance Rate

     Definition:  The fraction of tokens proposed by a draft model that
        are accepted by the target model.

     Discussion:  Speculative decoding uses a smaller draft model to
        propose multiple tokens verified in parallel by the target model.
        Higher acceptance rates yield greater speedup.

        Acceptance rate depends on draft model quality and alignment with
        the target model.  Rates vary by domain; code and structured text
        achieve higher rates than creative writing.

        Acceptance rate is computed per speculation window, then averaged.
        Report the distribution across windows.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Variation across domains and prompts

        *  Dependence on draft model selection

     See also:  Speculative Speedup (Section 4.8.2), Draft Overhead
        (Section 4.8.3)

  4.8.2.  Speculative Speedup

     Definition:  The ratio of decoding throughput with speculative
        decoding enabled to throughput with speculative decoding disabled.

     Discussion:  Speedup depends on acceptance rate and the relative cost
        of draft and target model inference.  High acceptance with low
        draft cost yields high speedup.

        Speculative decoding increases TTFT due to draft model prefill.
        Speedup applies to the decode phase only.  End-to-end speedup is
        lower, especially for short outputs.

     Unit of measurement:  ratio (dimensionless)

     Issues:
        *  Excludes TTFT overhead

        *  Varies with acceptance rate

     See also:  Draft Acceptance Rate (Section 4.8.1), Draft Overhead
        (Section 4.8.3), Output Token Throughput (Section 4.3.1)



  Gaikwad                   Expires 24 July 2026                 [Page 26]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.8.3.  Draft Overhead

     Definition:  The additional latency or compute cost introduced by the
        draft model.

     Discussion:  Draft model inference adds to prefill time and per-step
        decode time.  This overhead must be recovered through acceptance
        to achieve net speedup.

        Overhead is measured as additional latency per speculation window
        or as fraction of total compute.

     Unit of measurement:  milliseconds (ms) or percentage of total
        latency

     Issues:
        *  Amortization over speculation window length

        *  Memory overhead for draft model weights

     See also:  Draft Acceptance Rate (Section 4.8.1), Speculative Speedup
        (Section 4.8.2)

  4.8.4.  Verification Throughput

     Definition:  The number of draft tokens verified per second by the
        target model.

     Discussion:  Verification throughput measures the target model's
        capacity to check draft proposals.  Higher verification throughput
        enables longer speculation windows.

        Verification processes multiple tokens in parallel, achieving
        higher throughput than autoregressive generation of the same
        tokens.

     Unit of measurement:  tokens per second (tok/s)

     Issues:
        *  Distinction from generation throughput

        *  Variation with speculation window length

     See also:  Draft Acceptance Rate (Section 4.8.1), Output Token
        Throughput (Section 4.3.1)

  4.9.  Retrieval-Augmented Generation Metrics




  Gaikwad                   Expires 24 July 2026                 [Page 27]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.9.1.  Embedding Latency

     Definition:  The elapsed time to convert query text into vector
        representations for retrieval.

     Discussion:  Retrieval-Augmented Generation (RAG) systems embed
        queries before searching a vector store.  Embedding latency adds
        to TTFT.

        Embedding models are smaller and faster than generation models.
        Embedding latency is a minor TTFT component for most deployments.

        Batched embedding of multiple queries achieves higher throughput
        than sequential embedding.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Batched vs sequential embedding

        *  Embedding model selection effects

     See also:  Retrieval Latency (Section 4.9.2), Time to First Token
        (Section 4.1.2)

  4.9.2.  Retrieval Latency

     Definition:  The elapsed time to search a vector store and fetch
        relevant documents.

     Discussion:  Retrieval latency includes vector similarity search,
        optional reranking, and document fetching.  It is a component of
        TTFT for RAG systems.

        Retrieval latency depends on index size, search algorithm, and
        number of results.  Approximate nearest neighbor search trades
        accuracy for speed.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Index size and algorithm effects

        *  Reranking inclusion

     See also:  Embedding Latency (Section 4.9.1), Time to First Token
        (Section 4.1.2), Context Injection Overhead (Section 4.9.4)




  Gaikwad                   Expires 24 July 2026                 [Page 28]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.9.3.  Retrieval Recall

     Definition:  The fraction of relevant documents retrieved from the
        corpus.

     Discussion:  Recall measures retrieval effectiveness.  Low recall
        causes the generation model to lack relevant context.  This is a
        quality metric, not a performance metric, but affects overall
        system evaluation.

        Measuring recall requires ground-truth relevance labels.  For
        benchmarking without labels, use proxy metrics such as answer
        correctness.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Requires ground-truth relevance labels

        *  Trade-off with retrieval latency

     See also:  Retrieval Latency (Section 4.9.2), Context Utilization
        Rate (Section 4.9.5)

  4.9.4.  Context Injection Overhead

     Definition:  The additional prefill latency caused by retrieved
        context tokens.

     Discussion:  Retrieved documents increase prompt length, increasing
        prefill computation.  This overhead scales with retrieved token
        count.

        The overhead is the difference between prefill latency with
        retrieved context and prefill latency without it.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Varies with retrieval result length

        *  Interaction with context length limits

     See also:  Prefill Latency (Section 4.2.1), Retrieval Latency
        (Section 4.9.2)






  Gaikwad                   Expires 24 July 2026                 [Page 29]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.9.5.  Context Utilization Rate

     Definition:  The fraction of retrieved context tokens that materially
        influence the generated response.

     Discussion:  Not all retrieved content contributes to generation.
        Low utilization indicates retrieval of irrelevant content, wasting
        context window capacity and prefill compute.

        Utilization is difficult to measure directly.  Proxy measurements
        include attention weight analysis and ablation studies.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Indirect measurement required

        *  Attribution challenges

     See also:  Retrieval Recall (Section 4.9.3), Context Injection
        Overhead (Section 4.9.4)

  4.10.  Agentic and Compound System Metrics

  4.10.1.  Task Completion Latency

     Definition:  The elapsed time for a compound system to satisfy a user
        intent, encompassing all LLM calls, retrieval steps, and tool
        executions.

     Discussion:  Agentic systems perform multiple internal operations per
        user request.  Task completion latency measures the full user-
        facing response time.

        Task completion latency depends on the number of internal steps,
        which varies by task complexity.  Simple tasks complete in one LLM
        call.  Complex tasks require multiple calls with tool use.

     Unit of measurement:  seconds (s)

     Issues:
        *  Variation with task complexity

        *  Definition of task completion for open-ended tasks

     See also:  Sub-Request Count (Section 4.10.2), Tool Execution Latency
        (Section 4.10.4)




  Gaikwad                   Expires 24 July 2026                 [Page 30]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.10.2.  Sub-Request Count

     Definition:  The number of internal LLM inference requests triggered
        by a single user interaction.

     Discussion:  Agentic systems decompose user requests into multiple
        LLM calls for planning, reasoning, and action.  Sub-request count
        indicates system complexity and affects total latency and cost.

        High sub-request counts indicate complex reasoning chains or retry
        loops.  Testers SHOULD examine sub-request count distributions to
        identify inefficient patterns.

     Unit of measurement:  count

     Issues:
        *  Includes retries and failed attempts

        *  Varies with task complexity

     See also:  Task Completion Latency (Section 4.10.1), Loop Incidence
        Rate (Section 4.10.3)

  4.10.3.  Loop Incidence Rate

     Definition:  The fraction of tasks where the agent enters a
        repetitive control flow without making progress.

     Discussion:  Agentic loops occur when the system repeats similar
        actions without advancing toward task completion.  Loops indicate
        planning failures or tool errors.

        Loop detection requires defining "progress" for the task domain.
        Common heuristics include action repetition count and state
        similarity thresholds.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Progress definition is task-dependent

        *  Distinguishing loops from legitimate retries

     See also:  Sub-Request Count (Section 4.10.2), Task Completion
        Latency (Section 4.10.1)






  Gaikwad                   Expires 24 July 2026                 [Page 31]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.10.4.  Tool Execution Latency

     Definition:  The elapsed time for external tool calls invoked by the
        agent.

     Discussion:  Agents call external tools for information retrieval,
        computation, or actions.  Tool latency contributes to task
        completion latency.

        Tool latency varies by tool type.  Local computation completes in
        milliseconds.  External API calls require seconds.

     Unit of measurement:  milliseconds (ms) or seconds (s)

     Issues:
        *  High variance across tool types

        *  External dependencies outside system control

     See also:  Task Completion Latency (Section 4.10.1), Sub-Request
        Count (Section 4.10.2)

  4.10.5.  Agentic Goodput

     Definition:  The fraction of tasks completed successfully while
        meeting declared task-level objectives.

     Discussion:  Agentic goodput combines completion rate and quality.  A
        task that completes but produces incorrect results does not count
        toward goodput.

        Objective definitions are task-specific.  Testers MUST declare
        objectives and evaluation criteria.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Task-specific objective definitions

        *  Evaluation criteria for correctness

     See also:  Task Completion Latency (Section 4.10.1), SLO Attainment
        Rate (Section 4.12.2)

  4.11.  Quality and Policy Enforcement Metrics






  Gaikwad                   Expires 24 July 2026                 [Page 32]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  4.11.1.  Policy Violation Rate

     Definition:  The fraction of responses that violate declared content
        or safety policies.

     Discussion:  Safety systems filter outputs to prevent harmful
        content.  Policy violation rate measures filter failure.

        Violation detection requires evaluation against policy criteria.
        Automated classifiers or human review provide measurements.

        Low violation rate indicates effective filtering.  Very low rates
        may indicate overly restrictive filtering causing false refusals.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Policy definition and scope

        *  Detection method reliability

     See also:  False Refusal Rate (Section 4.11.2), Guardrail Processing
        Overhead (Section 4.11.3)

  4.11.2.  False Refusal Rate

     Definition:  The fraction of benign, policy-compliant requests that
        are incorrectly refused.

     Discussion:  Overly sensitive safety filters refuse legitimate
        requests.  False refusals degrade user experience and system
        utility.

        Measuring false refusals requires labeled benign requests.
        Testers MUST specify the evaluation dataset and labeling criteria.

        False refusal rate trades off against policy violation rate.
        Stricter filtering reduces violations but increases false
        refusals.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Requires labeled benign test set

        *  Trade-off with policy violation rate

     See also:  Policy Violation Rate (Section 4.11.1), Admission Rate



  Gaikwad                   Expires 24 July 2026                 [Page 33]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        (Section 4.5.6)

  4.11.3.  Guardrail Processing Overhead

     Definition:  The additional latency introduced by safety, policy, or
        content filtering mechanisms.

     Discussion:  Guardrails add processing before, during, or after
        generation.  Input filters add to TTFT.  Output filters add to
        end-to-end latency.

        Overhead is measured by comparing latency with guardrails enabled
        versus disabled.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Baseline measurement without guardrails

        *  Multiple guardrail stages with distinct overhead

     See also:  Time to First Token (Section 4.1.2), End-to-End Latency
        (Section 4.1.1), Policy Violation Rate (Section 4.11.1)

  4.12.  Service Level Objective Metrics

  4.12.1.  Service Level Objective

     Definition:  A quantitative threshold for a performance metric that
        defines acceptable service quality.

     Discussion:  SLOs specify targets such as:

        *  P99 TTFT below 500ms

        *  P95 TPOT below 50ms

        *  Error rate below 0.1%

        SLOs derive from user experience requirements and business
        constraints.  Different applications require different SLOs.

        SLO definitions include the metric, percentile, threshold, and
        measurement window.  Testers MUST fully specify SLOs when
        reporting attainment.

     Unit of measurement:  not applicable (SLO is a specification, not a
        measurement)



  Gaikwad                   Expires 24 July 2026                 [Page 34]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Issues:
        *  Application-specific requirements

        *  Multiple SLOs may apply simultaneously

     See also:  SLO Attainment Rate (Section 4.12.2), Sustainable Load
        (Section 4.3.6)

  4.12.2.  SLO Attainment Rate

     Definition:  The fraction of requests or time periods meeting all
        declared SLOs.

     Discussion:  Attainment rate summarizes SLO compliance.  Request-
        based attainment counts requests meeting SLOs.  Time-based
        attainment counts measurement windows where aggregate metrics meet
        SLOs.

        Attainment below 1.0 indicates SLO violations.  The acceptable
        attainment level depends on SLA commitments.

     Unit of measurement:  ratio or percentage

     Issues:
        *  Request-based vs time-based measurement

        *  Handling of multiple simultaneous SLOs

     See also:  Service Level Objective (Section 4.12.1), Sustainable Load
        (Section 4.3.6)

  4.12.3.  Goodput

     Definition:  The throughput of requests that complete successfully
        and meet SLO requirements.

     Discussion:  Goodput equals total throughput multiplied by SLO
        attainment rate.  It measures useful, compliant work rather than
        raw capacity.

        Systems with high throughput but low attainment achieve low
        goodput.  Goodput captures the throughput-quality trade-off.

     Unit of measurement:  requests per second (req/s) or tokens per
        second (tok/s)

     Issues:
        *  Requires defined SLOs



  Gaikwad                   Expires 24 July 2026                 [Page 35]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        *  May use request or token basis

     See also:  SLO Attainment Rate (Section 4.12.2), Output Token
        Throughput (Section 4.3.1), Request Throughput (Section 4.3.3)

  5.  Measurement Considerations

  5.1.  Workload Specification

     Benchmarks MUST specify the workload used for measurement:

     *  Input length distribution (mean, percentiles, min, max)

     *  Output length distribution or generation parameters

     *  Request arrival pattern (open-loop rate or closed-loop
        concurrency)

     *  Dataset source or generation method

     *  Tokenizer used for length calculations

     Workload characteristics affect all metrics.  Results from different
     workloads are not directly comparable.

  5.2.  Warm-up and Steady State

     Systems require warm-up before reaching steady-state performance.
     Warm-up effects include:

     *  JIT compilation of kernels

     *  Memory allocator warm-up

     *  Prefix cache population

     *  Batch size ramp-up

     Testers MUST exclude warm-up from measurement or report it
     separately.  Testers SHOULD document the warm-up procedure and
     duration.

  5.3.  Measurement Duration

     Measurement windows MUST be long enough to capture steady-state
     behavior and sufficient samples for statistical reliability.

     For percentile measurements:



  Gaikwad                   Expires 24 July 2026                 [Page 36]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     *  P50 requires at least 100 samples

     *  P99 requires at least 1,000 samples

     *  P99.9 requires at least 10,000 samples

     Testers MUST report sample counts alongside percentiles.

  5.4.  Clock Synchronization

     Distributed systems require synchronized clocks for latency
     measurement.  Clock skew introduces measurement error.

     Testers SHOULD use NTP or PTP for clock synchronization and report
     the synchronization method and estimated accuracy.

  5.5.  System Configuration

     Benchmarks MUST report system configuration:

     *  Hardware: accelerator model, count, memory, interconnect

     *  Software: serving framework, version, model format

     *  Model: architecture, parameter count, precision

     *  Serving: batching strategy, parallelism configuration

     *  Tuning: any non-default configuration parameters

     Results are specific to the reported configuration.

  6.  Security Considerations

  6.1.  Threat Model

     This section considers adversaries who submit requests designed to
     degrade service for other users or extract information about the
     system or other users' requests.

     Performance benchmarking itself does not introduce security
     vulnerabilities.  However, performance characteristics may be
     exploited by adversaries.

  6.2.  Side-Channel Information Leakage

     Shared infrastructure creates side-channel risks.




  Gaikwad                   Expires 24 July 2026                 [Page 37]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Timing channels: Request latency depends on queue depth, batch
     composition, and cache state influenced by other users.  An adversary
     observing their own request latency may infer information about
     concurrent requests.

     Cache channels: Prefix caching creates observable timing differences
     between cache hits and misses.  An adversary may probe for cached
     prefixes to learn about other users' prompts.

     Batch channels: Continuous batching causes ITL variation based on
     batch membership changes.  An adversary may infer when other requests
     arrive or complete.

     Mitigation strategies include request isolation, timing noise
     injection, and partitioned caching.  These mitigations affect
     performance.  Testers evaluating multi-tenant systems SHOULD measure
     side-channel leakage alongside performance.

  6.3.  Resource Exhaustion Attacks

     Adversaries may craft requests to exhaust system resources:

     Memory exhaustion: Requests with long outputs grow KV cache until
     memory is exhausted.  Systems without output length limits or memory
     management are vulnerable.

     Compute exhaustion: Long input sequences maximize prefill compute.
     Pathological inputs may trigger worst-case attention patterns.

     Queue exhaustion: Bursts of requests exceed admission capacity.
     Without rate limiting, legitimate requests are delayed or rejected.

     The metrics Sustainable Load (Section 4.3.6), and Admission Rate
     (Section 4.5.6) characterize resilience to resource exhaustion.

  6.4.  Model Extraction

     High-volume query access enables model extraction attacks where an
     adversary trains a copy of the model from input-output pairs.  This
     document does not define rate-limiting terminology.  Deployments
     concerned with model extraction SHOULD implement and monitor rate
     limits.

  6.5.  Benchmark Gaming

     Systems may be optimized for benchmark workloads in ways that do not
     generalize to production traffic.  Testers SHOULD use diverse
     workloads representative of intended deployment.



  Gaikwad                   Expires 24 July 2026                 [Page 38]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  7.  References

  7.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  7.2.  Informative References

     [RFC1242]  Bradner, S., "Benchmarking Terminology for Network
                Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
                July 1991, <https://www.rfc-editor.org/info/rfc1242>.

     [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
                Network Interconnect Devices", RFC 2544,
                DOI 10.17487/RFC2544, March 1999,
                <https://www.rfc-editor.org/info/rfc2544>.

     [RFC2647]  Newman, D., "Benchmarking Terminology for Firewall
                Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999,
                <https://www.rfc-editor.org/info/rfc2647>.

     [MLPERF]   Reddi, V. J., "MLPerf Inference Benchmark", Proceedings of
                the ACM/IEEE International Symposium on Computer
                Architecture (ISCA), DOI 10.1109/ISCA45697.2020.00045,
                2020, <https://doi.org/10.1109/ISCA45697.2020.00045>.

     [VLLM]     Kwon, W., "Efficient Memory Management for Large Language
                Model Serving with PagedAttention", Proceedings of the ACM
                Symposium on Operating Systems Principles (SOSP),
                DOI 10.1145/3600006.3613165, 2023,
                <https://doi.org/10.1145/3600006.3613165>.

     [ORCA]     Yu, G., "Orca: A Distributed Serving System for
                Transformer-Based Generative Models", Proceedings of the
                USENIX Symposium on Operating Systems Design and
                Implementation (OSDI), 2022.

     [SARATHI]  Agrawal, A., "Taming Throughput-Latency Tradeoff in LLM
                Inference with Sarathi-Serve", Proceedings of the USENIX
                Symposium on Operating Systems Design and Implementation
                (OSDI), 2024.



  Gaikwad                   Expires 24 July 2026                 [Page 39]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     [ATTENTION]
                Vaswani, A., "Attention Is All You Need", Advances in
                Neural Information Processing Systems (NeurIPS), 2017.

     [JAIN]     Jain, R., Chiu, D., and W. Hawe, "A Quantitative Measure
                of Fairness and Discrimination for Resource Allocation in
                Shared Computer Systems", DEC Research Report TR-301,
                September 1984.

  Appendix A.  Supplementary Metrics

     This appendix defines metrics relevant for production deployment
     decisions but not essential for basic performance characterization.

  A.1.  Energy and Sustainability Metrics

  A.1.1.  Energy per Token

     Definition:  The energy consumed to generate one output token.

     Discussion:  Energy per token enables efficiency comparison across
        systems and sustainability analysis.  The value depends on model
        size, hardware, batch size, and workload.

        Measurement requires power monitoring integrated with token
        counting.  GPU power is accessible via vendor APIs (NVML for
        NVIDIA).  Total system power requires external instrumentation.

        Energy per token differs between prefill and decode phases.
        Testers SHOULD report phase-separated energy when feasible.

     Unit of measurement:  Joules per token (J/tok) or millijoules per
        token (mJ/tok)

     Issues:
        *  Measurement boundary (GPU vs system)

        *  Phase attribution

     See also:  Tokens per Joule (Appendix A.1.2), Output Token Throughput
        (Section 4.3.1)

  A.1.2.  Tokens per Joule

     Definition:  The number of output tokens generated per Joule of
        energy.

     Discussion:  Tokens per Joule is the inverse of energy per token,



  Gaikwad                   Expires 24 July 2026                 [Page 40]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        expressing energy efficiency.  Higher values indicate greater
        efficiency.

     Unit of measurement:  tokens per Joule (tok/J)

     Issues:  Same as Energy per Token

     See also:  Energy per Token (Appendix A.1.1)

  A.1.3.  Instantaneous Power Draw

     Definition:  The electrical power consumed at a given instant.

     Discussion:  Power draw varies with load.  Idle systems consume less
        power than systems under load.  Prefill phases consume more power
        than decode phases due to higher compute utilization.

        Testers MUST specify the measurement boundary: GPU only, GPU and
        CPU, or entire system including cooling.

     Unit of measurement:  Watts (W)

     Issues:
        *  Measurement boundary specification

        *  Sampling rate for time-varying power

     See also:  Peak Power Draw (Appendix A.1.4), Idle Power Draw
        (Appendix A.1.5)

  A.1.4.  Peak Power Draw

     Definition:  The maximum instantaneous power observed during a
        measurement interval.

     Discussion:  Peak power determines infrastructure requirements for
        power delivery and cooling.  Systems may have brief power spikes
        exceeding average consumption.

     Unit of measurement:  Watts (W)

     Issues:
        *  Sampling rate may miss brief spikes

        *  Relationship to thermal design power (TDP)

     See also:  Instantaneous Power Draw (Appendix A.1.3)




  Gaikwad                   Expires 24 July 2026                 [Page 41]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  A.1.5.  Idle Power Draw

     Definition:  The power consumed when the system is ready to serve but
        not processing requests.

     Discussion:  Idle power represents the baseline cost of provisioned
        capacity.  The difference between loaded and idle power indicates
        dynamic power range.

     Unit of measurement:  Watts (W)

     Issues:  Definition of idle (model loaded, empty batch)

     See also:  Instantaneous Power Draw (Appendix A.1.3)

  A.1.6.  Carbon Intensity

     Definition:  The greenhouse gas emissions per token or per request.

     Discussion:  Carbon intensity equals energy consumption multiplied by
        the grid's carbon factor (gCO2e/kWh).  Grid carbon intensity
        varies by location and time.

        Testers reporting carbon metrics MUST specify the grid carbon
        factor used.

     Unit of measurement:  grams CO2 equivalent per token (gCO2e/tok)

     Issues:
        *  Grid carbon factor variation

        *  Scope of emissions (operational only or including embodied)

     See also:  Energy per Token (Appendix A.1.1)

  A.2.  Economic and Cost Metrics

  A.2.1.  Cost per Million Tokens

     Definition:  The monetary cost to generate one million output tokens.

     Discussion:  Cost includes compute (hardware amortization or rental),
        energy, and operations.  Testers MUST specify included cost
        components.

        Cloud pricing provides a market cost reference.  Self-hosted
        deployments require cost modeling.




  Gaikwad                   Expires 24 July 2026                 [Page 42]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Unit of measurement:  currency per million tokens (e.g., $/Mtok)

     Issues:
        *  Cost component inclusion

        *  Pricing model assumptions

     See also:  GPU-Hours per Request (Appendix A.2.2), Throughput-Cost
        Ratio (Appendix A.2.3)

  A.2.2.  GPU-Hours per Request

     Definition:  The accelerator time consumed to complete one request.

     Discussion:  GPU-hours measures resource consumption independent of
        hardware cost.  For multi-GPU deployments, report aggregate GPU-
        hours.

        GPU-hours equals end-to-end latency multiplied by GPU count used
        for the request.

     Unit of measurement:  GPU-hours

     Issues:
        *  Fractional allocation in multi-tenant systems

        *  GPU count for distributed inference

     See also:  End-to-End Latency (Section 4.1.1), Cost per Million
        Tokens (Appendix A.2.1)

  A.2.3.  Throughput-Cost Ratio

     Definition:  The ratio of sustainable throughput to infrastructure
        cost.

     Discussion:  Higher ratios indicate better cost efficiency.  Testers
        MUST specify the throughput metric (tokens or requests) and cost
        basis (hourly rental or amortized ownership).

     Unit of measurement:  tokens per second per dollar-hour (tok/s/$h)

     Issues:
        *  Cost basis selection

        *  Throughput metric selection

     See also:  Sustainable Load (Section 4.3.6), Cost per Million Tokens



  Gaikwad                   Expires 24 July 2026                 [Page 43]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        (Appendix A.2.1)

  A.3.  Hardware Utilization Metrics

  A.3.1.  Compute Utilization

     Definition:  The fraction of available compute capacity in use.

     Discussion:  Compute utilization indicates how effectively the system
        uses accelerator compute resources.  Low utilization suggests
        memory bandwidth or scheduling bottlenecks.

        For GPUs, utilization metrics include SM occupancy and tensor core
        utilization.  Testers MUST specify the utilization metric.

     Unit of measurement:  percentage

     Issues:
        *  Multiple utilization definitions (SM, tensor core, etc.)

        *  Vendor-specific measurement tools

     See also:  Memory Bandwidth Utilization (Appendix A.3.2)

  A.3.2.  Memory Bandwidth Utilization

     Definition:  The fraction of peak memory bandwidth consumed.

     Discussion:  LLM decode is memory-bandwidth-bound on current
        hardware.  High bandwidth utilization indicates the system is
        limited by memory throughput rather than compute.

     Unit of measurement:  percentage

     Issues:
        *  Measurement tool availability

        *  Cache effects on apparent bandwidth

     See also:  Compute Utilization (Appendix A.3.1)

  A.3.3.  KV Cache Memory

     Definition:  The memory consumed by key-value cache for active
        requests.

     Discussion:  KV cache memory grows with batch size and sequence
        length.  Memory exhaustion limits concurrent request capacity.



  Gaikwad                   Expires 24 July 2026                 [Page 44]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


        KV cache memory equals: batch_size * sequence_length * num_layers
        * 2 * hidden_dim * precision_bytes

     Unit of measurement:  gigabytes (GB) or percentage of accelerator
        memory

     Issues:
        *  Variation with batch composition

        *  Paged vs contiguous allocation

     See also:  KV Cache Swap Rate (Section 4.6.5), Page Fault Latency
        (Section 4.6.6)

  A.3.4.  Memory Fragmentation

     Definition:  The fraction of free memory unusable for new allocations
        due to non-contiguous layout.

     Discussion:  Memory fragmentation reduces effective capacity.  Paged
        attention systems achieve low fragmentation through fine-grained
        allocation.

     Unit of measurement:  percentage

     Issues:
        *  Allocator-specific measurement

        *  Definition of "unusable" depends on minimum allocation size

     See also:  KV Cache Memory (Appendix A.3.3)

  A.4.  Distributed Serving Metrics

  A.4.1.  Tensor Parallel Efficiency

     Definition:  The ratio of achieved throughput to ideal linear scaling
        with tensor parallelism degree.

     Discussion:  Tensor parallelism partitions model layers across
        accelerators.  Communication overhead reduces efficiency below
        ideal scaling.

        Efficiency equals throughput with N GPUs divided by (N times
        single-GPU throughput).

     Unit of measurement:  percentage




  Gaikwad                   Expires 24 July 2026                 [Page 45]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Issues:
        *  Baseline single-GPU measurement

        *  Communication topology effects

     See also:  Pipeline Parallel Efficiency (Appendix A.4.2), Collective
        Communication Latency (Appendix A.4.4)

  A.4.2.  Pipeline Parallel Efficiency

     Definition:  The ratio of achieved throughput to ideal linear scaling
        with pipeline parallelism depth.

     Discussion:  Pipeline parallelism partitions model layers into
        sequential stages.  Pipeline bubbles (idle time during fill and
        drain) reduce efficiency.

        Bubble fraction equals (P-1)/(P-1+M) where P is pipeline depth and
        M is microbatch count.

     Unit of measurement:  percentage

     Issues:
        *  Microbatch count selection

        *  Stage imbalance effects

     See also:  Tensor Parallel Efficiency (Appendix A.4.1)

  A.4.3.  Expert Parallel Load Imbalance

     Definition:  The deviation of token routing from uniform distribution
        across experts in Mixture-of-Experts models.

     Discussion:  Load imbalance causes some experts to become bottlenecks
        while others are underutilized.  Imbalance metrics include
        coefficient of variation or max/mean ratio.

     Unit of measurement:  dimensionless ratio or percentage

     Issues:
        *  Imbalance metric selection

        *  Dynamic variation across batches

     See also:  Tensor Parallel Efficiency (Appendix A.4.1)





  Gaikwad                   Expires 24 July 2026                 [Page 46]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  A.4.4.  Collective Communication Latency

     Definition:  The latency of collective operations (all-reduce, all-
        gather) used in distributed inference.

     Discussion:  Collective communication occurs between forward pass
        segments in tensor-parallel inference.  This latency adds to per-
        token generation time.

     Unit of measurement:  microseconds (us) or milliseconds (ms)

     Issues:
        *  Operation type specification

        *  Message size effects

     See also:  Tensor Parallel Efficiency (Appendix A.4.1), Inter-Token
        Latency (Section 4.1.3)

  A.5.  Quantization and Precision Metrics

  A.5.1.  Precision Mode

     Definition:  The numerical representation for model weights and
        activations.

     Discussion:  Common precision modes include FP32, FP16, BF16, FP8,
        INT8, and INT4.  Lower precision reduces memory and increases
        throughput at potential accuracy cost.

        Mixed precision uses different precisions for different tensors.
        Testers MUST specify precision for weights, activations, and KV
        cache separately if they differ.

     Unit of measurement:  not applicable (categorical specification)

     Issues:
        *  Mixed precision specification

        *  KV cache precision separate from weights

     See also:  Quantization Speedup (Appendix A.5.2), Quantization
        Accuracy Impact (Appendix A.5.4)

  A.5.2.  Quantization Speedup

     Definition:  The throughput improvement from quantization relative to
        a baseline precision.



  Gaikwad                   Expires 24 July 2026                 [Page 47]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Discussion:  Speedup equals quantized throughput divided by baseline
        throughput.  Testers MUST specify the baseline precision.

     Unit of measurement:  dimensionless ratio

     Issues:
        *  Baseline precision selection

        *  Workload effects on speedup

     See also:  Precision Mode (Appendix A.5.1), Quantization Memory
        Reduction (Appendix A.5.3)

  A.5.3.  Quantization Memory Reduction

     Definition:  The reduction in model memory from quantization relative
        to a baseline precision.

     Discussion:  Memory reduction enables larger batch sizes or longer
        sequences.  Reduction equals 1 minus (quantized size divided by
        baseline size).

     Unit of measurement:  percentage

     Issues:
        *  Baseline precision selection

        *  Overhead from quantization metadata

     See also:  Precision Mode (Appendix A.5.1), KV Cache Memory
        (Appendix A.3.3)

  A.5.4.  Quantization Accuracy Impact

     Definition:  The change in model quality metrics due to quantization.

     Discussion:  Quantization may degrade accuracy.  Impact is measured
        on task- specific benchmarks or perplexity.

        Testers MUST specify the evaluation benchmark and baseline.

     Unit of measurement:  percentage points or absolute score change

     Issues:
        *  Benchmark selection

        *  Task-specific variation




  Gaikwad                   Expires 24 July 2026                 [Page 48]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     See also:  Precision Mode (Appendix A.5.1)

  A.6.  Operational Lifecycle Metrics

  A.6.1.  Model Load Time

     Definition:  The elapsed time from process start to model readiness
        for serving.

     Discussion:  Load time includes weight loading from storage, memory
        allocation, and initialization.  Load time affects scale-up
        responsiveness in autoscaling deployments.

     Unit of measurement:  seconds (s)

     Issues:
        *  Storage medium effects (local vs network)

        *  Parallelism in loading

     See also:  Cold Start Latency (Appendix A.6.2), Scale-Up Latency
        (Appendix A.6.4)

  A.6.2.  Cold Start Latency

     Definition:  The latency of the first request after system
        initialization.

     Discussion:  Cold start latency exceeds steady-state latency due to
        JIT compilation, cache population, and memory allocation.

        Cold start affects user experience for scale-to-zero deployments
        and after restarts.

     Unit of measurement:  milliseconds (ms)

     Issues:
        *  Definition of cold (first request vs first after idle)

        *  JIT compilation effects

     See also:  Model Load Time (Appendix A.6.1), Warm-up Duration
        (Appendix A.6.3)

  A.6.3.  Warm-up Duration

     Definition:  The time or request count until latency stabilizes at
        steady state.



  Gaikwad                   Expires 24 July 2026                 [Page 49]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     Discussion:  Warm-up accounts for JIT compilation, cache warming, and
        allocator stabilization.  Testers SHOULD exclude warm-up from
        steady-state measurements.

     Unit of measurement:  seconds (s) or request count

     Issues:
        *  Stability definition

        *  Workload effects on warm-up

     See also:  Cold Start Latency (Appendix A.6.2)

  A.6.4.  Scale-Up Latency

     Definition:  The elapsed time to add serving capacity and begin
        handling traffic.

     Discussion:  Scale-up latency affects autoscaling responsiveness.  It
        includes instance provisioning, model loading, and warm-up.

     Unit of measurement:  seconds (s)

     Issues:
        *  Infrastructure-dependent (containers, VMs, bare metal)

        *  Warm traffic routing timing

     See also:  Model Load Time (Appendix A.6.1), Cold Start Latency
        (Appendix A.6.2)

  A.7.  Long-Context Metrics

  A.7.1.  Maximum Context Length

     Definition:  The maximum combined input and output token count
        supported by the system.

     Discussion:  Context length is limited by model architecture, memory
        capacity, and serving configuration.  Systems may support longer
        contexts than advertised at degraded performance.

     Unit of measurement:  tokens

     Issues:
        *  Architectural vs memory-constrained limits

        *  Performance degradation at maximum length



  Gaikwad                   Expires 24 July 2026                 [Page 50]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     See also:  Context Window Utilization (Appendix A.7.2)

  A.7.2.  Context Window Utilization

     Definition:  The fraction of maximum context length consumed by a
        request.

     Discussion:  Utilization equals (input tokens plus output tokens)
        divided by maximum context length.  High utilization stresses
        memory and may degrade performance.

     Unit of measurement:  percentage

     Issues:
        *  Maximum length definition

        *  Performance effects at high utilization

     See also:  Maximum Context Length (Appendix A.7.1)

  A.7.3.  Long-Context Latency Scaling

     Definition:  The rate at which latency increases with context length.

     Discussion:  Prefill latency scales linearly with input length for
        standard attention.  Decode latency scales with total sequence
        length due to growing KV cache access.

        Efficient attention mechanisms (sparse, linear) may achieve sub-
        linear scaling.

     Unit of measurement:  milliseconds per token (ms/tok) or scaling
        exponent

     Issues:
        *  Prefill vs decode scaling differs

        *  Architecture-dependent scaling

     See also:  Prefill Latency (Section 4.2.1), Decode Latency
        (Section 4.2.2)

  Appendix B.  Cross-Reference Index

     This index groups metrics by relationship for navigation.

     Latency metrics:




  Gaikwad                   Expires 24 July 2026                 [Page 51]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     *  End-to-End Latency (Section 4.1.1)

     *  Time to First Token (Section 4.1.2)

     *  Inter-Token Latency (Section 4.1.3)

     *  Time Between Tokens (Section 4.1.4)

     *  Time per Output Token (Section 4.1.5)

     *  Normalized Latency (Section 4.1.6)

     *  Prefill Latency (Section 4.2.1)

     *  Decode Latency (Section 4.2.2)

     Throughput metrics:

     *  Output Token Throughput (Section 4.3.1)

     *  Input Token Throughput (Section 4.3.2)

     *  Request Throughput (Section 4.3.3)

     *  Non-Padding Token Throughput (Section 4.3.4)

     *  Goodput (Section 4.12.3)

     Distribution metrics:

     *  Latency Percentiles (Section 4.4.1)

     *  Latency Distribution (Section 4.4.2)

     *  Token Delivery Jitter (Section 4.4.3)

     *  Maximum Pause Duration (Section 4.4.4)

     Scheduling metrics:

     *  Head-of-Line Blocking (Section 4.5.1)

     *  Queue Depth (Section 4.5.2)

     *  Queue Wait Time (Section 4.5.3)

     *  Fairness Index (Section 4.5.4)




  Gaikwad                   Expires 24 July 2026                 [Page 52]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     *  Batch Utilization (Section 4.5.5)

     *  Admission Rate (Section 4.5.6)

     Resource management metrics:

     *  Preemption Rate (Section 4.6.1)

     *  Preemption Loss (Section 4.6.2)

     *  Starvation Rate (Section 4.6.3)

     *  Preemption Recovery Latency (Section 4.6.4)

     *  KV Cache Swap Rate (Section 4.6.5)

     *  Page Fault Latency (Section 4.6.6)

     Caching metrics:

     *  Prefix Cache Hit Rate (Section 4.7.1)

     *  Prefix Cache Capacity (Section 4.7.2)

     *  Cache Eviction Rate (Section 4.7.3)

     *  TTFT Reduction from Caching (Section 4.7.4)

     Speculative decoding metrics:

     *  Draft Acceptance Rate (Section 4.8.1)

     *  Speculative Speedup (Section 4.8.2)

     *  Draft Overhead (Section 4.8.3)

     *  Verification Throughput (Section 4.8.4)

     RAG metrics:

     *  Embedding Latency (Section 4.9.1)

     *  Retrieval Latency (Section 4.9.2)

     *  Retrieval Recall (Section 4.9.3)

     *  Context Injection Overhead (Section 4.9.4)




  Gaikwad                   Expires 24 July 2026                 [Page 53]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


     *  Context Utilization Rate (Section 4.9.5)

     Agentic metrics:

     *  Task Completion Latency (Section 4.10.1)

     *  Sub-Request Count (Section 4.10.2)

     *  Loop Incidence Rate (Section 4.10.3)

     *  Tool Execution Latency (Section 4.10.4)

     *  Agentic Goodput (Section 4.10.5)

     Quality metrics:

     *  Policy Violation Rate (Section 4.11.1)

     *  False Refusal Rate (Section 4.11.2)

     *  Guardrail Processing Overhead (Section 4.11.3)

     SLO metrics:

     *  Service Level Objective (Section 4.12.1)

     *  SLO Attainment Rate (Section 4.12.2)

     *  Goodput (Section 4.12.3)

  Author's Address

     Madhava Gaikwad
     Independent Researcher
     Email: gaikwad.madhav@gmail.com
















  Gaikwad                   Expires 24 July 2026                 [Page 54]


