MailSchema
Search/Read MAP
MAP · Design research

Work with what exists.

APIs, tools, agents and messaging systems can carry a decision. The question is what each already provides, and what a MAP binding still needs to establish.

How this shapes MAP Download the research
43 entries · 7 groups · 47 primary sources

Capabilities below are drawn from the linked specifications and project documentation. Possible uses and remaining requirements are design assessments. No entry claims a tested MAP implementation.

43 entries

Service APIs

HTTP APIsRFC 9110Binding candidate
Already provides
HTTP supplies methods, status codes, conditional requests and authentication conventions.
Possible MAP use
Use the existing read and decision endpoints. OpenAPI can identify their schemas and operation IDs.
Still needs
If-Match must govern the actual approved representation; 202 is acceptance, and a lost response is indeterminate.
Primary sources1. rfc-editor.org2. spec.openapis.org
GraphQLSeptember 2025 specificationBinding candidate
Already provides
Queries, mutations and subscriptions operate on a typed schema. Results can include both data and errors.
Possible MAP use
Read the proposal with an installed query; call the service’s mutation with its expected-version argument.
Still needs
Serial root mutation execution is not an atomic business transaction. Interpret domain state and partial errors.
Primary sourcesspec.graphql.org
gRPCgRPC documentationBinding candidate
Already provides
RPCs return status codes; a deadline can expire even after a state-changing operation succeeds.
Possible MAP use
Select installed service and method descriptors. Map native request fields and result messages to the contract.
Still needs
The service must enforce expected revision and principal authority. A deadline does not establish failure before execution.
Primary sourcesgrpc.io
JSON-RPC2.0 specificationBinding candidate
Already provides
Transport-independent calls carry a method, parameters and correlation ID. Notifications receive no response.
Possible MAP use
Use a service read call and decision call over the already authorized connection; retain native result/error objects.
Still needs
A request ID is correlation, not an idempotency guarantee. Notifications alone cannot prove a consequential decision.
Primary sources1. jsonrpc.org2. spec.open-rpc.org
SOAP / WSDLSOAP 1.2; WSDL 2.0Binding candidate
Already provides
SOAP has a protocol-binding framework and faults; WSDL describes interfaces, operations and bindings.
Possible MAP use
Use the installed WSDL operation and existing service security. Map the proposal revision into its native message.
Still needs
SOAP success and reliable delivery do not establish contract effects. Service-specific version checks and fault meanings remain necessary.
Primary sources1. w3.org2. w3.org
OData4.01 OASIS StandardBinding candidate
Already provides
OData defines actions and conditional action requests, including native ETag checks and concurrency failures.
Possible MAP use
Bind the contract to a documented resource-bound action and the resource state it actually covers.
Still needs
OData permits weak ETag comparison in its own conditional semantics. Do not mislabel that as RFC 9110 strong comparison.
Primary sourcesdocs.oasis-open.org
CoAPRFC 7252Specialist candidate
Already provides
CoAP provides constrained resource operations, ETags, If-Match and request/response exchanges.
Possible MAP use
An installed constrained-service binding can map the decision to the native resource and its precondition.
Still needs
CoAP tokens, acknowledgements and retransmission rules are not business-decision deduplication. Account authorization and secure transport need an explicit profile.
Primary sourcesrfc-editor.org
SDKs and local toolsHost-specific interfaces; POSIX execution modelBinding candidate
Already provides
A host can invoke an installed library or executable. This is an implementation choice, not a common network protocol.
Possible MAP use
Map contract operations through a reviewed host adapter, fixed executable identity and structured arguments.
Still needs
Do not execute email-supplied commands. The adapter still needs authoritative service state and atomic enforcement; an exit code alone is insufficient.
Primary sourcespubs.opengroup.org

Agent protocols

Model Context Protocol2026-07-28; Tasks extension separately versionedBinding candidate
Already provides
MCP describes tools, calls and structured results over standard or custom bindings; Tasks is a separate extension.
Possible MAP use
Use installed tool mappings and the server’s existing authorization. Reuse native task support when negotiated.
Still needs
Tool annotations are hints. Successful calls and completed protocol tasks require interpretation against the contract’s actual effect.
Primary sources1. modelcontextprotocol.io2. modelcontextprotocol.io3. tasks.extensions.modelcontextprotocol.io
Agent2AgentCurrent project specificationBinding candidate
Already provides
A2A defines agent cards, structured messages, tasks, extensions and multiple protocol bindings.
Possible MAP use
Map a typed decision through an explicitly supported service extension; preserve native task and result handling.
Still needs
SendMessage idempotency is optional. Agent discovery, task completion and downstream delegation do not automatically prove exact-terms execution.
Primary sourcesa2a-protocol.org

Messaging

AMQP1.0 OASIS StandardBinding candidate
Already provides
AMQP supplies message transfer, delivery states, settlement and message properties.
Possible MAP use
Use a trusted request/reply route and service decision record, retaining native correlation and delivery semantics.
Still needs
Identify which receiver accepted the message. A broker’s accepted disposition is not proof that an application committed the effect.
Primary sourcesdocs.oasis-open.org
MQTT5.0 OASIS StandardBinding candidate
Already provides
MQTT defines publish/subscribe delivery, QoS, Response Topic and Correlation Data for request/reply patterns.
Possible MAP use
Use installed command and response topics, with authorization for each topic and a service-side decision check.
Still needs
QoS describes message delivery, not an atomic application effect. Prevent retained or replayed commands from causing new decisions.
Primary sourcesdocs.oasis-open.org
Core NATSProject documentationBinding candidate
Already provides
Core NATS supplies ephemeral at-most-once messaging and request/reply using reply subjects.
Possible MAP use
Map read and decision requests to authorized subjects; authenticate the service response and retain native correlation.
Still needs
A timeout can mean no response, not no effect. Subject access alone must not substitute for the acting principal’s permission.
Primary sourcesdocs.nats.io
NATS JetStreamProject documentationBinding candidate
Already provides
JetStream adds persisted streams and per-consumer delivery tracking with acknowledgements.
Possible MAP use
Use durable command delivery where needed and a separate correlated application result.
Still needs
Acknowledging consumption does not prove the business transaction. Couple decision deduplication to the service’s actual commit.
Primary sourcesdocs.nats.io
Apache Kafka4.1 design documentationBinding candidate
Already provides
Kafka provides durable logs and transaction mechanisms; coordinating effects in external systems remains a separate concern.
Possible MAP use
Use installed command/result topics and a service decision ledger or equivalent atomic storage mechanism.
Still needs
Broker transactions do not automatically cover publishing an article or sending mail. Preserve account authority through consumers and retries.
Primary sourceskafka.apache.org
WebhooksStandard Webhooks project specificationBinding candidate
Already provides
Standard Webhooks defines signed payload and delivery metadata, including an identifier and attempt timestamp.
Possible MAP use
Reuse an existing authenticated webhook for decisions or results when its API defines that role.
Still needs
A callback must be installed and authorized independently of email. Signature freshness does not prove current terms or grant permission.
Primary sourcesraw.githubusercontent.com
WebSubW3C RecommendationReuse supporting layer
Already provides
WebSub defines publisher, hub and subscriber relationships for delivering updates.
Possible MAP use
Reuse it for authenticated update notification followed by the service’s trusted state read.
Still needs
Subscription verification and notification delivery do not define a command, exact-terms decision or completed effect.
Primary sourcesw3.org

Streams and federation

WebSocketRFC 6455Reuse supporting layer
Already provides
WebSocket provides a bidirectional message channel and subprotocol negotiation.
Possible MAP use
Carry an existing RPC or command protocol over the authorized connection.
Still needs
A WebSocket connection has no built-in MAP read, decision or outcome meaning. The application subprotocol must supply those.
Primary sourcesrfc-editor.org
Server-sent eventsWHATWG HTML standardReuse supporting layer
Already provides
SSE delivers server-to-client event streams and supports reconnection with event identifiers.
Possible MAP use
Use an installed service stream for progress or authenticated result updates.
Still needs
It is not the client’s decision-submission path. Replayed event IDs and disconnected streams must not manufacture completion.
Primary sourceshtml.spec.whatwg.org
WebRTC data channelsRFC 8831Specialist candidate
Already provides
WebRTC data channels carry application data over SCTP with channel-specific ordering and reliability choices.
Possible MAP use
A peer-service integration could carry an existing command protocol over an authenticated channel.
Still needs
Signaling, peer identity, recipient authority, correlation and recovery must be specified. Channel delivery does not mean the action committed.
Primary sourcesrfc-editor.org
WebTransportW3C Candidate Recommendation Snapshot, July 2026Specialist candidate
Already provides
WebTransport exposes streams and datagrams for application communication.
Possible MAP use
Reuse a deployment’s application protocol over its established session rather than defining a MAP stream format.
Still needs
Streams and datagrams do not supply contract semantics, principal delegation or an atomic expected-version check.
Primary sourcesw3.org
HTTP/2, HTTP/3 and QUICHTTP/3 RFC 9114; underlying protocol familyReuse supporting layer
Already provides
HTTP/3 carries HTTP semantics over QUIC. Transport evolution is separate from the API’s application semantics.
Possible MAP use
Keep the HTTP service binding independent of the HTTP wire version.
Still needs
A different connection or multiplexing mechanism is not another action contract or evidence of safe retry.
Primary sources1. rfc-editor.org2. rfc-editor.org
XMPPRFC 6120Specialist candidate
Already provides
XMPP includes authenticated XML streams and an IQ request/response mechanism.
Possible MAP use
An installed service namespace could carry reads and decisions with correlated IQ responses.
Still needs
Map JIDs and delegated identities to the service principal. An IQ result still needs domain-specific exact-terms and outcome semantics.
Primary sourcesrfc-editor.org
ActivityPubW3C RecommendationSpecialist candidate
Already provides
ActivityPub defines actor inboxes, outboxes and activity delivery for social applications.
Possible MAP use
Reuse existing social activity semantics where they match the desired operation.
Still needs
Delivery or acceptance of an activity is not generic business approval. A bespoke publishing workflow still needs a documented service binding.
Primary sourcesw3.org

Descriptions and discovery

OpenAPI3.1.2 examinedReuse before inventing
Already provides
OpenAPI describes HTTP operations, security requirements, schemas and links to related operations.
Possible MAP use
Reuse operation identifiers and native API definitions as binding inputs.
Still needs
Links do not guarantee permission. OpenAPI alone does not define MAP effects or prove a service’s atomic version check.
Primary sourcesspec.openapis.org
OpenRPCProject specificationReuse before inventing
Already provides
OpenRPC describes JSON-RPC methods and supplies an optional rpc.discover discovery method.
Possible MAP use
Reference trusted method descriptions and their parameters rather than defining another RPC descriptor.
Still needs
Discovery does not install a binding or authorize execution. Outcome and exact-terms semantics remain service-specific.
Primary sourcesspec.open-rpc.org
AsyncAPI3.0.0Reuse before inventing
Already provides
AsyncAPI describes servers, channels, operations, security, messages and request/reply relationships with protocol bindings.
Possible MAP use
Reuse its native channel and message descriptions for queue and event-driven service integrations.
Still needs
A reply relationship does not prove business acceptance. Pin trusted configuration and define the service’s decision/result semantics.
Primary sourcesasyncapi.com
Arazzo1.1.0Reuse before inventing
Already provides
Arazzo describes API workflows with operation references, runtime values, payload replacements and success criteria.
Possible MAP use
Evaluate its existing mappings before standardizing the custom x-map selector language.
Still needs
A workflow runner must stop for host policy and confirmation before the decision. Success criteria cannot prove unimplemented atomic enforcement.
Primary sourcesspec.openapis.org
WoT Thing Description1.1 W3C RecommendationReuse before inventing
Already provides
Thing Descriptions provide action affordances, forms, input/output descriptions and security metadata across protocol bindings.
Possible MAP use
Compare a MAP semantic profile over existing affordances with a new binding-description format.
Still needs
Do not equate invokeaction with informed approval. Recipient relationship, exact terms and business effects still need explicit service guarantees.
Primary sourcesw3.org
CloudEvents1.0.2Reuse supporting layer
Already provides
CloudEvents standardizes event context and its representation across formats and protocol bindings.
Possible MAP use
Use it around existing service notifications or result events when the service already does so.
Still needs
An event envelope does not define a command contract, authority, atomic commit or exactly-once application behaviour.
Primary sourcesraw.githubusercontent.com
Schema.org ActionsSchema.org vocabularyReuse supporting layer
Already provides
Schema.org describes actions, their participants, results and potential actions.
Possible MAP use
Reuse suitable vocabulary or documented mappings where its meaning agrees with a MAP type.
Still needs
A potentialAction or target URL is descriptive metadata, not a permission grant or executable request template.
Primary sourcesschema.org

Email and human interfaces

SMTP and MIMERFC 5321; Structured Email containerReuse supporting layer
Already provides
SMTP delivers mail; MIME carries readable and structured message parts.
Possible MAP use
Keep email delivery as MAP’s proposal channel, independent of the service execution interface.
Still needs
Mail acceptance and a delivered reply do not prove execution. A generic reply-command binding would need its own trust and result rules.
Primary sources1. rfc-editor.org2. ietf.org
IMAPRFC 9051Reuse supporting layer
Already provides
IMAP accesses and manages mailbox messages; it does not specify mail submission.
Possible MAP use
Use an existing mail client or provider integration to obtain the message and trusted delivery context.
Still needs
Mailbox access does not establish permission to act in the external service.
Primary sourcesrfc-editor.org
JMAPRFC 8620Binding candidate
Already provides
JMAP defines account-scoped method calls, capabilities and state preconditions such as ifInState.
Possible MAP use
Reuse JMAP mailbox access or a separately defined domain capability when its actual semantics fit.
Still needs
Mailbox state is not the version of an external publication or campaign. Core JMAP is not a universal action API.
Primary sourcesrfc-editor.org
Structured EmailIETF working-group draft -06Reuse before inventing
Already provides
Structured Email specifies structured MIME content and defers details of structured replies to future work.
Possible MAP use
Reuse its container for the proposal and coordinate MAP’s specific action requirements with SML.
Still needs
A shared MIME container neither standardizes execution nor reserves the entire action problem for MAP.
Primary sourcesietf.org
iTIP / iMIPRFC 5546 and RFC 6047Reuse existing workflow
Already provides
iTIP defines calendaring scheduling exchanges; iMIP binds them to MIME email.
Possible MAP use
Use calendar-native requests and replies for attendance and scheduling semantics they already define.
Still needs
Do not recreate an RSVP protocol as a generic MAP type. A broader workflow must preserve organizer, attendee and revision semantics.
Primary sources1. rfc-editor.org2. rfc-editor.org
One-click unsubscribeRFC 8058Reuse existing workflow
Already provides
RFC 8058 defines an authenticated email signal and a fixed one-click unsubscribe POST.
Possible MAP use
Use it directly for list unsubscribe. Keep MAP’s experimental capability actions explicitly separate.
Still needs
It is not a general bearer approval protocol and does not authorize consequential actions.
Primary sourcesrfc-editor.org

Identity and authorization

OAuthRFC 9700 security BCPReuse supporting layer
Already provides
OAuth deployments have established authorization flows and security requirements for clients, tokens and resources.
Possible MAP use
Use the service’s existing scoped connection and resource protections.
Still needs
Possession of a token is not confirmation of a particular proposal. Keep credentials outside email and model-generated arguments.
Primary sourcesrfc-editor.org
OAuth resource metadataRFC 9728Reuse supporting layer
Already provides
Protected Resource Metadata advertises authorization configuration for an OAuth resource.
Possible MAP use
Use it during explicit setup for a service independently selected by the host.
Still needs
Metadata is not proof of MAP support, publisher trust, recipient authority or consent to the waiting action.
Primary sourcesrfc-editor.org
OpenID ConnectCore 1.0, errata set 2Reuse supporting layer
Already provides
OIDC supplies authentication and identity claims on top of OAuth 2.0.
Possible MAP use
Accept an already trusted provider’s identity through the service’s existing sign-in flow.
Still needs
Authentication identifies a subject; it does not authorize every action that subject’s email describes.
Primary sourcesopenid.net
OAuth Rich Authorization RequestsRFC 9396Reuse supporting layer
Already provides
RAR carries structured authorization_details, with reusable fields for API-defined authorization types.
Possible MAP use
Reuse it when a service needs fine-grained authorization requests rather than inventing a MAP permission language.
Still needs
An authorization_details object needs agreed semantics and enforcement. It does not itself bind an approval to current service terms.
Primary sourcesrfc-editor.org
GNAPRFC 9635Reuse supporting layer
Already provides
GNAP specifies grant negotiation, access tokens and interaction with a resource owner.
Possible MAP use
Allow a service’s established GNAP authorization through its trusted binding.
Still needs
Grant negotiation must remain separate from the email’s proposal. MAP need not require migration from OAuth or introduce its own grant system.
Primary sourcesrfc-editor.org
HTTP Message SignaturesRFC 9421Reuse supporting layer
Already provides
HTTP signatures cover selected message components and can carry creation time, expiry and nonce metadata.
Possible MAP use
Reuse them for request or callback authentication where the native service already defines the signature profile.
Still needs
A valid signature proves neither authorization nor a completed effect. Coverage, freshness, key trust and replay handling require a profile.
Primary sourcesrfc-editor.org
The architectural consequence

Reuse the description.
Keep the decision precise.

MAP connects a specific type contract to an operation the service already provides. The surrounding APIs, tools and identity systems already exist. This draft does not invent one mapping format for every service.

OpenAPI / OpenRPC / native schemas

Operation identities, inputs, outputs and protocol-specific descriptions.

The MAP gap: Associate an exact MAP contract with native operations and document authorization, revision and outcome semantics.

Use as the service-description source; do not duplicate its schema.

openapiopenrpc

AsyncAPI

Channels, messages, security, protocol bindings and request/reply.

The MAP gap: Define which application result establishes the decision, its principal and the atomic commit.

Use for messaging integrations; no MAP queue envelope.

asyncapi

Arazzo

API workflow steps, operation references, runtime values and success criteria.

The MAP gap: Keep host policy and confirmation outside automatic step advancement; establish the service’s actual enforcement.

Reuse for suitable API workflows. Do not make a workflow engine a Core requirement.

arazzo

WoT Thing Description

Cross-protocol action affordances, forms, input/output and security descriptions.

The MAP gap: A MAP profile would still need recipient, principal, exact-contract and exact-terms semantics.

Strong cross-protocol prior art; evaluate a profile when a real integration needs this shape.

wot

A2A tasks / MCP Tasks

Native representations for longer-running work and its state.

The MAP gap: Establish how task results prove the contract’s effect; preserve approval and authority across delegation.

Reuse when the service supports them; no generic MAP job API.

a2amcp-tasks

Still to establish in implementations

  • Whether a small semantic annotation over OpenAPI/Arazzo, AsyncAPI, OpenRPC or WoT is sufficient for reusable MAP bindings; no universal format is selected.
  • Which real services can demonstrate atomic principal, permission, expiry and terms enforcement across the different interface families.
  • How a delegated or brokered integration proves the original acting principal at the service decision, rather than only a worker or broker identity.
  • How a non-HTTP service identity is explicitly associated with Core’s current HTTPS-origin identifier; this survey does not change Core’s identity syntax.
  • Which provider action renderers can preserve the contract and recipient checks end to end; their presence is not a MAP compatibility claim.

Common service interfaces, descriptions, discovery, delivery, identity and established email workflows relevant to MAP. This catalogue does not enumerate every protocol or vendor SDK. The source catalogue records retrieval URLs, times and byte hashes for the evidence.