MAP uses existing standards for email, authentication, data representation and HTTP. The following references identify their role and the additional requirements MAP imposes. The Internet-Draft lists the normative dependencies.
The Structured Email working group's charter covers the message container and trust guidance but leaves recipient use of extracted data and domain-specific vocabularies outside its current scope. MAP's decisions therefore need their own specification and venue; using the SML container does not make MAP an SML working-group item.
| Source | Use and boundary |
|---|---|
| Structured Email -06 | Sections 4.1-4.3 define designation and placement. Section 5.1 requires stripping non-representative data on manual forwarding; MAP deliberately imposes its own stronger copy rule. Section 5.3 requires SUPERSEDES for updates. Section 5.2 discusses future structured replies, not a reserved MAP execution slot. |
| SML trust -01 | Work-in-progress guidance on the risks of structured display, automation, external references and social engineering. Its trust categories do not authorize a MAP decision. MAP requires a configured connection and an authenticated current-state read for credentialed action; that read is not a fetch of a resource named by arbitrary email content. |
| DKIM, RFC 6376, RFC 8301, RFC 8463 | Signature/body/header rules and current algorithm requirements. MAP adds required coverage and excludes every l= signature; it does not claim these are general DKIM delivery rules. |
| DMARC, RFC 9989 | Strict/relaxed alignment and Organizational Domain discovery. No last-two-label shortcut or assumption that a tenant equals a domain. |
| Authentication-Results, RFC 8601 | Configured receiving trust boundaries. A passing result is insufficient by itself to prove MAP-specific signature coverage or unchanged machine content. |
| HTTP, RFC 9110 | Safe methods, selected representations, strong If-Match, 412, 202, and ordinary HTTP semantics. The service can instead use its existing atomic expected-version argument. |
| Problem Details, RFC 9457 | Optional reuse; no mandatory MAP problem envelope or six new registered problem types. |
| RFC 8707, RFC 9700 | Resource-specific token audience protections; the email never selects a credential destination. |
| One-click unsubscribe, RFC 8058 | Fixed request and scanner lessons. The MAP capability binding is a separate experiment, not unsubscribe interoperability. |
| NIST SP 800-63A-4, section 3.8 | Email confirmation codes expire within 24 hours and are invalidated on use in that publication's scope. MAP adopts those bounds; it does not equate address validation with authentication. |
| RFC 7493, RFC 8785 | I-JSON and deterministic canonical contract hashing. MAP adds explicit size/depth/numeric limits. |
| JSON Schema 2020-12, JSON-LD 1.1 | Draft companion schemas and fixed offline context. Schema validation never proves authority or temporal consistency. |
| Unicode UTS #39 | Display spoofing defenses; no blanket normalization of opaque service tokens or email local parts. |
Service interfaces and discovery
The research catalogue records the wider comparison, primary sources, publication status and design assessment for each interface. It distinguishes execution protocols, descriptions, delivery, identity and established workflows. Research coverage is not a claim of MAP interoperability.
- OpenAPI 3.1.2 describes the illustrative native HTTP API.
- Arazzo 1.1.0, AsyncAPI 3.0 and WoT Thing Description 1.1 are prior art for reusable binding descriptions. No new general mapping language is specified here.
- OAuth Protected Resource Metadata, RFC 9728 can support explicit setup for an independently selected resource.
- MCP tools supply the native calls and structured results used in the illustrative walkthrough. MCP Tasks is a separately negotiated extension. Neither is a normative MAP MCP binding.
- The proposed Agent Communication Protocols charter, revision 00-04 addresses correlation and lifecycle of agentic dialogs across protocols. It explicitly excludes agent decision-making semantics and client UX. MAP defines the meaning and authorization conditions of a service action described in email, not dialog-context propagation. A future binding can carry any relevant dialog context without making it a MAP requirement.
- The proposed Discovery of Agents With Names charter, revision 00-08 addresses initial discovery of public AI-resource properties. It excludes capability catalogues, subsequent communication and identity management in its initial scope. MAP's configured type and service catalogues do not become a global agent-discovery system. Both charters are proposals as of 4 October 2026, not adopted specifications or assigned venues for MAP.