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

Hi Murray,

Sending a reminder for this one from May 5th.

thanks,
Amanda

On Tue May 05 18:50:12 2026, amanda.baber wrote:
> Hi Murray,
> 
> Can you review this one by May 19th?
> 
> thanks,
> Amanda
> 
> =====
> 
> Type name: application
> 
> Subtype name: vnd.fafm+yaml
> 
> Required parameters: None
> 
> Optional parameters: version
> 
> Encoding considerations: 8bit (UTF-8). Binary content, when
> present, is base64-encoded inside YAML.
> 
> Security considerations:
> 
> The following addresses the questions outlined in the
> media-type security considerations checklist at
> https://www.iana.org/form/media-types:
> 
> 1. Active or executable content. No. The .fafm format is a YAML
>    data document. It contains no scripts, code, executable
>    directives, or active markup. Implementations MUST treat
>    .fafm content as data, never as instructions, commands, or
>    code.
> 
> 2. Privacy and integrity needs. Yes. .fafm files contain personal
>    user memory - preferences, names, conversational facts, and
>    arbitrary user-supplied content. Confidentiality and integrity
>    protection are required when these files are stored or
>    transmitted.
> 
> 3. Privacy and integrity services. The .fafm format itself does
>    not provide cryptographic confidentiality, integrity
>    protection, or signing. These services MUST be provided
>    externally:
> 
> - Confidentiality: OS-level file permissions (mode 0600 is
>   the local-default), encryption at rest in server backends,
>   and TLS for all transport.
> 
> - Integrity: filesystem permissions, transport-layer
>   integrity (TLS), and application-level write authorization.
> 
> - Future versions of the format may add cryptographic signing
>   of memory entries for provenance and audit trail.
> 
> 4. YAML format considerations. .fafm 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 .fafm:
> 
> - 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. .fafm does not use or require
>    compression at the format layer. If transport-level
>    compression (e.g., HTTP Content-Encoding: gzip) is applied to
>    .fafm 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. .fafm is a single YAML
>    document, not a container or archive format. No
>    packaging-level security considerations apply.
> 
> 7. Link references. Not applicable. .fafm content does not
>    require resolution of external links to be properly
>    interpreted. The format is fully self-contained.
> 
> Additional security considerations:
> 
> - Untrusted input / context poisoning / prompt injection. .fafm
>   files are written from voice and AI interactions and MUST be
>   treated as untrusted user input by consumers. Implementations
>   MUST NOT elevate .fafm content to "system instructions" or
>   "developer directives" within prompt hierarchies. Memory
>   entries are a documented vector for context poisoning and
>   prompt injection.
> 
> - Cross-context isolation. Implementations SHOULD scope memory
>   consumption to the originating namepoint to prevent unintended
>   cross-context influence between projects, agents, or users.
> 
> - No secrets or credentials. .fafm files MUST NOT contain
>   secrets, API keys, or credentials. Memory is intended for
>   user-facing facts and preferences only.
> 
> - Voice-command safety. Memory MUST NOT be deleted by voice
>   commands; deletion is a UI-only operation. Implementations
>   MUST expose a forget(namepoint, criteria) method supporting
>   deletion by entry ID, time range, or full wipe.
> 
> Interoperability considerations:
> 
> .fafm is the Voice Memory Layer (VML) sibling of the
> IANA-registered .faf format (application/vnd.faf+yaml). It is
> designed to interoperate with .faf while serving a distinct
> purpose:
> 
> .faf   - Foundational Context Layer  (project IS - static, read once)
> .fafm  - Voice Memory Layer (VML)    (agent REMEMBERS - mutating,
> persisted)
> 
> Two formats. Two lifecycles. One ecosystem.
> 
> .faf is read once and trusted as the project's canonical context.
> .fafm accretes over time as the agent and user interact, with
> entries appended, summarized, and selectively promoted into .faf
> when they become enduring facts.
> 
> The .fafm schema extends application/vnd.faf+yaml - a .fafm
> document remains a valid YAML file. Consumers that only
> understand .faf will safely ignore the memory block and still
> extract identity from namepoint and top-level fields. Consumers
> that understand .fafm gain access to accumulated memory.
> 
> Both formats share the same family branding, YAML philosophy
> (YAML 1.2 / RFC 9512 baseline), and MIT license. Multiple .fafm
> documents per scope are permitted, distinguished by namepoint.
> 
> Published specification: https://github.com/Wolfe-
> Jam/faf/blob/main/MEMORY-FORMAT.md
> 
> Applications that use this media type: Voice agents, LiveKit
> deployments, Grok Voice SDKs, future ElevenLabs/Hume
> integrations.
> 
> Fragment identifier considerations: None.
> 
> Additional information - File extension: .fafm
> 
> 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]