PACE: Protocol for Agent Communication Exchange
draft-nandakumar-agentproto-moq-pace-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Suhas Nandakumar , Cullen Fluffy Jennings | ||
| Last updated | 2026-07-06 | ||
| 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-nandakumar-agentproto-moq-pace-00
Agent Communication Protocols S. Nandakumar
Internet-Draft Cisco
Intended status: Standards Track C. Jennings
Expires: 30 December 2026 Cisco Systems
28 June 2026
PACE: Protocol for Agent Communication Exchange
draft-nandakumar-agentproto-moq-pace-00
Abstract
This document defines the Protocol for Agent Communication Exchange
(PACE), a session protocol for AI agent communication over Media over
QUIC Transport (MOQT). PACE provides session lifecycle management,
multi-modal data exchange, agent identity verification, and delegated
authorization within MOQT's publish/subscribe model, supporting
point-to-point and point-to-multipoint topologies through relay
infrastructure.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://suhasHere.github.io/draft-a2a-moqt-transport/draft-
nandakumar-ai-agent-moq-transport.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
nandakumar-agentproto-moq-pace/.
Discussion of this document takes place on the Agent Communication
Protocols Working Group mailing list (mailto:agent2agent@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/
agent2agent/. Subscribe at https://www.ietf.org/mailman/listinfo/
agent2agent/.
Source for this draft and an issue tracker can be found at
https://github.com/suhasHere/draft-a2a-moqt-transport.
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/.
Nandakumar & Jennings Expires 30 December 2026 [Page 1]
Internet-Draft PACE over MOQT June 2026
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 30 December 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
2.1. Why MOQT? . . . . . . . . . . . . . . . . . . . . . . . . 5
3. MOQT Mapping . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Namespace Organization . . . . . . . . . . . . . . . . . 6
3.1.1. Agent Namespace . . . . . . . . . . . . . . . . . . . 6
3.1.2. Session Communication Namespace . . . . . . . . . . . 7
3.1.3. Session Discovery Namespace . . . . . . . . . . . . . 8
3.2. Transport Binding . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Connection Establishment . . . . . . . . . . . . . . 8
3.2.2. Track Organization . . . . . . . . . . . . . . . . . 9
3.2.3. Message Serialization . . . . . . . . . . . . . . . . 9
4. Session Management . . . . . . . . . . . . . . . . . . . . . 9
4.1. Session Lifecycle . . . . . . . . . . . . . . . . . . . . 9
4.2. Session Establishment . . . . . . . . . . . . . . . . . . 10
4.2.1. Session Parameters . . . . . . . . . . . . . . . . . 11
4.2.2. MOQT Setup Extensions . . . . . . . . . . . . . . . . 12
4.3. Timed Sessions . . . . . . . . . . . . . . . . . . . . . 12
4.4. Session Update . . . . . . . . . . . . . . . . . . . . . 12
4.5. Session Recovery . . . . . . . . . . . . . . . . . . . . 12
4.6. Session Termination . . . . . . . . . . . . . . . . . . . 13
5. Agent Identity and Discovery . . . . . . . . . . . . . . . . 13
5.1. Agent Identity Model . . . . . . . . . . . . . . . . . . 13
Nandakumar & Jennings Expires 30 December 2026 [Page 2]
Internet-Draft PACE over MOQT June 2026
5.1.1. Agent Identity Token . . . . . . . . . . . . . . . . 13
5.1.2. Delegation Chains . . . . . . . . . . . . . . . . . . 14
5.2. Agent Discovery . . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Phase 1: Discovering Agents on the Network . . . . . 14
5.2.2. Phase 2: Following an Agent . . . . . . . . . . . . . 15
5.2.3. Agent Card . . . . . . . . . . . . . . . . . . . . . 15
6. Multi-Modal Data Exchange . . . . . . . . . . . . . . . . . . 16
6.1. Modality Types . . . . . . . . . . . . . . . . . . . . . 16
6.2. Channel Architecture . . . . . . . . . . . . . . . . . . 16
6.3. Priority and Quality of Service . . . . . . . . . . . . . 16
6.4. Request/Response Pattern . . . . . . . . . . . . . . . . 17
6.5. Streaming Pattern . . . . . . . . . . . . . . . . . . . . 18
6.6. Real-Time Media Exchange . . . . . . . . . . . . . . . . 18
7. Communication Topologies . . . . . . . . . . . . . . . . . . 18
8. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Binding Architecture . . . . . . . . . . . . . . . . . . 19
8.2. A2A Binding . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.1. Namespace Structure . . . . . . . . . . . . . . . . . 20
8.2.2. A2A Operation Mapping . . . . . . . . . . . . . . . . 20
8.2.3. Message Format . . . . . . . . . . . . . . . . . . . 21
8.2.4. Priority Mapping . . . . . . . . . . . . . . . . . . 22
8.2.5. Streaming Support . . . . . . . . . . . . . . . . . . 23
8.2.6. A2A Agent Card with MOQT Extension . . . . . . . . . 23
8.3. MCP Binding . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. AutoGen Binding . . . . . . . . . . . . . . . . . . . . . 24
8.4.1. Namespace Structure . . . . . . . . . . . . . . . . . 24
8.4.2. Message Format . . . . . . . . . . . . . . . . . . . 25
8.4.3. Conversation Patterns . . . . . . . . . . . . . . . . 25
8.4.4. Priority Mapping . . . . . . . . . . . . . . . . . . 26
8.5. Generic JSON-RPC Binding . . . . . . . . . . . . . . . . 26
8.5.1. Namespace Structure . . . . . . . . . . . . . . . . . 26
8.5.2. Message Format . . . . . . . . . . . . . . . . . . . 26
8.5.3. Extension Mechanism . . . . . . . . . . . . . . . . . 27
9. Authorization and Security . . . . . . . . . . . . . . . . . 27
9.1. Authorization Model . . . . . . . . . . . . . . . . . . . 27
9.1.1. Behavior-Driven Scopes . . . . . . . . . . . . . . . 27
9.1.2. Delegated Authorization . . . . . . . . . . . . . . . 27
9.1.3. Confirmation and Evidence . . . . . . . . . . . . . . 27
9.2. Transport Security . . . . . . . . . . . . . . . . . . . 28
9.3. Privacy Considerations . . . . . . . . . . . . . . . . . 28
10. Scalability and Reliability . . . . . . . . . . . . . . . . . 28
10.1. Failure Modes and Recovery . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12.1. MOQT Setup Parameter Registry . . . . . . . . . . . . . 29
12.2. PACE Protocol Binding Registry . . . . . . . . . . . . . 29
12.3. PACE Message Type Registry . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Nandakumar & Jennings Expires 30 December 2026 [Page 3]
Internet-Draft PACE over MOQT June 2026
13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Example Workflows . . . . . . . . . . . . . . . . . 32
A.1. Agent-to-Agent: Task Delegation . . . . . . . . . . . . . 32
A.2. Agent-to-Tool: MCP Tool Invocation . . . . . . . . . . . 33
A.3. Multi-Agent Collaboration . . . . . . . . . . . . . . . . 34
A.4. Agent-to-Tool with Streaming: Long-Running Operation . . 36
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction
AI agents are autonomous software systems that interact with other
agents and tools to complete tasks. As agent communication expands
across the Internet, it requires: verifiable agent identity
independent of users, capability discovery and collaboration across
network boundaries, multi-modal data exchange (text, audio, video)
with session management, and delegated authorization across agent
chains.
This document defines the Protocol for Agent Communication Exchange
(PACE), a session layer over Media over QUIC Transport (MOQT)
[MoQ-TRANSPORT]. PACE enables diverse agent protocols to leverage
MOQT's publish/subscribe model, relay-based fan-out, built-in
prioritization, and efficient multiplexing over QUIC.
1.1. Design Goals
1. *Session Lifecycle*: Timed sessions with establishment, update,
suspension, and termination.
2. *Multi-Modal*: Concurrent real-time media, chat, and operations.
3. *Scalable*: Relay-based fan-out with failure recovery.
4. *Flexible Topologies*: Point-to-point and point-to-multipoint.
5. *Agent Identity*: Authentication independent of user identity
with delegated authorization.
6. *Protocol Agnostic*: Usable by A2A, MCP, and custom protocols.
Nandakumar & Jennings Expires 30 December 2026 [Page 4]
Internet-Draft PACE over MOQT June 2026
1.2. 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. Architecture Overview
The PACE architecture layers as follows:
┌─────────────────────────────────────────────────────────┐
│ Application Protocols (A2A, MCP, AutoGen, Custom) │
├─────────────────────────────────────────────────────────┤
│ PACE: Sessions │ Identity │ Auth │ Multi-Modal │ QoS │
├─────────────────────────────────────────────────────────┤
│ MOQT: Pub/Sub │ Namespace Routing │ Relay Caching │
├─────────────────────────────────────────────────────────┤
│ QUIC / WebTransport: TLS 1.3 │ Mux │ Migration │
└─────────────────────────────────────────────────────────┘
Figure 1: PACE Architecture
2.1. Why MOQT?
Media over QUIC Transport (MOQT) [MoQ-TRANSPORT] is a publish/
subscribe protocol over QUIC. PACE adopts MOQT as its transport
substrate for the following reasons:
* *Native pub/sub* — Agents publish and subscribe without polling or
long-lived HTTP connections; the relay handles fan-out
* *Prefix-based routing* — SUBSCRIBE_TRACKS on an agent's prefix
automatically delivers all current and future tracks, enabling
session notification without dedicated signaling channels
* *Relay architecture* — No direct peer-to-peer connections
required; relays provide NAT traversal and load balancing out of
the box
* *Multi-party fan-out* — A single PUBLISH reaches all subscribers
via relay; no application-level broadcast logic needed for multi-
agent collaboration
* *Relay caching* — Late-joining agents receive cached objects,
enabling session recovery and mid-conversation catch-up without
peer retransmission
Nandakumar & Jennings Expires 30 December 2026 [Page 5]
Internet-Draft PACE over MOQT June 2026
* *Per-object priority* — Real-time audio/video, control messages,
and bulk transfers coexist on the same session with differentiated
QoS (0-255 priority scale)
* *Multiple latency spectrums* — A single MOQT session supports sub-
100ms real-time media, sub-second interactive messaging, and best-
effort bulk transfers simultaneously, matching the diverse
communication needs of AI agents
* *Scalability* — Relays MAY be organized hierarchically for
geographic distribution, enabling thousands of agents across
regions without requiring each agent to maintain direct
connections to all peers
* *QUIC foundation* — Connection migration (WiFi to cellular),
multiplexed streams, 0-RTT resumption, and mandatory TLS 1.3
* *Namespace-level access control* — Maps directly to agent
authorization scopes; relays enforce who can publish/subscribe to
which namespaces
3. MOQT Mapping
3.1. Namespace Organization
PACE uses MOQT's hierarchical namespace for routing, isolation, and
multiplexing. MOQT addresses content using a namespace tuple (an
ordered sequence of string fields) combined with a track name. PACE
organizes all communication into three namespace scopes defined in
the following subsections.
3.1.1. Agent Namespace
("pace", "agents", {agent-id}) -- {track}
This is an agent's persistent identity on the relay network. Each
agent publishes the following tracks:
* "card" — Agent Card containing capabilities, identity claims,
authentication schemes, and MOQT connectivity information
The common prefix ("pace", "agents") enables SUBSCRIBE_NAMESPACE-
based discovery of all agents on the network. Interested agents then
issue SUBSCRIBE_TRACKS on a discovered agent's prefix to receive all
current and future tracks published by that agent. See Section 5.2
for the complete discovery flow.
Nandakumar & Jennings Expires 30 December 2026 [Page 6]
Internet-Draft PACE over MOQT June 2026
3.1.2. Session Communication Namespace
("pace", "agents", {agent-id}, {session-id}) -- {track}
A session-id is a shared UUID representing a collaboration context —
it is not scoped to or owned by any single agent. Any agent can
generate a session-id to initiate a collaboration. When multiple
agents participate in a session, they each publish tracks under their
own agent namespace using the same session-id. Agents that have
issued SUBSCRIBE_TRACKS on a peer's agent prefix are automatically
notified (via relay-forwarded PUBLISH messages) when that peer
creates new session tracks.
Each agent in a session publishes the following tracks:
* "ctrl" — Session lifecycle messages (SESSION_INIT, SESSION_ACCEPT,
SESSION_UPDATE, SESSION_CLOSE)
* "chat" — Chat messages and streaming LLM output
* "audio" — Real-time audio stream
* "video" — Real-time video stream
* "ops/{req-id}" — Request/response operations (one track per
request)
Protocol bindings add prefix-scoped tracks to enable multiple
protocols to operate concurrently within a single session without
track name collisions:
* "a2a/{category}/{id}" — A2A protocol operations, where {category}
is the operation type (e.g., request, response, task, stream) and
{id} is the request or task identifier
* "mcp/{category}/{id}" — MCP protocol operations, where {category}
is the primitive type (e.g., tools, resources, prompts) and {id}
is the tool name or resource URI
* "ext/{proto}/{category}/{id}" — Custom protocol extensions, where
{proto} identifies the protocol
For example, the MCP over MOQT specification [MCP-MOQT] defines
tracks like (mcp, {session-id}, tools) -- ({tool-name}); within PACE,
this maps to track name "mcp/tools/{tool-name}" under the agent's
session namespace, preserving the MCP semantics while coexisting with
A2A or other protocol tracks in the same session.
Nandakumar & Jennings Expires 30 December 2026 [Page 7]
Internet-Draft PACE over MOQT June 2026
See Appendix A for concrete examples of agent-to-agent, agent-to-
tool, and multi-agent collaboration workflows.
3.1.3. Session Discovery Namespace
("pace", "discovery", "sessions", {agent-id}) -- {session-id}
Agents advertise their active sessions on this top-level discovery
namespace so that other agents can find sessions to join. Each agent
publishes one track per active session (the track name is the
session-id). Each object on a session track contains:
* session-id — The shared session UUID
* description — Human-readable purpose of the session
* participants — List of agent-ids currently in the session
* modalities — Supported data modalities (text, audio, video, etc.)
Agents discover active sessions by issuing SUBSCRIBE_NAMESPACE on
("pace", "discovery", "sessions").
3.2. Transport Binding
3.2.1. Connection Establishment
Agents MUST establish either a native QUIC connection or a
WebTransport [RFC9297] session as defined in [MoQ-TRANSPORT]. For
native QUIC connections, agents MUST use the ALPN value "moqt". For
WebTransport, the protocol is negotiated using the "WT-Available-
Protocols" mechanism as specified in [MoQ-TRANSPORT].
Upon establishing the MOQT session (CLIENT_SETUP / SERVER_SETUP), an
agent performs the bootstrap sequence to make itself discoverable:
1. *Announce*: PUBLISH_NAMESPACE on ("pace", "agents", {agent-id})
2. *Publish Agent Card*: PUBLISH on track "card" under its namespace
3. *Discover peers*: SUBSCRIBE_NAMESPACE on ("pace", "agents") to
learn about other agents on the network
See Section 5.2 for the full discovery flow that follows bootstrap.
Nandakumar & Jennings Expires 30 December 2026 [Page 8]
Internet-Draft PACE over MOQT June 2026
3.2.2. Track Organization
Each agent publishes exclusively on its own tracks. Other agents
issue SUBSCRIBE_TRACKS on a peer's agent prefix to receive all tracks
published by that peer, including session tracks. The relay handles
fan-out to all subscribers via prefix matching. This per-agent
publishing model ensures clear ownership and enables relay caching.
Namespace structure and track names are defined in Section 3.1.
3.2.3. Message Serialization
Protocol messages are encapsulated within MOQT objects using a PACE
envelope prepended to the payload:
+=========+==========+========================================+
| Field | Size | Description |
+=========+==========+========================================+
| version | 1 byte | PACE envelope version (currently 0x01) |
+---------+----------+----------------------------------------+
| flags | 1 byte | 0x01=compressed, 0x02=fragmented, |
| | | 0x04=encrypted |
+---------+----------+----------------------------------------+
| length | varint | Length of the serialized protocol |
| | | message |
+---------+----------+----------------------------------------+
| payload | variable | Serialized protocol message |
+---------+----------+----------------------------------------+
Table 1
Bindings SHOULD preserve native message formats. For example, A2A
messages retain their JSON-RPC 2.0 format; the PACE envelope wraps
the serialized JSON bytes.
4. Session Management
A PACE session represents a logical communication context between two
or more agents. Sessions provide lifetime management, context
preservation, and failure recovery. All session operations use the
namespace structure defined in Section 3.1.
4.1. Session Lifecycle
Sessions progress through defined states:
Nandakumar & Jennings Expires 30 December 2026 [Page 9]
Internet-Draft PACE over MOQT June 2026
IDLE ──establish──▶ PENDING ──accept──▶ ACTIVE ◀──update──┐
◀──reject──────────┘ │ │ │
suspend terminate │
▼ │ │
SUSPENDED ▼ │
│ │ CLOSED ◀──┘
│ └resume──▶ ACTIVE
└─timeout──▶ CLOSED
Figure 2: Session State Machine
IDLE: No session exists. Agent is available to initiate or accept
sessions.
PENDING: Establishment in progress (negotiation, authentication).
ACTIVE: Session established; data exchange occurring. May be
updated.
SUSPENDED: Temporarily inactive, state preserved. Transitions to
CLOSED on timeout.
CLOSED: Session terminated. Resources released.
4.2. Session Establishment
Session establishment creates a shared communication context between
two or more agents. Its goals are to negotiate capabilities and
modalities, exchange and verify identity tokens, and set up the MOQT
subscriptions so both agents can publish and receive messages.
*Prerequisite:* Both agents must have completed discovery Phase 2
(Section 5.2) — meaning they have issued SUBSCRIBE_TRACKS on each
other's agent prefix. This enables the relay to forward PUBLISH
messages between them automatically via prefix matching.
The following steps describe how Agent A (initiator) establishes a
session with Agent B (responder):
1. *A generates a session-id* (UUID).
2. *A publishes SESSION_INIT* — A issues PUBLISH on
("pace","agents","agent-a",{session-id}) -- "ctrl" containing
proposed session parameters (target=agent-b, capabilities,
modalities, identity token, supported protocols).
Nandakumar & Jennings Expires 30 December 2026 [Page 10]
Internet-Draft PACE over MOQT June 2026
3. *Relay forwards PUBLISH to B* — B's existing SUBSCRIBE_TRACKS on
("pace","agents","agent-a") prefix-matches the new track. The
relay forwards the PUBLISH message to B.
4. *B accepts the PUBLISH* — this implicitly subscribes B to A's
ctrl track. B receives the SESSION_INIT object, inspects the
parameters, and decides whether to accept.
5. *B publishes SESSION_ACCEPT* — B issues PUBLISH on
("pace","agents","agent-b",{session-id}) -- "ctrl" containing
accepted capabilities and modalities.
6. *Relay forwards PUBLISH to A* — A's existing SUBSCRIBE_TRACKS on
("pace","agents","agent-b") prefix-matches. The relay forwards
the PUBLISH message to A.
7. *A accepts the PUBLISH* — A receives the SESSION_ACCEPT object.
8. *Session is ACTIVE* — both agents can now publish additional
tracks under their respective session namespaces. The relay
forwards all new PUBLISH messages to the peer via the existing
SUBSCRIBE_TRACKS prefix match.
4.2.1. Session Parameters
The SESSION_INIT object contains:
* session-id: Globally unique session identifier (UUID)
* session-type: Short-lived (bounded duration) or long-lived
(indefinite)
* session-timeout: Maximum idle duration before automatic
termination
* max-participants: Maximum number of agents in the session
* supported-modalities: Bitmask of data modalities the agent can
handle
* identity-token: Agent identity token (see Section 5)
* supported-protocols: Application protocols offered (A2A, MCP,
etc.)
Nandakumar & Jennings Expires 30 December 2026 [Page 11]
Internet-Draft PACE over MOQT June 2026
4.2.2. MOQT Setup Extensions
PACE defines the following MOQT setup parameters negotiated during
CLIENT_SETUP/SERVER_SETUP:
+======================+============+=========================+
| Parameter | ID | Description |
+======================+============+=========================+
| pace-version | 0x50414301 | PACE protocol version |
+----------------------+------------+-------------------------+
| agent-identity | 0x50414302 | Agent identity token or |
| | | certificate reference |
+----------------------+------------+-------------------------+
| supported-protocols | 0x50414303 | Bitmask of application |
| | | protocols (A2A=0x01, |
| | | MCP=0x02) |
+----------------------+------------+-------------------------+
| auth-schemes | 0x50414304 | Supported |
| | | authentication schemes |
+----------------------+------------+-------------------------+
| session-capabilities | 0x50414305 | Session capability |
| | | flags |
+----------------------+------------+-------------------------+
Table 2
4.3. Timed Sessions
Sessions are either short-lived (bounded duration, auto-terminates on
completion or timeout) or long-lived (indefinite, survives idle
periods via SUSPENDED state). The session-timeout parameter defines
the maximum idle period before automatic transition to CLOSED.
4.4. Session Update
Active sessions can be updated by publishing a SESSION_UPDATE message
on the control track. Updates can modify modalities, participants,
authorization scopes, or timeout. All participants MUST acknowledge
the update before new parameters take effect.
4.5. Session Recovery
PACE provides graceful recovery from network and server failures:
QUIC Connection Migration: Sessions survive network path changes
(e.g., WiFi to cellular) via QUIC's connection ID mechanism
without re-establishing the MOQT session.
Nandakumar & Jennings Expires 30 December 2026 [Page 12]
Internet-Draft PACE over MOQT June 2026
Relay Caching: Relays cache recent objects, allowing reconnecting
agents to receive missed messages without requiring peer
retransmission.
Session Resumption: Agents resume SUSPENDED sessions by reconnecting
to the relay, re-issuing PUBLISH_NAMESPACE and SUBSCRIBE_TRACKS on
their agent prefix. The relay delivers cached objects from the
point of disconnection.
State Checkpointing: Agents SHOULD periodically publish state
checkpoints on a dedicated track, enabling recovery after relay
failures.
4.6. Session Termination
Sessions terminate explicitly via SESSION_CLOSE on the control track
or implicitly via timeout. Upon termination, all subscriptions are
cancelled, pending operations receive cancellation notifications, and
session resources are released after a configurable grace period.
5. Agent Identity and Discovery
5.1. Agent Identity Model
PACE authenticates agents independently of the users they represent.
This enables independent revocation, capability-scoped permissions,
audit trails for agent actions, and delegation chains.
5.1.1. Agent Identity Token
Each agent presents an identity token during session establishment.
The token format is based on JWT [RFC7519] with agent-specific
claims:
Nandakumar & Jennings Expires 30 December 2026 [Page 13]
Internet-Draft PACE over MOQT June 2026
+==================+=========================================+
| Claim | Description |
+==================+=========================================+
| agent-id | Globally unique agent identifier (UUID) |
+------------------+-----------------------------------------+
| issuer | Identity provider that issued the token |
+------------------+-----------------------------------------+
| subject | User or organization the agent serves |
+------------------+-----------------------------------------+
| capabilities | Agent capability descriptors |
+------------------+-----------------------------------------+
| scopes | Authorized operation scopes |
+------------------+-----------------------------------------+
| issued-at | Token issuance timestamp |
+------------------+-----------------------------------------+
| expires-at | Token expiration timestamp |
+------------------+-----------------------------------------+
| delegation-chain | Parent agent references (see below) |
+------------------+-----------------------------------------+
Table 3
The token is cryptographically signed by the issuing authority.
Agents MAY use the SD-JWT based identity mechanism defined in
[SD-AGENT] to support selective disclosure of identity attributes
during session establishment.
5.1.2. Delegation Chains
When an agent acts on behalf of another agent, the identity token
includes a delegation-chain field tracing the authorization path
(e.g., User → Coordinator → Researcher → Tool). Each entry records
the granting agent and the scope granted. Receiving agents verify
the complete chain to ensure each link has appropriate authorization.
5.2. Agent Discovery
Agent discovery uses MOQT's namespace operations to find agents and
follow their activity. Discovery operates on the Agent Namespace
scope defined in Section 3.1. Each agent is identified by a globally
unique agent-id (UUID), verifiable via the Agent Card (see
Section 5.2.3).
5.2.1. Phase 1: Discovering Agents on the Network
1. Each agent announces its presence by issuing PUBLISH_NAMESPACE on
("pace","agents",{agent-id}).
Nandakumar & Jennings Expires 30 December 2026 [Page 14]
Internet-Draft PACE over MOQT June 2026
2. Agents discover peers by issuing SUBSCRIBE_NAMESPACE on the
common prefix ("pace","agents").
3. The relay sends NAMESPACE messages to subscribers for each
matching PUBLISH_NAMESPACE, enabling agents to learn about each
other without prior knowledge.
If an agent-id is known out-of-band (e.g., from a registry or URL),
agents MAY skip Phase 1 and proceed directly to Phase 2.
5.2.2. Phase 2: Following an Agent
Once Agent B knows Agent A's namespace prefix, B issues
SUBSCRIBE_TRACKS on ("pace","agents","agent-a"). This establishes an
ongoing relationship where the relay forwards all PUBLISH messages
from A that match this prefix — including A's Agent Card and any
future session tracks A creates.
1. B issues SUBSCRIBE_TRACKS on ("pace","agents","agent-a").
2. The relay forwards A's PUBLISH for the "card" track to B.
3. B accepts the PUBLISH — this implicitly subscribes B to the card
track and B receives A's Agent Card objects.
4. When A later publishes session tracks under
("pace","agents","agent-a",{session-id}), the relay automatically
forwards those PUBLISH messages to B (prefix match), enabling B
to discover and join sessions without any explicit notification
mechanism.
A does the same for B by issuing SUBSCRIBE_TRACKS on
("pace","agents","agent-b").
5.2.3. Agent Card
Each agent publishes an Agent Card on track "card" under its
namespace ("pace","agents",{agent-id}). When capabilities change,
the agent publishes a new object (incrementing the group). Receivers
SHOULD verify the card's signature and expiration before acting on
its claims.
All Agent Cards MUST include:
* Agent identifier (UUID) and display name
* Supported modalities and protocols
Nandakumar & Jennings Expires 30 December 2026 [Page 15]
Internet-Draft PACE over MOQT June 2026
* Authentication schemes
* Identity claims (issuer, public key, expiration)
The card format is protocol-specific. For A2A agents, see
Section 8.2.6. Agent Cards MAY use selective disclosure [SD-AGENT]
to reveal only claims necessary for a given interaction.
6. Multi-Modal Data Exchange
PACE supports concurrent exchange of multiple data modalities within
a single session, each with appropriate quality of service.
6.1. Modality Types
PACE defines the following data modality classes:
+================+=========+======================+============+
| Modality | Latency | Examples | Delivery |
+================+=========+======================+============+
| Real-time | < 100ms | Voice, video, screen | Continuous |
| | | share | stream |
+----------------+---------+----------------------+------------+
| Semi-real-time | < 1s | Chat messages, | Ordered |
| | | streaming LLM output | objects |
+----------------+---------+----------------------+------------+
| Non-real-time | Best | Tool calls, file | Reliable |
| | effort | transfers, context | delivery |
+----------------+---------+----------------------+------------+
Table 4
6.2. Channel Architecture
Each modality maps to dedicated MOQT tracks within the Session
Communication Namespace (Section 3.1). Different modalities are
isolated by track name while sharing session context and
authorization.
6.3. Priority and Quality of Service
MOQT's 0-255 priority scale enables differentiated treatment of
messages based on urgency and modality. PACE defines the following
priority tiers:
Nandakumar & Jennings Expires 30 December 2026 [Page 16]
Internet-Draft PACE over MOQT June 2026
+================+==================+========================+
| Priority Range | Category | Use |
+================+==================+========================+
| 0-15 | Critical Control | Session termination, |
| | | emergency cancel |
+----------------+------------------+------------------------+
| 16-31 | Urgent Control | Error notifications, |
| | | auth revocation |
+----------------+------------------+------------------------+
| 32-63 | Real-time Media | Voice/video frames |
+----------------+------------------+------------------------+
| 64-95 | Interactive | Chat messages, |
| | | streaming LLM tokens |
+----------------+------------------+------------------------+
| 96-127 | Standard | Tool calls, request/ |
| | Operations | response |
+----------------+------------------+------------------------+
| 128-159 | Discovery | Capability cards, |
| | | agent advertisements |
+----------------+------------------+------------------------+
| 160-191 | Background | Telemetry, non- |
| | | critical notifications |
+----------------+------------------+------------------------+
| 192-255 | Bulk Transfer | File transfers, |
| | | context exchange |
+----------------+------------------+------------------------+
Table 5
6.4. Request/Response Pattern
Request/response interactions use coordinated publish operations.
Agent A publishes a request object on its own track
("pace","agents","agent-a",{sid}) -- "ops/{req-id}". Agent B, which
has subscribed to A's session namespace, receives the request,
processes it, and publishes the response on its own corresponding
track ("pace","agents","agent-b",{sid}) -- "ops/{req-id}". Agent A
receives the response through its subscription to B's session
namespace.
For a detailed example of request/response over MOQT tracks, see
[MCP-MOQT] which defines this pattern for MCP tool invocations.
Nandakumar & Jennings Expires 30 December 2026 [Page 17]
Internet-Draft PACE over MOQT June 2026
6.5. Streaming Pattern
Long-running operations produce incremental results as MOQT objects
organized into groups representing execution phases. The server
advances to a new group at each phase transition (e.g.,
initialization, progress, completion). Multiple objects within a
group represent incremental data for that phase.
Late-joining subscribers receive the latest complete group from relay
cache, enabling mid-operation catch-up without replaying the full
history.
6.6. Real-Time Media Exchange
Audio and video streams use dedicated tracks ("audio", "video") with
descending group order (newest-first) and high priority (32-63),
ensuring media frames preempt lower-priority data under congestion.
7. Communication Topologies
PACE supports multiple communication topologies through MOQT's relay
fan-out:
Point-to-Point: Two agents publish and subscribe to each other's
session tracks. Used for tool invocation, task delegation, and
bilateral collaboration.
Point-to-Multipoint (Fan-Out): One agent publishes; multiple agents
subscribe. The relay handles fan-out without the publisher
maintaining per-subscriber state. Used for broadcast
notifications and shared context distribution.
Multi-Party: All participants publish on their own tracks and
subscribe to each other's tracks within the same session-id.
Adding a participant requires publishing SESSION_JOIN on the
control track; existing participants receive the notification and
subscribe to the new agent's session namespace.
Hierarchical Teams: A coordinator creates child PACE sessions to
delegate subtasks. Each level operates as a separate session with
narrowed authorization scope. Delegation chains (Section 5)
maintain an auditable path from the original user authorization.
Nandakumar & Jennings Expires 30 December 2026 [Page 18]
Internet-Draft PACE over MOQT June 2026
8. Protocol Bindings
This section defines protocol bindings that map application protocol
semantics to MOQT. Each binding operates within PACE sessions, using
the Session Communication Namespace (Section 3.1) and channel
architecture (Section 6).
8.1. Binding Architecture
Protocol bindings sit between application protocols and the PACE
session layer. Each binding defines:
* *Protocol Identifier*: Unique string used as the track name prefix
* *Namespace Pattern*: How operations map to track names
* *Message Serialization*: Encoding within MOQT object payloads
* *Operation Mapping*: Protocol operations to MOQT primitives
* *Priority Mapping*: Message types to PACE priority tiers
Protocols use distinct track name prefixes within PACE sessions:
+==========+==============+====================================+
| Protocol | Track Prefix | Example Full Path |
+==========+==============+====================================+
| A2A | a2a/ | ("pace","agents","agent-a","s1") |
| | | -- "a2a/task/t1" |
+----------+--------------+------------------------------------+
| MCP | mcp/ | ("pace","agents","fs-server","s1") |
| | | -- "mcp/tools/read" |
+----------+--------------+------------------------------------+
| AutoGen | autogen/ | ("pace","agents","rt1","s1") -- |
| | | "autogen/message/conv1" |
+----------+--------------+------------------------------------+
| Generic | ext/{proto}/ | ("pace","agents","agent-a","s1") |
| | | -- "ext/myproto/rpc/call" |
+----------+--------------+------------------------------------+
Table 6
8.2. A2A Binding
The Agent-to-Agent Protocol [A2A] binding maps A2A task delegation
and collaboration to MOQT primitives using the a2a/ category prefix.
Nandakumar & Jennings Expires 30 December 2026 [Page 19]
Internet-Draft PACE over MOQT June 2026
8.2.1. Namespace Structure
A2A operates within a PACE session. Each agent publishes A2A
messages on tracks under its own session namespace:
Namespace: ("pace", "agents", {agent-id}, {session-id})
Tracks: "a2a/{subcategory}/{identifier}"
A2A track name patterns:
+===========================+======================+
| Track Pattern | Purpose |
+===========================+======================+
| a2a/request/{request-id} | Outbound requests |
+---------------------------+----------------------+
| a2a/response/{request-id} | Request responses |
+---------------------------+----------------------+
| a2a/stream/{request-id} | Streaming operations |
+---------------------------+----------------------+
| a2a/task/{task-id} | Task lifecycle |
+---------------------------+----------------------+
| a2a/notify/{type} | Push notifications |
+---------------------------+----------------------+
Table 7
8.2.2. A2A Operation Mapping
The following table maps A2A v0.3.0 operations to MOQT primitives:
Nandakumar & Jennings Expires 30 December 2026 [Page 20]
Internet-Draft PACE over MOQT June 2026
+===========================+=====================+================+
| A2A Operation | MOQT Mechanism |Track Name |
+===========================+=====================+================+
| SendMessage | PUBLISH + OBJECT |a2a/ |
| | |request/{req-id}|
+---------------------------+---------------------+----------------+
| SendStreamingMessage | PUBLISH + multiple |a2a/stream/{req-|
| | OBJECTs |id} |
+---------------------------+---------------------+----------------+
| GetTask | SUBSCRIBE + OBJECT |a2a/task/{task- |
| | |id} |
+---------------------------+---------------------+----------------+
| ListTasks | SUBSCRIBE_NAMESPACE |(discover a2a/ |
| | |task/* tracks) |
+---------------------------+---------------------+----------------+
| CancelTask | OBJECT on ctrl |ctrl |
| | track | |
+---------------------------+---------------------+----------------+
| SubscribeToTask | SUBSCRIBE (ongoing) |a2a/task/{task- |
| | |id} |
+---------------------------+---------------------+----------------+
| GetExtendedAgentCard | SUBSCRIBE + OBJECT |Agent's card |
| | |track |
+---------------------------+---------------------+----------------+
| SetPushNotificationConfig | PUBLISH + OBJECT |a2a/notify/ |
| | |config |
+---------------------------+---------------------+----------------+
| GetPushNotificationConfig | SUBSCRIBE + OBJECT |a2a/notify/ |
| | |config |
+---------------------------+---------------------+----------------+
Table 8
8.2.3. Message Format
A2A messages are serialized as JSON-RPC 2.0 within MOQT objects,
preserving A2A's native format. The PACE envelope wraps the JSON
bytes:
Nandakumar & Jennings Expires 30 December 2026 [Page 21]
Internet-Draft PACE over MOQT June 2026
{
"jsonrpc": "2.0",
"method": "message/send",
"params": {
"message": {
"role": "user",
"parts": [{"kind": "text", "text": "Hello agent"}]
}
},
"id": "req-001"
}
8.2.4. Priority Mapping
+==================+=====================+======================+
| A2A Message Type | MOQT Priority Range | Description |
+==================+=====================+======================+
| Cancel/Error | 0-31 | Task cancellation, |
| | | critical errors |
+------------------+---------------------+----------------------+
| SendMessage | 32-63 | Responses requiring |
| response | | immediate delivery |
+------------------+---------------------+----------------------+
| SendMessage | 64-95 | Normal request |
| request | | messages |
+------------------+---------------------+----------------------+
| Task status | 96-127 | Incremental task |
| updates | | state changes |
+------------------+---------------------+----------------------+
| Streaming | 96-127 | Streaming result |
| artifacts | | data |
+------------------+---------------------+----------------------+
| Discovery (Agent | 128-159 | Agent card exchange |
| Card) | | |
+------------------+---------------------+----------------------+
| Push | 160-191 | Asynchronous |
| notifications | | notifications |
+------------------+---------------------+----------------------+
| Background/bulk | 192-255 | Large file |
| | | transfers, batch ops |
+------------------+---------------------+----------------------+
Table 9
Nandakumar & Jennings Expires 30 December 2026 [Page 22]
Internet-Draft PACE over MOQT June 2026
8.2.5. Streaming Support
A2A streaming operations (SendStreamingMessage, task subscriptions)
use the streaming pattern defined in Section 6.5. A2A streaming
events map to MOQT objects as follows:
* Each streaming response creates a new MOQT group
* TaskStatusUpdateEvent (state changes) and TaskArtifactUpdateEvent
(output data) are individual objects within groups
* Groups represent execution phases (initialization, progress,
completion)
8.2.6. A2A Agent Card with MOQT Extension
When operating over PACE, the A2A Agent Card includes a moqt
extension block:
{
"name": "research-assistant",
"protocolVersion": "0.3.0",
"capabilities": {"streaming": true, "pushNotifications": true},
"skills": [{"id": "web-research", "name": "Web Research"}],
"authentication": {"schemes": ["bearer", "oauth2"]},
"moqt": {
"relayEndpoint": "moqt://relay.example.com:4443",
"webTransportEndpoint": "https://relay.example.com:4443/moqt",
"namespace": ["pace", "agents", "research-assistant"],
"supportedExtensions": ["pace-v1"],
"maxConcurrentSubscriptions": 100,
"cacheTTL": 300
},
"signature": "base64-encoded-ed25519-signature"
}
The moqt extension fields:
Nandakumar & Jennings Expires 30 December 2026 [Page 23]
Internet-Draft PACE over MOQT June 2026
+============================+============================+
| Field | Description |
+============================+============================+
| relayEndpoint | Native QUIC endpoint for |
| | the MOQT relay |
+----------------------------+----------------------------+
| webTransportEndpoint | WebTransport endpoint |
| | (alternative connectivity) |
+----------------------------+----------------------------+
| namespace | Agent's namespace prefix |
| | as array |
+----------------------------+----------------------------+
| supportedExtensions | MOQT/PACE extensions |
| | supported |
+----------------------------+----------------------------+
| maxConcurrentSubscriptions | Maximum subscriptions the |
| | agent handles |
+----------------------------+----------------------------+
| cacheTTL | Cache duration for the |
| | agent card (seconds) |
+----------------------------+----------------------------+
Table 10
8.3. MCP Binding
The Model Context Protocol [MCP] binding enables tool and resource
access for agents. Within a PACE session, MCP tracks use the "mcp/"
prefix under the agent's session namespace:
Namespace: ("pace", "agents", {server-id}, {session-id})
Tracks: "mcp/{subcategory}/{identifier}"
The complete MCP over MOQT specification — including track structure,
operation mapping, message serialization, Agent Skills architecture,
and relay support — is defined in [MCP-MOQT]. PACE adopts that
specification's track semantics, mapping its namespace tuples (e.g.,
(mcp, {session-id}, tools) -- ({tool-name})) into PACE track names
(e.g., "mcp/tools/{tool-name}") as described in Section 3.1.
8.4. AutoGen Binding
AutoGen [AutoGen] is a multi-agent conversation framework. This
binding maps AutoGen's conversation patterns to MOQT within PACE
sessions.
8.4.1. Namespace Structure
Nandakumar & Jennings Expires 30 December 2026 [Page 24]
Internet-Draft PACE over MOQT June 2026
Namespace: ("pace", "agents", {runtime-id}, {session-id})
Tracks: "autogen/{subcategory}/{identifier}"
Where runtime-id is the AutoGen runtime instance identifier.
+===================================+======================+
| Track Pattern | Purpose |
+===================================+======================+
| autogen/message/{conversation-id} | Inter-agent messages |
+-----------------------------------+----------------------+
| autogen/control/{command} | Runtime control |
+-----------------------------------+----------------------+
| autogen/state/{state-key} | Agent state sync |
+-----------------------------------+----------------------+
| autogen/result/{task-id} | Final outputs |
+-----------------------------------+----------------------+
Table 11
8.4.2. Message Format
AutoGen messages are serialized as JSON with the following structure:
{
"sender": "agent-name",
"recipient": "agent-name | broadcast",
"content": "message content or structured data",
"metadata": {
"conversation_id": "conv-123",
"turn": 5,
"role": "assistant | user | system"
}
}
8.4.3. Conversation Patterns
AutoGen's conversation patterns map to MOQT as follows:
Two-Agent Chat: Each agent publishes to their message track. Agents
subscribe to their conversation partner's track.
Group Chat: A coordinator agent manages turn-taking. All agents
subscribe to the coordinator's broadcast track.
Nested Chat: Hierarchical conversations use nested session-ids. An
outer agent creates a child PACE session for the inner
conversation, linking it to the parent via delegation chains.
Nandakumar & Jennings Expires 30 December 2026 [Page 25]
Internet-Draft PACE over MOQT June 2026
8.4.4. Priority Mapping
+======================+=====================+
| AutoGen Message Type | MOQT Priority Range |
+======================+=====================+
| Termination signals | 0-31 |
+----------------------+---------------------+
| Human input requests | 32-63 |
+----------------------+---------------------+
| Agent responses | 64-95 |
+----------------------+---------------------+
| Function results | 96-127 |
+----------------------+---------------------+
| State updates | 128-159 |
+----------------------+---------------------+
| Logging/debug | 160-255 |
+----------------------+---------------------+
Table 12
8.5. Generic JSON-RPC Binding
This binding provides a baseline for custom protocols using JSON-RPC
2.0 messaging.
8.5.1. Namespace Structure
Namespace: ("pace", "agents", {agent-id}, {session-id})
Tracks: "ext/{protocol-name}/{subcategory}/{identifier}"
Where protocol-name is the custom protocol identifier.
+================================+==================+
| Track Pattern | Purpose |
+================================+==================+
| ext/{proto}/rpc/{request-id} | Request/response |
+--------------------------------+------------------+
| ext/{proto}/stream/{stream-id} | Streaming data |
+--------------------------------+------------------+
| ext/{proto}/event/{event-type} | Async events |
+--------------------------------+------------------+
Table 13
8.5.2. Message Format
Messages follow standard JSON-RPC 2.0:
Nandakumar & Jennings Expires 30 December 2026 [Page 26]
Internet-Draft PACE over MOQT June 2026
{
"jsonrpc": "2.0",
"method": "protocol.method",
"params": {},
"id": "request-id"
}
8.5.3. Extension Mechanism
Custom protocols extend this binding by defining additional track
subcategories, custom message schemas within JSON-RPC params,
protocol-specific priorities, and custom MOQT extension headers.
Implementations SHOULD document extensions and MAY register them in
the IANA PACE Protocol Binding Registry.
9. Authorization and Security
9.1. Authorization Model
PACE implements a behavior-driven authorization model where access
tokens are scoped to specific operations an agent is permitted to
perform.
9.1.1. Behavior-Driven Scopes
Scopes are structured as {domain}:{resource}:{action}:{constraints},
bound to specific agent behaviors rather than roles. Constraints
support dynamic limits (time bounds, resource limits, counts).
9.1.2. Delegated Authorization
When agents invoke other agents, each delegation narrows the scope.
Agent A (holding scope S) requests a sub-scope S' ⊂ S for Agent B.
Agent B can further narrow to S'' ⊂ S' for downstream tools.
Downstream agents cannot exceed their delegator's permissions.
Authorization tokens are presented in SESSION_INIT and validated
including the full delegation chain. Tokens are refreshed
proactively before expiration.
9.1.3. Confirmation and Evidence
For high-risk operations, PACE supports confirmation requirements
where agents must present cryptographic evidence of approval (human,
policy-check, or MFA) before the operation proceeds.
Nandakumar & Jennings Expires 30 December 2026 [Page 27]
Internet-Draft PACE over MOQT June 2026
9.2. Transport Security
All PACE communication is encrypted via TLS 1.3 (QUIC requirement).
Agent identity tokens are cryptographically signed with short expiry.
MOQT Common Access Tokens [MoQ-C4M] provide relay-level namespace
authorization. Relay nodes cannot access payload content unless
explicitly authorized as trusted intermediaries.
9.3. Privacy Considerations
Agents SHOULD minimize shared data to what is necessary for the task.
Long-lived sessions SHOULD support forward secrecy through periodic
key rotation. Relay operators MUST NOT retain content beyond
operational necessity.
10. Scalability and Reliability
PACE inherits MOQT's relay architecture for geographic distribution
and load management:
* *Subscription Aggregation*: Multiple subscribers to the same track
result in a single upstream subscription, reducing origin load
* *Geographic Locality*: Edge relays cache content close to
subscribers, minimizing round-trip latency
* *Fault Isolation*: Relay failures are localized; other paths
continue operating
10.1. Failure Modes and Recovery
+====================+===================+=======================+
| Failure | Detection | Recovery |
+====================+===================+=======================+
| Agent network loss | QUIC idle timeout | Connection migration, |
| | | session resume |
+--------------------+-------------------+-----------------------+
| Relay failure | Subscription | Failover to alternate |
| | timeout | relay |
+--------------------+-------------------+-----------------------+
| Agent crash | Session heartbeat | Session suspended, |
| | miss | await resume |
+--------------------+-------------------+-----------------------+
| Prolonged outage | Session timeout | Session closed, state |
| | | checkpointed |
+--------------------+-------------------+-----------------------+
Table 14
Nandakumar & Jennings Expires 30 December 2026 [Page 28]
Internet-Draft PACE over MOQT June 2026
Session recovery mechanics are defined in Section 4.5.
11. Security Considerations
TODO
12. IANA Considerations
12.1. MOQT Setup Parameter Registry
This document requests registration of the following MOQT setup
parameters:
+======================+============+=======================+
| Parameter Name | ID | Description |
+======================+============+=======================+
| pace-version | 0x50414301 | PACE protocol version |
+----------------------+------------+-----------------------+
| agent-identity | 0x50414302 | Agent identity token |
| | | reference |
+----------------------+------------+-----------------------+
| supported-protocols | 0x50414303 | Application protocol |
| | | bitmask |
+----------------------+------------+-----------------------+
| auth-schemes | 0x50414304 | Authentication scheme |
| | | identifiers |
+----------------------+------------+-----------------------+
| session-capabilities | 0x50414305 | Session capability |
| | | flags |
+----------------------+------------+-----------------------+
Table 15
12.2. PACE Protocol Binding Registry
IANA is requested to create a registry for PACE protocol bindings.
Each entry contains:
* Protocol Identifier (string)
* Protocol Version
* Namespace Prefix Pattern
* Reference Document
Initial entries:
Nandakumar & Jennings Expires 30 December 2026 [Page 29]
Internet-Draft PACE over MOQT June 2026
+=============+============+========================+===============+
| Protocol ID | Version | Track Name Pattern | Reference |
+=============+============+========================+===============+
| a2a | 0.3.0 | a2a/{sub}/{id} | This |
| | | | document |
+-------------+------------+------------------------+---------------+
| mcp | 2025-06-18 | mcp/{sub}/{id} | This |
| | | | document |
+-------------+------------+------------------------+---------------+
| autogen | 0.4 | autogen/{sub}/{id} | This |
| | | | document |
+-------------+------------+------------------------+---------------+
| (generic) | - | ext/{proto}/{sub}/{id} | This |
| | | | document |
+-------------+------------+------------------------+---------------+
Table 16
12.3. PACE Message Type Registry
IANA is requested to create a registry for PACE session control
message types:
+=================+======+================================+
| Message Type | Code | Description |
+=================+======+================================+
| SESSION_INIT | 0x01 | Initiate session establishment |
+-----------------+------+--------------------------------+
| SESSION_ACCEPT | 0x02 | Accept session establishment |
+-----------------+------+--------------------------------+
| SESSION_REJECT | 0x03 | Reject session establishment |
+-----------------+------+--------------------------------+
| SESSION_UPDATE | 0x04 | Update session parameters |
+-----------------+------+--------------------------------+
| SESSION_SUSPEND | 0x05 | Suspend active session |
+-----------------+------+--------------------------------+
| SESSION_RESUME | 0x06 | Resume suspended session |
+-----------------+------+--------------------------------+
| SESSION_CLOSE | 0x07 | Terminate session |
+-----------------+------+--------------------------------+
| SESSION_JOIN | 0x08 | Join multi-party session |
+-----------------+------+--------------------------------+
| SESSION_LEAVE | 0x09 | Leave multi-party session |
+-----------------+------+--------------------------------+
Table 17
13. References
Nandakumar & Jennings Expires 30 December 2026 [Page 30]
Internet-Draft PACE over MOQT June 2026
13.1. Normative References
[MoQ-TRANSPORT]
Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
I. Swett, "Media over QUIC Transport", Work in Progress,
Internet-Draft, draft-ietf-moq-transport-16, January 2026,
<https://datatracker.ietf.org/doc/draft-ietf-moq-
transport/>.
[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/rfc/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[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/rfc/rfc8174>.
[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/rfc/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
13.2. Informative References
[A2A] A2A Project, "Agent-to-Agent Protocol Specification",
Version 0.3.0, 2025,
<https://google.github.io/A2A/specification/>.
[AutoGen] Wu, Q., Banber, G., Zhang, Y., Wu, Y., Li, B., Zhu, E.,
and A. Awadallah, "AutoGen: Enabling Next-Gen LLM
Applications via Multi-Agent Conversation",
arXiv 2308.08155, 2023,
<https://arxiv.org/abs/2308.08155>.
[MCP] Anthropic, "Model Context Protocol Specification",
Version 2025-06-18, June 2025,
<https://modelcontextprotocol.io/specification/>.
Nandakumar & Jennings Expires 30 December 2026 [Page 31]
Internet-Draft PACE over MOQT June 2026
[MCP-MOQT] Jennings, C., Swett, I., Rosenberg, J., and S. Nandakumar,
"Model Context Protocol and Agent Skills over Media over
QUIC Transport", Work in Progress, Internet-Draft, draft-
mcp-over-moqt, 2025,
<https://datatracker.ietf.org/doc/draft-mcp-over-moqt/>.
[MoQ-C4M] Jennings, S., "Common Access Token for Media over QUIC",
Work in Progress, Internet-Draft, draft-ietf-moq-c4m,
2025,
<https://datatracker.ietf.org/doc/draft-ietf-moq-c4m/>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>.
[RFC9110] 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/rfc/rfc9110>.
[RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
2022, <https://www.rfc-editor.org/rfc/rfc9297>.
[SD-AGENT] Nandakumar, S. and C. Jennings, "SD Agent: Selective
Disclosure for Agent Discovery and Identity Management",
Work in Progress, Internet-Draft, draft-nandakumar-agent-
sd-jwt-02, February 2026,
<https://datatracker.ietf.org/doc/draft-nandakumar-agent-
sd-jwt/>.
Appendix A. Example Workflows
This appendix illustrates common PACE workflows end-to-end, showing
how agents use the namespace structure, session establishment, and
protocol bindings defined in this document.
A.1. Agent-to-Agent: Task Delegation
Agent A (a coordinator) delegates a research task to Agent B. This
is a point-to-point session using the A2A binding.
Nandakumar & Jennings Expires 30 December 2026 [Page 32]
Internet-Draft PACE over MOQT June 2026
*Setup*: Agent A generates session-id s1 (a UUID) and establishes a
session with Agent B via the flow in Section 4.
*Resulting namespace layout*:
Agent A publishes:
("pace","agents","agent-a","s1") -- "ctrl" (SESSION_INIT)
("pace","agents","agent-a","s1") -- "a2a/request/r1" (task request)
Agent B publishes:
("pace","agents","agent-b","s1") -- "ctrl" (SESSION_ACCEPT)
("pace","agents","agent-b","s1") -- "a2a/response/r1" (task result)
*Flow*:
1. A publishes SESSION_INIT on its "ctrl" track — the relay forwards
to B via B's SUBSCRIBE_TRACKS prefix match
2. B accepts the forwarded PUBLISH, publishes SESSION_ACCEPT on its
own "ctrl" track
3. A receives SESSION_ACCEPT via the relay (A's SUBSCRIBE_TRACKS on
B)
4. A publishes a JSON-RPC request on "a2a/request/r1":
{"jsonrpc":"2.0","method":"message/
send","params":{...},"id":"r1"}
5. B receives the request (via its subscription to A's namespace),
processes it, and publishes the result on "a2a/response/r1"
6. A receives the response via its subscription to B's namespace
7. Either agent publishes SESSION_CLOSE on "ctrl" to terminate
A.2. Agent-to-Tool: MCP Tool Invocation
Agent A needs to read a file using a filesystem tool (an MCP server).
*Setup*: Agent A generates session-id s2 and establishes a session
with the filesystem tool.
*Resulting namespace layout*:
Nandakumar & Jennings Expires 30 December 2026 [Page 33]
Internet-Draft PACE over MOQT June 2026
Agent A publishes:
("pace","agents","agent-a","s2") -- "ctrl"
("pace","agents","agent-a","s2") -- "mcp/tools/readFile" (tool call)
Tool publishes:
("pace","agents","fs-tool","s2") -- "ctrl"
("pace","agents","fs-tool","s2") -- "mcp/tools/readFile" (tool result)
*Flow*:
1. A establishes a session with the tool (SESSION_INIT / ACCEPT)
2. A publishes a tool call on "mcp/tools/readFile":
{"jsonrpc":"2.0","method":"tools/
call","params":{"name":"readFile", "arguments":{"path":"/data/
report.csv"}},"id":"t1"}
3. Tool receives the call, reads the file, publishes the result on
its own "mcp/tools/readFile" track
4. A receives the file contents
5. A may issue additional tool calls within the same session or
close it
A.3. Multi-Agent Collaboration
Agent A (coordinator) creates a research session and invites Agent B
(web researcher) and Agent C (data analyst) to collaborate.
*Setup*: Agent A generates session-id s3 and publishes SESSION_INIT
on its ctrl track — the relay forwards to B and C via their
SUBSCRIBE_TRACKS prefix match on A's agent namespace.
*Resulting namespace layout*:
Nandakumar & Jennings Expires 30 December 2026 [Page 34]
Internet-Draft PACE over MOQT June 2026
Agent A publishes:
("pace","agents","agent-a","s3") -- "ctrl" (session mgmt, assignments)
("pace","agents","agent-a","s3") -- "chat" (coordination messages)
Agent B publishes:
("pace","agents","agent-b","s3") -- "ctrl" (SESSION_ACCEPT)
("pace","agents","agent-b","s3") -- "chat" (status updates)
("pace","agents","agent-b","s3") -- "a2a/task/research-1" (findings)
Agent C publishes:
("pace","agents","agent-c","s3") -- "ctrl" (SESSION_ACCEPT)
("pace","agents","agent-c","s3") -- "chat" (status updates)
("pace","agents","agent-c","s3") -- "a2a/task/analysis-1" (results)
*Subscriptions*: Each agent subscribes to the other two agents'
session namespaces:
* A subscribes to ("pace","agents","agent-b","s3") and
("pace","agents","agent-c","s3")
* B subscribes to ("pace","agents","agent-a","s3") and
("pace","agents","agent-c","s3")
* C subscribes to ("pace","agents","agent-a","s3") and
("pace","agents","agent-b","s3")
*Flow*:
1. A establishes session, B and C accept
2. A publishes task assignments on "chat" — the relay fans out to
both B and C
3. B performs web research, publishes findings incrementally on
"a2a/task/research-1" (using MOQT groups for phases)
4. C subscribes to B's research track, receives findings as they
arrive, and begins analysis
5. C publishes analysis results on "a2a/task/analysis-1"
6. A monitors all progress through its subscriptions and publishes a
final summary when complete
7. A publishes SESSION_CLOSE — all participants unsubscribe
Nandakumar & Jennings Expires 30 December 2026 [Page 35]
Internet-Draft PACE over MOQT June 2026
A.4. Agent-to-Tool with Streaming: Long-Running Operation
Agent A invokes a code-generation tool that produces output
incrementally.
*Setup*: Same as tool invocation — Agent A and the tool share
session-id s4.
*Flow*:
1. A publishes a tool call on "mcp/tools/generateCode"
2. Tool begins generating code and publishes results using MOQT
groups:
* Group 0: {"status":"started","language":"python"}
* Group 1, Object 0: first code block
* Group 1, Object 1: second code block
* Group 2: {"status":"complete","totalLines":142}
3. A receives objects as they are published (ascending group order)
4. If A needs to cancel, it publishes a cancellation on "ctrl"
5. Tool receives cancellation, stops generation, publishes final
status
Appendix B. Acknowledgments
TODO
Authors' Addresses
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com
Cullen Jennings
Cisco Systems
Email: fluffy@cisco.com
Nandakumar & Jennings Expires 30 December 2026 [Page 36]