# AIP Compatibility Profiles

This is a supporting implementation reference. Section 21 of the
[AIP 1.0 Specification](AIP-1.0.md) defines the normative compatibility
boundary; profile-specific schemas, version matrices, and conformance suites
define the exact foreign-protocol wire behavior.

AIP compatibility profiles map existing protocols and delivery mechanisms into
the AIP semantic core without importing implementation code from those systems.

Implemented profiles:

- `aip.mcp.compat.v1`
- `aip.a2a.compat.v1`
- `aip.http.webhook.v1`
- `aip.native.nats.v1`
- `aip.sse.stream.v1`
- `aip.websocket.stream.v1`

## MCP Profile

The MCP profile maps MCP JSON-RPC methods into native AIP capabilities,
resources, and task views. The implementation is intentionally split across
separate crates:

- `aip-profile-mcp`: pure DTOs and semantic mapping.
- `aip-mcp-server`: AIP-backed MCP server lifecycle.
- `aip-mcp-client`: outbound bridge for external MCP servers.
- `aip-transport-mcp-stdio`: newline-delimited stdio framing.
- `aip-transport-mcp-streamable-http`: Streamable HTTP request and SSE helpers.
- `aip-mcp-conformance`: embeddable compatibility checks.

`aipd` exposes the profile at `/mcp`, `/mcp/v1`, and `/aip/v1/mcp`.

Implemented methods:

- `initialize`
- `notifications/initialized`
- `ping`
- `notifications/cancelled`
- `notifications/progress`
- `tools/list`
- `tools/call`
- `notifications/tools/list_changed`
- `resources/list`
- `resources/read`
- `resources/templates/list`
- `resources/subscribe`
- `resources/unsubscribe`
- `notifications/resources/list_changed`
- `notifications/resources/updated`
- `prompts/list`
- `prompts/get`
- `notifications/prompts/list_changed`
- `completion/complete`
- `logging/setLevel`
- `notifications/message`
- `roots/list`
- `notifications/roots/list_changed`
- `sampling/createMessage`
- `elicitation/create`
- `notifications/elicitation/complete`
- `tasks/list`
- `tasks/get`
- `tasks/result`
- `tasks/cancel`
- `notifications/tasks/status`
- draft-aware `server/discover` parsing in the profile only; stable endpoints do
  not advertise or emit draft discovery messages

`tools/call` is translated into a native AIP `Action` and executed by the same
gateway/runtime path used by native HTTP and NATS. JSON-RPC errors are derived
from typed AIP `ProtocolError` values. MCP-specific lifecycle, request
correlation, sessions, roots, sampling, elicitation, prompts, completions, and
task views stay outside `aip-core`.

Streamable HTTP behavior:

- `POST` accepts JSON-RPC requests, notifications, and client responses.
- `GET` opens an SSE discovery stream.
- `DELETE` removes the MCP session state.
- `MCP-Protocol-Version`, `MCP-Session-Id`, and `Last-Event-ID` are parsed by
  the transport helper crate.
- Origin checks, bearer token parsing, protected-resource metadata, and
  `WWW-Authenticate` bearer challenges are exposed as transport-level helpers so
  deployments can enforce MCP HTTP authorization without moving policy into
  `aip-core`.

stdio behavior:

- one JSON-RPC message per newline-delimited frame;
- request, notification, and response frames are decoded into typed MCP DTOs;
- process lifecycle remains host-controlled so embedders can enforce their own
  sandboxing policy.

## A2A Profile

The A2A profile maps Agent Card discovery and task-oriented JSON-RPC operations
into native AIP manifests, actions, cancellations, and action results. `aipd`
exposes Agent Card discovery at `/.well-known/agent.json` and `/a2a/agent-card`;
JSON-RPC is exposed at `/a2a`, `/a2a/v1`, and `/aip/v1/a2a`.

Implemented A2A 1.0 operations:

- `SendMessage`
- `SendStreamingMessage`
- `GetTask`
- `ListTasks`
- `CancelTask`
- `SubscribeToTask`
- `CreateTaskPushNotificationConfig`
- `GetTaskPushNotificationConfig`
- `ListTaskPushNotificationConfigs`
- `DeleteTaskPushNotificationConfig`

The profile includes current Agent Card interfaces, extensions, skills,
security schemes, ProtoJSON roles and task states, message parts, artifacts,
history, and push notification resources. Message operations execute through a
native AIP `Action`; cancellation translates into native AIP `Cancel`; task
state projects from the durable native action read model. Push configuration and
delivery cursors use the generic durable profile-state contract. Credentials
are encrypted at rest, payloads are signed, callback destinations use the same
SSRF policy as native callbacks, and delivery is lease-fenced and retryable.
Legacy v0.3 method names are input aliases only and are never advertised as the
current wire surface.

## Native NATS Profile

The native NATS profile uses subject routing plus the native AIP envelope:

```text
aip.v1.{trust_domain}.{service}.{version}.{message_type}
```

Daemon implementations subscribe to the service wildcard:

```text
aip.v1.{trust_domain}.{service}.{version}.>
```

Request/reply payloads may be encoded either as the canonical
`TransportMessage` wrapper or as a raw native `Envelope`. Implementations MUST
return a native `Envelope` response wrapped in `TransportMessage` when replying
through the Rust transport helpers. Standard headers include AIP version,
message type, message id, session id, and correlation id when present.