[Proposal]: MailA2A custom protocol binding for store-and-forward email

## Abstract

I propose MailA2A, a custom protocol binding that maps A2A v1.0 operations and
data onto RFC 5322 email threads and MIME parts. The use case is asynchronous,
store-and-forward agents that already have governed mailboxes, must cross
organizational mail infrastructure, or are intermittently connected.

Draft specification and portable reference validator:

Stable community binding URI:

## Motivation

The standard HTTP/JSON, JSON-RPC, and gRPC bindings are the right default for
online services, but do not provide email's store-and-forward delivery,
mailbox-based operational boundary, or compatibility with existing enterprise
mail gateways. This is a transport binding rather than a core-protocol change:
it preserves A2A Task, Message, Artifact, operation, error, and Agent Card
semantics.

There is historical precedent but no current equivalent. FIPA's abstract
architecture explicitly modeled SMTP agent addresses; ECMA NLIP has HTTP,
WebSocket, and AMQP bindings. Neither defines an A2A v1.0 email binding.

## Initial technical approach

- One RFC 5322 message is one A2A request, response, error, or ordered event.
- A protected `application/a2a+json` MIME part carries canonical A2A JSON.
- `Message-ID`, `In-Reply-To`, and `References` correlate the mail thread;
protected correlation/task/context IDs remain authoritative.
- Streaming is an ordered sequence of email events with explicit sequence,
finality, gap recovery, deduplication, expiry, and idempotency rules. It is
not presented as low-latency SSE.
- Outer `Mail-A2A-*` fields are routing hints only. Effectful processing uses
authenticated protected content.
- Direct messages profile S/MIME 4.0 or OpenPGP/MIME. Private groups carry the
protected envelope as MLS application data in RFC 9420 `message/mls`.
- The optional payment profile carries exact transport-neutral x402 v2
`PaymentRequired`, `PaymentPayload`, and `SettlementResponse` objects without
copying HTTP 402 or `PAYMENT-*` headers into email.

The repository contains a normative draft, JSON Schema, Agent Card and EML
examples, a security policy, and a zero-dependency `.cljc` validator. JVM and
ClojureScript runs currently pass 8 tests / 16 assertions each.

## Questions for maintainers

1. Should a custom binding's `AgentInterface.url` explicitly permit an endpoint
URI such as `mailto:`, despite URL wording oriented toward network services?
2. Is an ordered finite message sequence an acceptable streaming binding when
the Agent Card and specification state its latency and recovery semantics?
3. Would maintainers prefer no experimental mail header fields at all, with
every service parameter only in the protected JSON part?
4. If there is interest, would a maintainer sponsor an
`experimental-cpb-mail` repository under `a2aproject`?

This draft is explicitly a community binding, not an official A2A artifact.

- [x] I agree to follow this project's Code of Conduct.

The issue proposes a new protocol binding. Review the draft specification at https://github.com/kotoba-lang/mail-a2a and the community binding URI. Understand the A2A v1.0 core protocol and how it maps to RFC 5322 email. The work involves design decisions and integration, not a simple code change.

Vom Indexierungsmodell aus dem Issue-Text verfasst.