feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,281 @@
|
||||
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
|
||||
Reference in New Issue
Block a user