Skip to main content

Agent Protocol over MoQ
draft-liu-agent-protocol-over-moq-00

Document Type Active Internet-Draft (individual)
Authors Dapeng Liu , Suresh Krishnan
Last updated 2026-03-02
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-agent-protocol-over-moq-00
Network Working Group                                             D. Liu
Internet-Draft                                             Alibaba Cloud
Intended status: Standards Track                             S. Krishnan
Expires: 3 September 2026                                          Cisco
                                                              March 2026

                        Agent Protocol over MoQ
                  draft-liu-agent-protocol-over-moq-00

Abstract

   This document specifies a Agent-to-Agent communication framework
   enabling structured, low-latency, and semantically rich communication
   between autonomous agents over the Media over QUIC (MoQ) protocol.
   It leverages MoQ's efficient media transport capabilities while
   introducing a new application-layer framing mechanism to support
   control signaling, session management, and large data fragmentation.
   The design supports both intra-domain and inter-domain deployment,
   with an emphasis on interoperability, extensibility, and minimal
   overhead.

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 September 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

Liu & Krishnan          Expires 3 September 2026                [Page 1]
Internet-Draft           Agent Protocol over MoQ              March 2026

   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.  Requirements and Terminology  . . . . . . . . . . . . . . . .   3
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   4.  Agent to Agent Communication Frame Structure  . . . . . . . .   6
     4.1.  Frame Header Format . . . . . . . . . . . . . . . . . . .   6
     4.2.  Frame Payload . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Message Encoding Formats  . . . . . . . . . . . . . . . .   7
       4.3.1.  JSON Encoding . . . . . . . . . . . . . . . . . . . .   7
       4.3.2.  Binary Encoding for STREAM and DATA . . . . . . . . .   8
     4.4.  Message Type Details  . . . . . . . . . . . . . . . . . .   8
       4.4.1.  CMD Message Format  . . . . . . . . . . . . . . . . .   8
       4.4.2.  Subscription Management Fields  . . . . . . . . . . .   9
       4.4.3.  DATA Message Format . . . . . . . . . . . . . . . . .  10
       4.4.4.  STREAM Message Format . . . . . . . . . . . . . . . .  10
       4.4.5.  HEARTBEAT Message Format  . . . . . . . . . . . . . .  11
     4.5.  MoQ Mapping and Transport Considerations  . . . . . . . .  11
     4.6.  Pub/Sub Mechanism Integration . . . . . . . . . . . . . .  12
   5.  Session and Communication Model . . . . . . . . . . . . . . .  12
     5.1.  In-Session Communication (Recommended)  . . . . . . . . .  12
     5.2.  Session-Less Communication  . . . . . . . . . . . . . . .  13
   6.  Fragmentation and Large Data Handling . . . . . . . . . . . .  13
     6.1.  Small Signals (< 1400 bytes)  . . . . . . . . . . . . . .  13
     6.2.  Large Data (> 1400 bytes) . . . . . . . . . . . . . . . .  13
     6.3.  Streaming Media . . . . . . . . . . . . . . . . . . . . .  14
   7.  Transport and Domain Considerations . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Agent Protocol over MoQ Magic Number Registry . . . . . .  15
     9.2.  Agent Protocol over MoQ Version Registry  . . . . . . . .  15
     9.3.  Agent Protocol over MoQ Message Type Registry . . . . . .  15
     9.4.  Agent Protocol over MoQ Frame Flags Registry  . . . . . .  16
     9.5.  Well-Known URI Registration . . . . . . . . . . . . . . .  17
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  17
   11. Informative References  . . . . . . . . . . . . . . . . . . .  17
   Appendix A.  Appendix A: Usage Examples . . . . . . . . . . . . .  18
     A.1.  A.1 Scenario Overview . . . . . . . . . . . . . . . . . .  18
     A.2.  A.2 Stateless Communication (Session-Less)  . . . . . . .  18
       A.2.1.  A.2.1 Heartbeat Interaction . . . . . . . . . . . . .  18
     A.3.  A.3 Stateful Communication with Streaming Media . . . . .  18
       A.3.1.  A.3.1 Real-time Video Stream for Design Feedback  . .  19
       A.3.2.  A.3.2 Subscription Management Example . . . . . . . .  19

Liu & Krishnan          Expires 3 September 2026                [Page 2]
Internet-Draft           Agent Protocol over MoQ              March 2026

     A.4.  A.4 Stateful Communication with Large Data Blocks . . . .  20
       A.4.1.  A.4.1 Sending High-Res Design Assets  . . . . . . . .  20
     A.5.  A.5 Deployment Scenarios  . . . . . . . . . . . . . . . .  21
       A.5.1.  A.5.1 Intra-Domain (Same Edge Cluster)  . . . . . . .  21
       A.5.2.  A.5.2 Inter-Domain (Cross-Cloud Invocation) . . . . .  21
     A.6.  A.6 Summary Table of Interaction Types  . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   The multimodal capabilities of AI Agents, has created a need for a
   real-time communication framework that supports both media streaming
   and structured control signaling.  Existing protocols such as HTTP/2,
   gRPC, either suffer from head-of-line blocking or lack native support
   for real-time media and bidirectional streaming.

   Media over QUIC (MoQ) offers a compelling transport foundation with
   its low-latency, multiplexed, and connection-robust design.  However,
   MoQ is originally optimized for media delivery and lacks native
   semantics for agent-to-agent control, session establishment, and
   structured data exchange.

   This document proposes an application-layer protocol framework that
   operates over MoQ.  It introduces:

   *  A binary framing structure to carry both control and media
      payloads.

   *  A session management mechanism for multi-turn agent dialogues.

   *  Strategies for fragmenting large control signals with partial
      reliability.

   *  Support for both MoQ domain-local and internet-wide communication.

   The proposed framework is designed to be minimal, modular, and
   compatible with existing MoQ implementations.  It does not modify
   MoQ's transport semantics but instead defines a new application-layer
   envelope that can be carried within MoQ Objects or Datagrams.

2.  Requirements and Terminology

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

   MoQ:  Media over QUIC, a protocol for real-time media delivery.

Liu & Krishnan          Expires 3 September 2026                [Page 3]
Internet-Draft           Agent Protocol over MoQ              March 2026

   Agent:  An autonomous entity capable of sending and receiving
      structured commands and media.

   Session:  A logical dialogue between two agents, identified by a
      Session ID.

   Frame:  The basic unit of agent to agent communication, consisting of
      a header and payload.

3.  Architecture Overview

   Agent Protocol over MoQ operates as an application-layer protocol on
   top of MoQ.  The protocol stack is illustrated below:

Liu & Krishnan          Expires 3 September 2026                [Page 4]
Internet-Draft           Agent Protocol over MoQ              March 2026

      +-------------------------------------------------------------+
      |     Agent to Agent Communication - Application Logic        |
      |  (Agent Reasoning, Command Execution, Media Processing)     |
      +-------------------------------------------------------------+
                                    |
                                    v
      +-------------------------------------------------------------+
      |                                                             |
      |   Agent Protocol over MoQ Frame Layer (Header + Payload)    |
      |                                                             |
      |  +-------------------+  +-------------------------------+   |
      |  |   Frame Header    |  |       Frame Payload           |   |
      |  | - Magic Number    |  | - CMD (JSON)                  |   |
      |  | - Version         |  | - DATA (Binary chunks)        |   |
      |  | - Message Type    |  | - STREAM (Media samples)      |   |
      |  | - Session ID      |  | - HEARTBEAT (Empty)           |   |
      |  | - Stream ID       |  |                               |   |
      |  | - Flags           |  |                               |   |
      |  | - Payload Length  |  |                               |   |
      |  +-------------------+  +-------------------------------+   |
      +-------------------------------------------------------------+
                                    |
                                    v
      +-------------------------------------------------------------+
      |              Media Transport Layer (MoQ)                    |
      |                                                             |
      |   Track Management  |  Group/Object  |  Datagram Support    |
      |   Subscribe/Publish |  Prioritization|  Low-latency         |
      +-------------------------------------------------------------+
                                    |
                                    v
      +-------------------------------------------------------------+
      |                  Transport Layer (QUIC)                     |
      |                                                             |
      |   UDP-based  |  0-RTT Handshake  |  Stream Multiplexing     |
      |   TLS 1.3    |  Loss Recovery    |  Flow Control            |
      +-------------------------------------------------------------+

            Figure 1: Protocol Stack of Agent Protocol over MoQ

   The stack consists of four main layers:

   *  Transport Layer (QUIC): Provides UDP-based, low-latency transport
      with built-in encryption (TLS 1.3), 0-RTT connection
      establishment, stream multiplexing, and congestion control.

Liu & Krishnan          Expires 3 September 2026                [Page 5]
Internet-Draft           Agent Protocol over MoQ              March 2026

   *  Media Transport Layer (MoQ): Handles track-based pub/sub, group
      and object organization, priority management, and datagram support
      for real-time media delivery.

   *  Application Framing Layer: Defines the Agent Protocol over MoQ
      binary frame structure with fixed header fields and variable
      payload, enabling efficient encapsulation of different message
      types.

   *  Application Logic: Implements agent-specific functionality
      including reasoning engines, command interpretation, media
      processing, and business logic.

   Agents establish a MoQ session (via WebTransport or native QUIC
   client) and use one or more Tracks for communication.  Each agent-to-
   agent message is encapsulated in a binary frame before being sent as
   a MoQ Object or Datagram.  The framing layer provides session
   management, fragmentation support, and extensibility through version
   and flag fields.

4.  Agent to Agent Communication Frame Structure

   The Agent to Agent Communication frame is a binary structure designed
   for efficiency and extensibility.  It consists of a fixed-length
   header and a variable-length payload.

4.1.  Frame Header Format

   +=========+=========+============================+==================+
   | Field   |  Length | Description                | MoQ Mapping      |
   |         | (bytes) |                            |                  |
   +=========+=========+============================+==================+
   | Magic   |    2    | Identifier: 0xA2A2         | Detects agent-   |
   | Number  |         |                            | to-agent         |
   |         |         |                            | traffic          |
   +---------+---------+----------------------------+------------------+
   | Version |    1    | Protocol version (e.g.,    | Forward          |
   |         |         | 0x01)                      | compatibility    |
   +---------+---------+----------------------------+------------------+
   | Msg     |    1    | Message type: CMD(0x01),   | Route to         |
   | Type    |         | DATA(0x02), STREAM(0x03),  | handler          |
   |         |         | HEARTBEAT(0x04)            |                  |
   +---------+---------+----------------------------+------------------+
   | Session |    8    | Unique session identifier  | Correlate        |
   | ID      |         | (UUIDv7 or hash)           | multi-turn       |
   |         |         |                            | dialogues        |
   +---------+---------+----------------------------+------------------+
   | Stream  |    4    | Identifier for fragmented  | Reassemble       |

Liu & Krishnan          Expires 3 September 2026                [Page 6]
Internet-Draft           Agent Protocol over MoQ              March 2026

   | ID      |         | streams                    | large data       |
   +---------+---------+----------------------------+------------------+
   | Flags   |    1    | Bitmask: compressed(0x01), | Processing       |
   |         |         | encrypted(0x02),           | hints            |
   |         |         | fragmented(0x04)           |                  |
   +---------+---------+----------------------------+------------------+
   | Payload |    4    | Length of the following    | Parse boundary   |
   | Len     |         | payload                    |                  |
   +---------+---------+----------------------------+------------------+

                                  Table 1

4.2.  Frame Payload

   The payload is interpreted based on the Msg Type and Flags:

   *  CMD: JSON or MessagePack-encoded command structure.

   *  DATA: Raw binary chunk of a large file or buffer.

   *  STREAM: Raw media sample or simplified RTP-like header + frame.

   *  HEARTBEAT: Empty payload; used for liveness detection.

4.3.  Message Encoding Formats

   Agent Protocol over MoQ uses JSON (JavaScript Object Notation) as the
   standard encoding format for structured message content:

4.3.1.  JSON Encoding

   JSON (JavaScript Object Notation) is used for all CMD and control
   messages:

   *  *Human-readable* and widely supported across programming languages

   *  *Self-describing* with key-value pairs

   *  *Schema-flexible* allowing dynamic field addition

   *  *Standard library support* in most modern languages

   Example CMD message in JSON:

Liu & Krishnan          Expires 3 September 2026                [Page 7]
Internet-Draft           Agent Protocol over MoQ              March 2026

   {
     "action": "session_init",
     "session_id": "abc-123-def-456",
     "auth_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
     "capabilities": {
       "media_types": ["video/h264", "audio/opus"],
       "max_fragment_size": 1400
     }
   }

                                  Figure 2

4.3.2.  Binary Encoding for STREAM and DATA

   Media streams and large data payloads use raw binary encoding:

   *  *STREAM messages*: Raw media samples (H.264, Opus, etc.) without
      additional encoding overhead

   *  *DATA messages*: Raw binary chunks for file transfers and large
      payloads

   *  *Maximum efficiency* for bandwidth-constrained scenarios

4.4.  Message Type Details

   Each message type has specific field requirements and processing
   rules:

4.4.1.  CMD Message Format

   CMD messages carry structured commands encoded in JSON.  In addition
   to session management commands, CMD messages include specific actions
   for subscription management in pub/sub scenarios.

Liu & Krishnan          Expires 3 September 2026                [Page 8]
Internet-Draft           Agent Protocol over MoQ              March 2026

   +==========+=======+=============+===========+===========================+
   |Field     |Type   |Required     |Description|Example                    |
   +==========+=======+=============+===========+===========================+
   |action    |String |Yes          |Command    |"session_init",            |
   |          |       |             |identifier |"session_ack",             |
   |          |       |             |           |"subscribe_request",       |
   |          |       |             |           |"unsubscribe_request",     |
   |          |       |             |           |"track_ready"              |
   +----------+-------+-------------+-----------+---------------------------+
   |session_id|String/|Yes (for     |Session    |"abc-123-def-456"          |
   |          |UUID   |session cmds)|identifier |                           |
   +----------+-------+-------------+-----------+---------------------------+
   |auth_token|String |Yes (for     |JWT with   |"eyJhbGciOiJIUzI1NiIsIn..."|
   |          |       |session_init)|operation  |                           |
   |          |       |             |claim      |                           |
   +----------+-------+-------------+-----------+---------------------------+
   |status    |String |No           |Response   |"approved", "denied",      |
   |          |       |             |status     |"error"                    |
   +----------+-------+-------------+-----------+---------------------------+
   |error_code|Integer|No           |Error      |401, 403, 500              |
   |          |       |             |identifier |                           |
   +----------+-------+-------------+-----------+---------------------------+
   |payload   |Any    |No           |Command-   |{"key": "value"}           |
   |          |       |             |specific   |                           |
   |          |       |             |data       |                           |
   +----------+-------+-------------+-----------+---------------------------+

                                  Table 2

4.4.2.  Subscription Management Fields

   For subscription-related actions such as "subscribe_request" and
   "unsubscribe_request", CMD messages include additional fields:

Liu & Krishnan          Expires 3 September 2026                [Page 9]
Internet-Draft           Agent Protocol over MoQ              March 2026

   +==============+======+==========+============+=========================+
   |Field         |Type  |Required  |Description |Example                  |
   +==============+======+==========+============+=========================+
   |track_name    |String|Yes (for  |Name of the |"agent2.session456.video"|
   |              |      |subscribe)|track to    |                         |
   |              |      |          |subscribe to|                         |
   +--------------+------+----------+------------+-------------------------+
   |quality_params|Object|No        |Quality     |{"resolution": "1080p",  |
   |              |      |          |parameters  |"fps": 30}               |
   |              |      |          |for the     |                         |
   |              |      |          |subscription|                         |
   +--------------+------+----------+------------+-------------------------+
   |subscriber_id |String|Yes (for  |ID of the   |"agent1"                 |
   |              |      |subscribe)|subscribing |                         |
   |              |      |          |agent       |                         |
   +--------------+------+----------+------------+-------------------------+

                                  Table 3

4.4.3.  DATA Message Format

   DATA messages carry raw binary chunks for large file transfers.

   +==============+=========+===========+==============+===============+
   | Field        | Type    | Required  | Description  | Constraints   |
   +==============+=========+===========+==============+===============+
   | chunk_index  | Integer | Yes       | Position in  | 0-based,      |
   |              |         |           | sequence     | sequential    |
   +--------------+---------+-----------+--------------+---------------+
   | total_chunks | Integer | Yes (last | Total number | Must match    |
   |              |         | chunk)    | of chunks    | in all        |
   |              |         |           |              | chunks        |
   +--------------+---------+-----------+--------------+---------------+
   | checksum     | String  | No        | Data         | SHA-256 hex   |
   |              |         |           | integrity    | encoded       |
   |              |         |           | hash         |               |
   +--------------+---------+-----------+--------------+---------------+
   | metadata     | Object  | No        | File/type    | {"filename":  |
   |              |         |           | information  | "file.txt"}   |
   +--------------+---------+-----------+--------------+---------------+

                                  Table 4

4.4.4.  STREAM Message Format

   STREAM messages carry media samples with optional timing information.

Liu & Krishnan          Expires 3 September 2026               [Page 10]
Internet-Draft           Agent Protocol over MoQ              March 2026

   +=================+=======+==========+=============+===============+
   | Field           |Type   | Required | Description | Example       |
   +=================+=======+==========+=============+===============+
   | timestamp       |Integer| Yes      | Sample      | 1678901234567 |
   |                 |       |          | timestamp   |               |
   |                 |       |          | (ms)        |               |
   +-----------------+-------+----------+-------------+---------------+
   | media_type      |String | Yes      | Media       | "video/h264", |
   |                 |       |          | content     | "audio/opus"  |
   |                 |       |          | type        |               |
   +-----------------+-------+----------+-------------+---------------+
   | sequence_number |Integer| Yes      | Frame       | 12345         |
   |                 |       |          | sequence    |               |
   +-----------------+-------+----------+-------------+---------------+
   | key_frame       |Boolean| No       | Is key      | true          |
   |                 |       |          | frame       |               |
   +-----------------+-------+----------+-------------+---------------+
   | bitrate         |Integer| No       | Current     | 1000000       |
   |                 |       |          | bitrate     |               |
   |                 |       |          | (bps)       |               |
   +-----------------+-------+----------+-------------+---------------+

                                 Table 5

4.4.5.  HEARTBEAT Message Format

   HEARTBEAT messages have empty payload and are used for liveness
   detection.

   +================+==========+======================================+
   | Field          | Value    | Description                          |
   +================+==========+======================================+
   | Payload Length | 0        | No payload data                      |
   +----------------+----------+--------------------------------------+
   | Processing     | Ack only | Recipient should acknowledge receipt |
   +----------------+----------+--------------------------------------+

                                 Table 6

4.5.  MoQ Mapping and Transport Considerations

   Agent Protocol over MoQ frames are mapped to MoQ Objects and
   Datagrams based on their reliability and latency requirements:

   *  *CMD frames*: Mapped to MoQ Objects to ensure reliable delivery of
      control messages.  These require acknowledgment and retransmission
      if lost.

Liu & Krishnan          Expires 3 September 2026               [Page 11]
Internet-Draft           Agent Protocol over MoQ              March 2026

   *  *STREAM frames*: Mapped to MoQ Objects by default for ordered
      delivery.  May use MoQ Datagrams for loss-tolerant real-time
      streams where occasional packet loss is acceptable.

   *  *DATA frames*: Large data chunks are mapped to MoQ Objects for
      reliable transfer.  Small data may use MoQ Datagrams for lower
      latency.

   *  *HEARTBEAT frames*: Mapped to MoQ Datagrams for efficient keep-
      alive functionality without requiring acknowledgments.

   This mapping ensures that the transport characteristics of MoQ align
   with the application requirements of agent-to-agent communication.

4.6.  Pub/Sub Mechanism Integration

   The MoQ pub/sub mechanism is integrated with Agent Protocol over MoQ
   through specific CMD message types that manage subscriptions at the
   application layer:

   *  *Subscription Requests*: Agents send CMD messages with action
      "subscribe_request" to initiate track subscriptions.

   *  *Subscription Management*: The "subscribe_request" includes track
      name, quality parameters, and authorization tokens.

   *  *Track Naming Convention*: Track names follow the format
      "{agent_id}.{session_id}.{stream_type}", e.g., "agent1.abc-
      123-video".

   *  *Authorization*: Subscription requests are validated against the
      agent's authorization token before establishing the underlying MoQ
      subscription.

   This approach provides application-layer control over the underlying
   MoQ pub/sub mechanism, allowing fine-grained access control and
   session management.

5.  Session and Communication Model

   Agent Protocol over MoQ supports two communication modes:

5.1.  In-Session Communication (Recommended)

   Agents establish a session using a handshake that includes
   authorization verification.  Once a session is established, agents
   can use subscription management commands to establish pub/sub
   relationships:

Liu & Krishnan          Expires 3 September 2026               [Page 12]
Internet-Draft           Agent Protocol over MoQ              March 2026

   *  Agent A obtains an authorization JWT containing an operation claim
      as defined in [I-D.liu-agent-operation-authorization].

   *  Agent A sends a CMD frame with {action: "session_init",
      session_id: 0x123..., auth_token: "<JWT>"}.

   *  Agent B validates the JWT and verifies the operation permissions
      before responding.

   *  Agent B responds with CMD {action: "session_ack", session_id:
      0x123..., status: "approved|denied"}.

   *  Subsequent messages use the same Session ID in the frame header.

   The session terminates with a *session_bye* command or MoQ session
   closure.

5.2.  Session-Less Communication

   For stateless interactions (e.g., heartbeat, fire-and-forget
   command), agents may send frames without session setup.  The *Session
   ID* field is set to zero.  Authorization for such interactions is
   typically pre-established or implicit.

6.  Fragmentation and Large Data Handling

   Agent Protocol over MoQ defines three strategies based on payload
   size:

6.1.  Small Signals (< 1400 bytes)

   Sent as a single MoQ Datagram or Object.  No application-layer
   fragmentation.  Ideal for commands and heartbeats.

6.2.  Large Data (> 1400 bytes)

   Application-layer fragmentation is required:

   *  Data is split into chunks (e.g., 1400 bytes).

   *  Each chunk is encapsulated in an agent protocol over MoQ frame
      with the same Stream ID.

   *  The last chunk sets the fragmented flag to 0 and includes final
      metadata.

   Reassembly is performed at the receiver using Stream ID and order of
   arrival.

Liu & Krishnan          Expires 3 September 2026               [Page 13]
Internet-Draft           Agent Protocol over MoQ              March 2026

6.3.  Streaming Media

   Continuous media (audio/video) is sent as a sequence of agent
   protocol over MoQ *STREAM* frames.  Each frame carries one media
   sample.  Loss of a single frame does not block subsequent ones,
   leveraging MoQ's partial reliability.

7.  Transport and Domain Considerations

   Agent Protocol over MoQ is designed to operate in two modes:

   *  Intra-MoQ-Domain: Agents communicate within the same MoQ
      infrastructure (e.g., same edge cluster).  Low latency, high
      trust.  MoQ-native discovery is RECOMMENDED.

   *  Inter-Domain (Internet-wide): Agents communicate across networks.
      STUN/TURN/ICE MAY be used if direct QUIC path fails.

   Agent Protocol over MoQ does not define its own discovery mechanism
   but RECOMMENDS integration with MoQ's track discovery or external
   service directories.

8.  Security Considerations

   Agent Protocol over MoQ inherits security from the underlying
   transport:

   *  QUIC provides TLS 1.3 encryption and 0-RTT resumption.

   *  Application-layer authorization uses JWT with operation claim as
      defined in [I-D.liu-agent-operation-authorization].

   *  Session establishment requires validation of authorization tokens
      before communication begins.

   Implementations MUST validate authorization tokens before processing
   any agent-to-agent communication.  Session IDs MUST be
   cryptographically random to prevent session hijacking.

9.  IANA Considerations

   This document requests IANA to create new registries and register
   initial values for the Agent Protocol over MoQ.

Liu & Krishnan          Expires 3 September 2026               [Page 14]
Internet-Draft           Agent Protocol over MoQ              March 2026

9.1.  Agent Protocol over MoQ Magic Number Registry

   IANA is requested to create a new registry for Agent Protocol over
   MoQ Magic Numbers under the "Media over QUIC (MoQ)" group.  The
   registration procedure is Standards Action as defined in [RFC8126].

   Initial registration:

     +========+====================================+=================+
     | Value  | Description                        | Reference       |
     +========+====================================+=================+
     | 0xA2A2 | Agent-to-Agent Communication Frame | [This document] |
     +--------+------------------------------------+-----------------+

                                  Table 7

9.2.  Agent Protocol over MoQ Version Registry

   IANA is requested to create a new registry for Agent Protocol over
   MoQ Versions.  The registration procedure is Standards Action.

   Initial registration:

      +=======+===================================+=================+
      | Value | Description                       | Reference       |
      +=======+===================================+=================+
      | 0x01  | Agent Protocol over MoQ Version 1 | [This document] |
      +-------+-----------------------------------+-----------------+

                                  Table 8

   Values 0x00 and 0xFF are reserved.  Values 0x02-0xFE are available
   for assignment.

9.3.  Agent Protocol over MoQ Message Type Registry

   IANA is requested to create a new registry for Agent Protocol over
   MoQ Message Types.  The registration procedure is Specification
   Required as defined in [RFC8126].

   Initial registrations:

Liu & Krishnan          Expires 3 September 2026               [Page 15]
Internet-Draft           Agent Protocol over MoQ              March 2026

   +=======+==============+=========================+=================+
   | Value | Message Type | Description             | Reference       |
   +=======+==============+=========================+=================+
   | 0x00  | Reserved     | Reserved for future use | [This document] |
   +-------+--------------+-------------------------+-----------------+
   | 0x01  | CMD          | Command message with    | [This document] |
   |       |              | structured payload      |                 |
   +-------+--------------+-------------------------+-----------------+
   | 0x02  | DATA         | Raw binary data chunk   | [This document] |
   +-------+--------------+-------------------------+-----------------+
   | 0x03  | STREAM       | Media stream sample     | [This document] |
   +-------+--------------+-------------------------+-----------------+
   | 0x04  | HEARTBEAT    | Liveness detection      | [This document] |
   |       |              | message                 |                 |
   +-------+--------------+-------------------------+-----------------+

                                 Table 9

   Values 0x05-0xFE are available for assignment.  Value 0xFF is
   reserved.

9.4.  Agent Protocol over MoQ Frame Flags Registry

   IANA is requested to create a new registry for Agent Protocol over
   MoQ Frame Flags.  The registration procedure is Specification
   Required.  Each flag is represented by a bit position (0-7).

   Initial registrations:

   +=====+============+==============================+=================+
   | Bit | Flag Name  | Description                  | Reference       |
   +=====+============+==============================+=================+
   | 0   | Compressed | Payload is compressed (0x01) | [This           |
   |     |            |                              | document]       |
   +-----+------------+------------------------------+-----------------+
   | 1   | Encrypted  | Payload has application-     | [This           |
   |     |            | layer encryption (0x02)      | document]       |
   +-----+------------+------------------------------+-----------------+
   | 2   | Fragmented | Frame is part of a           | [This           |
   |     |            | fragmented stream (0x04)     | document]       |
   +-----+------------+------------------------------+-----------------+
   | 3-7 | Unassigned | Available for assignment     | [This           |
   |     |            |                              | document]       |
   +-----+------------+------------------------------+-----------------+

                                  Table 10

Liu & Krishnan          Expires 3 September 2026               [Page 16]
Internet-Draft           Agent Protocol over MoQ              March 2026

9.5.  Well-Known URI Registration

   IANA is requested to register a new well-known URI in the "Well-Known
   URIs" registry as defined in [RFC8615].

   The "/.well-known/a2a" endpoint facilitates agent discovery in inter-
   domain deployments.  When accessed via HTTPS GET, the endpoint
   returns a JSON response containing the MoQ endpoint information for
   Agent Protocol over MoQ communication.

   URI suffix:  a2a

   Change controller:  IETF

   Specification document:  This document

   Related information:  Used for WebTransport-based Agent Protocol over
      MoQ endpoint discovery.  The endpoint returns a JSON object with
      the MoQ endpoint information, e.g., { "moq_endpoint":
      "quic://api.example.com:443" }

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

   [RFC9000]  Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", RFC 9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

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

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

11.  Informative References

   [MOQ]      Nisancioglu, M. D., Enghardt, T., and C. Perkins, "Media
              over QUIC (MoQ) - Internet Draft", I-D ietf-moq-00, 2024.

   [WEBTRANS] Jansson, P. and J. Uberti, "WebTransport over HTTP/3",
              RFC 9220, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9220>.

Liu & Krishnan          Expires 3 September 2026               [Page 17]
Internet-Draft           Agent Protocol over MoQ              March 2026

   [I-D.liu-agent-operation-authorization]
              Liu, D., Zhu, H., and S. Krishnan, "Agent Operation
              Authorization Policy", I-D liu-agent-operation-
              authorization, January 2026.

Appendix A.  Appendix A: Usage Examples

   This appendix provides detailed examples of Agent Protocol over MoQ
   interactions based on a multimodal collaborative design scenario.

A.1.  A.1 Scenario Overview

   *Agents:*

   *  *Agent 1 (Personal Assistant):* Resides on a user's smartphone.

   *  *Agent 2 (Professional Designer):* Resides on a cloud server.

A.2.  A.2 Stateless Communication (Session-Less)

   Used for lightweight, fire-and-forget interactions like liveness
   checks or simple status updates.

A.2.1.  A.2.1 Heartbeat Interaction

   Agent 1 sends a heartbeat to Agent 2 to maintain the MoQ track
   activity.

   Header:
   - Magic Number: 0xA2A2
   - Version: 0x01
   - Msg Type: 0x04 (HEARTBEAT)
   - Session ID: 0 (Stateless)
   - Stream ID: 0
   - Flags: 0x00
   - Payload Len: 0
   Payload: (Empty)

                  Figure 3: Heartbeat Frame Implementation

A.3.  A.3 Stateful Communication with Streaming Media

   Used for complex dialogues requiring continuous media processing,
   such as real-time video analysis.

Liu & Krishnan          Expires 3 September 2026               [Page 18]
Internet-Draft           Agent Protocol over MoQ              March 2026

A.3.1.  A.3.1 Real-time Video Stream for Design Feedback

   *Step 1: Session Handshake with Authorization*

   Agent 1 (Smartphone)                    Agent 2 (Cloud)
           |                                      |
           |  CMD {action:"session_init",         |
           |       session_id:"abc-123",          |
           |       auth_token:"<JWT>"}            |
           |------------------------------------->|
           |                                      |
           |  CMD {action:"session_ack",          |
           |       session_id:"abc-123",          |
           |       status:"approved"}             |
           |<-------------------------------------|

                  Figure 4: Session Establishment Sequence

   *Step 2: Media Streaming*

   Agent 1 captures video and sends it as STREAM frames within the
   established session.

   Header:
   - Magic Number: 0xA2A2
   - Version: 0x01
   - Msg Type: 0x03 (STREAM)
   - Session ID: abc-123
   - Flags: 0x00
   - Payload Len: 1200
   Payload: [Raw H.264/HEVC NAL Unit]

                Figure 5: Video Sample Frame Implementation

A.3.2.  A.3.2 Subscription Management Example

   *Step 1: Subscription Request*

   Agent 1 wants to subscribe to Agent 2's video feed.  It sends a
   subscription request within the established session.

Liu & Krishnan          Expires 3 September 2026               [Page 19]
Internet-Draft           Agent Protocol over MoQ              March 2026

   Agent 1 (Subscriber)                    Agent 2 (Publisher)
           |                                                 |
           |  CMD {action:"subscribe_request",               |
           |       session_id:"abc-123",                     |
           |       track_name:"agent2.video.h264",           |
           |       subscriber_id:"agent1"}                   |
           |------------------------------------------------>|
           |                                                 |
           |  CMD {action:"track_ready",                     |
           |       session_id:"abc-123",                     |
           |       status:"approved",                        |
           |       track_url:"moq://track/agent2.video.h264"}|
           |<------------------------------------------------|

                  Figure 6: Subscription Request Sequence

   *Step 2: Media Streaming via MoQ pub/sub*

   After successful subscription negotiation via CMD messages, the
   actual media stream flows through the underlying MoQ pub/sub
   mechanism.

A.4.  A.4 Stateful Communication with Large Data Blocks

   Used for transferring high-resolution assets or large model weights.

A.4.1.  A.4.1 Sending High-Res Design Assets

   Agent 2 sends a 5MB design file back to Agent 1.

   *Fragmentation Strategy:* The file is split into chunks of 1400
   bytes.

   Header:
   - Msg Type: 0x02 (DATA)
   - Session ID: abc-123
   - Stream ID: 101 (File Transfer Stream)
   - Flags: 0x04 (Fragmented = 1)
   - Payload Len: 1400
   Payload: [First 1400 bytes of the file]

                        Figure 7: First Chunk Frame

Liu & Krishnan          Expires 3 September 2026               [Page 20]
Internet-Draft           Agent Protocol over MoQ              March 2026

   Header:
   - Msg Type: 0x02 (DATA)
   - Session ID: abc-123
   - Stream ID: 101
   - Flags: 0x00 (Fragmented = 0)
   - Payload Len: 800
   Payload: [Final 800 bytes of the file]

                         Figure 8: Last Chunk Frame

A.5.  A.5 Deployment Scenarios

A.5.1.  A.5.1 Intra-Domain (Same Edge Cluster)

   Agents are deployed in the same regional data center (e.g., Alibaba
   Cloud Hangzhou Region).

   *  *Discovery:* Uses MoQ-native track discovery.

   *  *Latency:* Extremely low (< 5ms).

   *  *Trust:* High; encryption is present but overhead is minimal due
      to short physical distance.

A.5.2.  A.5.2 Inter-Domain (Cross-Cloud Invocation)

   Agent 1 (on Smartphone) calls Agent 2 (on Cloud).

   Agent 1 (Smartphone)  .well-known/a2a    Agent 2 (Cloud)
           |                    |                          |
           | GET https://cloud.example.com/.well-known/a2a |
           |---------------------------------------------->|
           |                    |                          |
           | { "moq_endpoint": "quic://api.cloud.example.com:443" } |
           |<----------------------------------------------|
           |                    |                          |
           | QUIC/MoQ Handshake (0-RTT)                    |
           |---------------------------------------------->|
           |                    |                          |
           | Agent Protocol over MoQ Frame                 |
           | (Session Init with Auth)                      |
           |---------------------------------------------->|

                   Figure 9: Inter-Domain Connection Flow

   *  *Discovery:* Uses HTTPS Well-Known URI as a bootstrap.

   *  *Traversal:* Relies on QUIC's robustness against NAT changes.

Liu & Krishnan          Expires 3 September 2026               [Page 21]
Internet-Draft           Agent Protocol over MoQ              March 2026

   *  *Security:* Inherits TLS 1.3 from QUIC; ensures end-to-end privacy
      across public networks.

A.6.  A.6 Summary Table of Interaction Types

    +================+=======+=========+============+=================+
    | Type           |Session|Msg Type |Typical     | MoQ Mapping     |
    |                |ID     |         |Usage       |                 |
    +================+=======+=========+============+=================+
    | *Session-Less* |0      |HEARTBEAT|Keep-alive, | MoQ Datagram    |
    |                |       |/ CMD    |Simple      | (HEARTBEAT),    |
    |                |       |         |Queries     | MoQ Object      |
    |                |       |         |            | (CMD)           |
    +----------------+-------+---------+------------+-----------------+
    | *Streaming*    |UUID   |STREAM   |Audio/Video/| MoQ Object      |
    |                |       |         |Sensor      | (Ordered        |
    |                |       |         |Stream      | Delivery), MoQ  |
    |                |       |         |            | Datagram (Loss- |
    |                |       |         |            | Tolerant)       |
    +----------------+-------+---------+------------+-----------------+
    | *Bulk Data*    |UUID   |DATA     |Large Files,| MoQ Object      |
    |                |       |         |Images      | (Reliable), MoQ |
    |                |       |         |            | Datagram (Small |
    |                |       |         |            | Data)           |
    +----------------+-------+---------+------------+-----------------+
    | *Control*      |UUID   |CMD      |Logic       | MoQ Object      |
    |                |       |         |Execution,  | (Reliable)      |
    |                |       |         |ACKs,       |                 |
    |                |       |         |Subscription|                 |
    |                |       |         |Management  |                 |
    +----------------+-------+---------+------------+-----------------+

                                  Table 11

Authors' Addresses

   Dapeng Liu
   Alibaba Cloud
   Email: max.ldp@alibaba-inc.com

   Suresh Krishnan
   Cisco
   Email: suresh.krishnan@gmail.com

Liu & Krishnan          Expires 3 September 2026               [Page 22]