282 lines
10 KiB
Plaintext
282 lines
10 KiB
Plaintext
Internet-Draft AI/Agent WG
|
|
Intended status: Standards Track March 2026
|
|
Expires: September 15, 2026
|
|
|
|
|
|
Cross-Protocol Agent Translation (CPAT)
|
|
draft-cpat-cross-protocol-agent-translation-00
|
|
|
|
Abstract
|
|
|
|
This document defines the Cross-Protocol Agent Translation (CPAT)
|
|
framework, a lightweight mechanism enabling AI agents using
|
|
different communication protocols to interoperate through
|
|
capability advertisement and message translation. With over 90
|
|
competing agent-to-agent (A2A) protocol drafts and no
|
|
interoperability standard, protocol fragmentation is the primary
|
|
barrier to multi-vendor agent ecosystems. CPAT defines three
|
|
components: a capability advertisement format for agents to
|
|
declare supported protocols, a negotiation handshake to select a
|
|
common protocol or translation path, and a canonical envelope
|
|
format that enables translation gateways to convert messages
|
|
between incompatible protocols. CPAT reuses existing HTTP
|
|
content negotiation patterns and builds on JSON for simplicity.
|
|
|
|
Status of This Memo
|
|
|
|
This Internet-Draft is submitted in full conformance with the
|
|
provisions of BCP 78 and BCP 79.
|
|
|
|
This document is intended to have Standards Track status.
|
|
Distribution of this memo is unlimited.
|
|
|
|
Table of Contents
|
|
|
|
1. Introduction
|
|
2. Terminology
|
|
3. Problem Statement
|
|
4. Protocol Capability Advertisement
|
|
5. Negotiation Handshake
|
|
6. Canonical Envelope Format
|
|
7. Translation Gateway Requirements
|
|
8. Security Considerations
|
|
9. IANA Considerations
|
|
|
|
1. Introduction
|
|
|
|
The IETF AI/agent landscape includes over 90 drafts proposing
|
|
agent-to-agent communication protocols, yet no standard exists
|
|
for agents using different protocols to exchange messages. This
|
|
fragmentation mirrors the early days of instant messaging, where
|
|
users on different networks could not communicate until gateway
|
|
and federation standards emerged.
|
|
|
|
CPAT takes a pragmatic approach: rather than mandating a single
|
|
protocol, it defines the minimum machinery for agents to
|
|
discover each other's protocol support, agree on a common
|
|
format, and fall back to translation gateways when no common
|
|
protocol exists. The design follows three principles:
|
|
|
|
1. Reuse existing standards (HTTP, JSON, TLS) wherever possible.
|
|
2. Keep the core mechanism small enough to implement in a day.
|
|
3. Do not require agents to support any protocol beyond their own
|
|
plus CPAT negotiation.
|
|
|
|
2. 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 RFC 2119 [RFC2119].
|
|
|
|
Agent Protocol: A communication protocol used by an AI agent for
|
|
peer-to-peer message exchange (e.g., A2A, MCP, SLIM, uACP).
|
|
|
|
Capability Document: A JSON object describing the protocols an
|
|
agent supports, served at a well-known URI.
|
|
|
|
Translation Gateway: A service that converts messages between
|
|
two agent protocols using the CPAT canonical envelope as an
|
|
intermediate representation.
|
|
|
|
3. Problem Statement
|
|
|
|
Consider three agents: Agent A speaks Protocol X, Agent B speaks
|
|
Protocol Y, and Agent C speaks both X and Z. Today there is no
|
|
standard way for A to discover that B uses a different protocol,
|
|
negotiate a common format, or route through a translator. Each
|
|
protocol defines its own discovery and messaging layer, creating
|
|
isolated silos.
|
|
|
|
Existing work on Agent Name Service (ANS) and agent discovery
|
|
addresses finding agents but not protocol compatibility. The
|
|
ADOL draft addresses token efficiency within a single protocol
|
|
but not cross-protocol translation. CPAT fills the gap between
|
|
discovery and communication.
|
|
|
|
4. Protocol Capability Advertisement
|
|
|
|
Each CPAT-compliant agent MUST serve a capability document at
|
|
the well-known URI /.well-known/cpat. The document is a JSON
|
|
object with the following structure:
|
|
|
|
{
|
|
"cpat_version": "1.0",
|
|
"agent_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
|
|
"protocols": [
|
|
{
|
|
"id": "a2a-v1",
|
|
"version": "1.0",
|
|
"endpoint": "https://agent.example.com/a2a",
|
|
"priority": 10
|
|
},
|
|
{
|
|
"id": "mcp-v1",
|
|
"version": "2025-03-26",
|
|
"endpoint": "https://agent.example.com/mcp",
|
|
"priority": 20
|
|
}
|
|
],
|
|
"translation_gateways": [
|
|
"https://gateway.example.com/cpat/translate"
|
|
],
|
|
"envelope_formats": ["cpat-envelope-v1"]
|
|
}
|
|
|
|
The "protocols" array MUST contain at least one entry. Each
|
|
entry MUST include "id" (a registered protocol identifier),
|
|
"version", and "endpoint". The "priority" field is OPTIONAL;
|
|
lower values indicate higher preference.
|
|
|
|
Agents SHOULD also advertise their capability document URI in
|
|
DNS SRV or SVCB records for automated discovery. The DNS
|
|
record type "_cpat._tcp" SHOULD be used.
|
|
|
|
5. Negotiation Handshake
|
|
|
|
When Agent A wants to communicate with Agent B, the following
|
|
negotiation procedure applies:
|
|
|
|
Step 1: Agent A fetches Agent B's capability document from
|
|
B's well-known CPAT URI over HTTPS.
|
|
|
|
Step 2: Agent A computes the intersection of its own protocol
|
|
list with Agent B's. If the intersection is non-empty, the
|
|
protocol with the lowest combined priority score is selected.
|
|
Communication proceeds directly using that protocol.
|
|
|
|
Step 3: If no common protocol exists, Agent A checks whether
|
|
any translation gateway listed by either agent supports both
|
|
protocols. Agent A queries the gateway's capability endpoint
|
|
at /.well-known/cpat/gateway:
|
|
|
|
GET /.well-known/cpat/gateway?from=a2a-v1&to=slim-v1
|
|
|
|
The gateway responds with 200 OK and a translation descriptor
|
|
if it supports the pair, or 404 if not.
|
|
|
|
Step 4: If a suitable gateway is found, Agent A sends its
|
|
message wrapped in a CPAT envelope (Section 6) to the gateway,
|
|
which translates and forwards it to Agent B.
|
|
|
|
Step 5: If no gateway supports the required pair, Agent A
|
|
SHOULD return an error to its caller indicating protocol
|
|
incompatibility, using the CPAT error code "no_translation_path".
|
|
|
|
The entire negotiation is stateless and cacheable. Agents
|
|
SHOULD cache capability documents for the duration indicated by
|
|
HTTP Cache-Control headers, defaulting to 3600 seconds.
|
|
|
|
6. Canonical Envelope Format
|
|
|
|
The CPAT envelope wraps a protocol-specific message in a
|
|
standard container for gateway translation. The envelope is a
|
|
JSON object:
|
|
|
|
{
|
|
"cpat_version": "1.0",
|
|
"message_id": "urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8",
|
|
"timestamp": "2026-03-01T12:00:00Z",
|
|
"source": {
|
|
"agent_id": "urn:uuid:...",
|
|
"protocol": "a2a-v1"
|
|
},
|
|
"destination": {
|
|
"agent_id": "urn:uuid:...",
|
|
"protocol": "slim-v1"
|
|
},
|
|
"intent": "task_request",
|
|
"payload": {
|
|
"content_type": "application/json",
|
|
"body": "...base64-encoded protocol-specific message..."
|
|
},
|
|
"trace": ["urn:uuid:...source", "urn:uuid:...gateway"]
|
|
}
|
|
|
|
The "intent" field MUST be one of: "task_request",
|
|
"task_response", "notification", "error", "capability_query".
|
|
This allows gateways to perform semantic translation even when
|
|
protocol message structures differ significantly.
|
|
|
|
The "trace" array provides a simple provenance chain of all
|
|
agents and gateways that have handled the message. Each
|
|
intermediary MUST append its own identifier.
|
|
|
|
The "payload.body" field contains the original protocol message,
|
|
base64-encoded. Gateways translate by decoding the source
|
|
protocol message, mapping it to the CPAT semantic model (intent
|
|
+ standard fields), and re-encoding in the destination protocol.
|
|
|
|
7. Translation Gateway Requirements
|
|
|
|
A CPAT translation gateway MUST:
|
|
|
|
1. Serve a capability document listing all supported protocol
|
|
pairs at /.well-known/cpat/gateway.
|
|
|
|
2. Accept CPAT envelopes via HTTP POST at its translate endpoint.
|
|
|
|
3. Validate envelope integrity before translation.
|
|
|
|
4. Preserve message semantics: the intent, core payload content,
|
|
and metadata MUST survive translation. Fields with no
|
|
equivalent in the destination protocol SHOULD be carried in
|
|
a protocol-specific extension field or dropped with a warning.
|
|
|
|
5. Return the translated envelope in the response body, or
|
|
forward it directly to the destination agent.
|
|
|
|
6. Log all translations with source, destination, and timestamp
|
|
for audit purposes.
|
|
|
|
A gateway MUST NOT modify the payload semantics during
|
|
translation. If exact translation is not possible, the gateway
|
|
MUST include a "translation_warnings" array in the envelope
|
|
listing fields that were approximated or dropped.
|
|
|
|
Gateways SHOULD implement rate limiting per source agent and
|
|
MUST require TLS 1.3 [RFC8446] for all connections.
|
|
|
|
8. Security Considerations
|
|
|
|
Capability documents are served over HTTPS, ensuring transport
|
|
security. Agents SHOULD verify the TLS certificate of peers
|
|
before trusting their capability documents.
|
|
|
|
CPAT envelopes in transit through gateways are visible to the
|
|
gateway operator. For end-to-end confidentiality, agents MAY
|
|
encrypt the payload.body field using a shared key established
|
|
out of band. The envelope metadata (intent, agent IDs,
|
|
timestamps) remains visible to enable routing.
|
|
|
|
Gateways are trusted intermediaries. Deployments SHOULD use
|
|
gateways operated by mutually trusted parties or verified
|
|
through attestation mechanisms such as those in
|
|
draft-aylward-daap-v2.
|
|
|
|
The trace array enables detection of routing loops and
|
|
unauthorized intermediaries. Agents SHOULD reject messages
|
|
with unexpected entries in the trace.
|
|
|
|
Denial-of-service attacks against gateways are mitigated by
|
|
rate limiting (Section 7) and standard HTTP-layer protections.
|
|
|
|
9. IANA Considerations
|
|
|
|
This document requests IANA establish the following:
|
|
|
|
1. A "CPAT Protocol Identifier" registry under Expert Review
|
|
policy. Initial entries: "a2a-v1", "mcp-v1", "slim-v1",
|
|
"uacp-v1", "ainp-v1".
|
|
|
|
2. A "CPAT Intent Type" registry under Specification Required
|
|
policy. Initial entries: "task_request", "task_response",
|
|
"notification", "error", "capability_query".
|
|
|
|
3. A well-known URI registration for "cpat" per RFC 8615.
|
|
|
|
Author's Address
|
|
|
|
Generated by IETF Draft Analyzer
|
|
2026-03-01
|