[media-types] [IANA #1452522] New Media Type Registratio n Request: application/vnd.fafa+yaml

Hi Murray,

We've received a reply to your question about "version" (with no additional text) in the optional parameter field:

===

The expert is right. The "version" that follows semantic-versioning syntax is an in-band field in the document payload - it declares which version of the .fafa specification the document conforms to, the same way the format itself is self-describing about everything else. It is not a parameter of the media type, so there is no Content-Type parameter to negotiate.

Please set:

Optional parameters: N/A

No required or optional parameters are defined for application/vnd.fafa+yaml; versioning is handled in-band via the top-level "version" field of the document.

Happy to clarify anything further.

===

Does that work?

thanks,
Amanda

On Tue Jun 02 14:55:28 2026, [email protected] wrote:
> One minor thing here.
> 
> -MSK
> 
> On Wed, May 27, 2026 at 10:37 AM Amanda Baber via RT <
> [email protected]> wrote:
> 
> > > Type name: application
> > >
> > > Subtype name: vnd.fafa+yaml
> > >
> > > Required parameters: N/A
> > >
> > > Optional parameters: version
> >
> 
> What does this value look like?  An integer, a string containing a semantic
> version, something else?
> 
> The published specification contains a "version" that follows the semantic
> versioning syntax, but that refers to the payload, not the media type
> itself.
> 
> 
> > > Encoding considerations: 8bit (UTF-8). Binary content, when
> > > present, is base64-encoded inside YAML.
> > >
> > > Security considerations:
> > >
> > > The following addresses the questions outlined in the IANA
> > > media-type security considerations checklist at
> > > https://www.iana.org/form/media-types:
> > >
> > > 1. Active or executable content. No. The .fafa format is a YAML
> > >    data document. It contains no scripts, code, executable
> > >    directives, or active markup. Implementations MUST treat
> > >    .fafa content as data, never as instructions, commands, or
> > >    code. Declaration is not authorization: an implementation
> > >    MUST NOT auto-execute a capability purely because it is
> > >    declared.
> > >
> > > 2. Privacy and integrity needs. .fafa carries agent identity
> > >    claims and capability declarations. It is not intended to
> > >    carry personal data. Integrity of the endpoints and
> > >    signature fields is required where present; confidentiality
> > >    of the declaration itself is generally not required, but
> > >    transport SHOULD be authenticated and encrypted.
> > >
> > > 3. Privacy and integrity services. The .fafa format itself does
> > >    not provide cryptographic confidentiality, integrity
> > >    protection, or signing. These services MUST be provided
> > >    externally:
> > >
> > > - Confidentiality: TLS for all transport; encryption at rest
> > >   in any backend that stores .fafa documents.
> > >
> > > - Integrity: where present, the signature field carries
> > >   provenance/integrity material, verified by the consumer;
> > >   transport-layer integrity (TLS); application-level write
> > >   authorization.
> > >
> > > - Consumers MUST treat the endpoints field as untrusted
> > >   until verified against signature if present, and MUST
> > >   apply least privilege when consuming declared
> > >   capabilities.
> > >
> > > 4. YAML format considerations. .fafa is built on YAML 1.2. All
> > >    YAML 1.2 security considerations apply, including those
> > >    described in RFC 9512 ("YAML Media Type") section 6. Specific
> > >    to .fafa:
> > >
> > > - Parsers MUST disable custom type construction (no
> > >   !!python/object, !ruby/object, or equivalent
> > >   language-specific constructors).
> > >
> > > - Parsers MUST enforce alias-expansion limits to mitigate
> > >   entity-expansion / "billion-laughs"-style attacks.
> > >
> > > - Parsers MUST enforce nesting-depth limits to prevent stack
> > >   overflow.
> > >
> > > 5. Compression. Not applicable. .fafa does not use or require
> > >    compression at the format layer. If transport-level
> > >    compression is applied to .fafa content alongside other
> > >    secret data, standard compression-with-secret considerations
> > >    (e.g., CRIME/BREACH class attacks) apply at the transport
> > >    layer.
> > >
> > > 6. Container format. Not applicable. .fafa is a single YAML
> > >    document, not a container or archive format. No
> > >    packaging-level security considerations apply.
> > >
> > > 7. Link references. .fafa documents MAY contain endpoint
> > >    locators (the endpoints field) and provenance references
> > >    (the provenance field). These are declarative pointers; a
> > >    .fafa document does not require resolving them to be
> > >    correctly interpreted. Consumers MUST treat endpoint
> > >    locators as untrusted until verified (see item 3) and MUST
> > >    NOT auto-resolve or auto-invoke them by virtue of their
> > >    presence in the document.
> > >
> > >
> > > Additional security considerations:
> > >
> > > - Untrusted input / context poisoning / prompt injection. .fafa
> > >   documents originate from agents and third parties and MUST be
> > >   treated as untrusted input by consumers. Implementations MUST
> > >   NOT elevate .fafa content to "system instructions" or
> > >   "developer directives" within prompt hierarchies. Capability
> > >   declarations are a documented vector for over-trust and
> > >   prompt injection.
> > >
> > > - Cross-context isolation. Implementations SHOULD scope
> > >   capability consumption to the declaring agent's verified
> > >   identity to prevent unintended cross-agent or cross-domain
> > >   influence.
> > >
> > > - No secrets or credentials. .fafa documents MUST NOT contain
> > >   secrets, API keys, or credentials; MUST NOT contain
> > >   user-personal data (use .fafm for memory of that kind); and
> > >   MUST NOT contain executable code. The format is declarative,
> > >   not executable.
> > >
> > >
> > > Interoperability considerations:
> > >
> > > .fafa is the Agent Card format of the FAF family, sibling to
> > > the IANA-registered .faf format (application/vnd.faf+yaml) and
> > > .fafm format (application/vnd.fafm+yaml). It is designed to
> > > interoperate while serving a distinct purpose:
> > >
> > > .faf   - Foundational Context Layer  (project IS - static, read once)
> > > .fafm  - Voice Memory Layer (VML)    (agent REMEMBERS - mutating,
> > > persisted)
> > > .fafa  - Agent Card                  (agent IS - declarative identity
> > > + capability)
> > >
> > > Three formats. Three roles. One ecosystem.
> > >
> > > .fafa is format-level, not protocol-level. It composes with -
> > > does not replace - agent-interaction protocols: a protocol
> > > carries, references, or resolves a .fafa document; the document
> > > declares the agent the protocol acts upon.
> > >
> > > The .fafa schema extends application/vnd.faf+yaml - a .fafa
> > > document remains a valid YAML file. Consumers that only
> > > understand .faf will safely ignore the agent-specific blocks
> > > and still extract identity from top-level fields. Consumers
> > > that understand .fafa gain the full agent declaration.
> > >
> > > .fafa is YAML 1.2 / RFC 9512 compliant. Consumers MUST use
> > > YAML safe-load, MUST treat unknown top-level fields and unknown
> > > subfields within agent, capabilities, and endpoints as
> > > forward-compatible extensions, and SHOULD use UTF-8 encoding.
> > >
> > > All three formats share the same family branding, YAML
> > > philosophy (YAML 1.2 / RFC 9512 baseline), and MIT license.
> > > Multiple .fafa documents per scope are permitted, distinguished
> > > by agent.id.
> > >
> > >
> > > Published specification: https://github.com/Wolfe-
> > > Jam/faf/blob/main/AGENT-FORMAT.md
> > >
> > > Applications that use this media type: faf-agent-mcp (reference
> > > implementation), xAI/Grok, claude-faf-mcp, gemini-faf-mcp and
> > > future FAF MCP-family integrations.
> > >
> > > Fragment identifier considerations: None
> > >
> > > Additional information - File extension: .fafa
> > >
> > > Person & email address for further information: James Wolfe,
> > > [email protected]
> > >
> > > Intended usage: COMMON
> > >
> > > Restrictions on usage: None
> > >
> > > Author: James Wolfe
> > >
> > > Change controller: FAF Foundation
> >
> >

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]