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

Approved after they concur with one correction, below.

-MSK

On Tue, May 12, 2026 at 12:22 PM Amanda Baber via RT <
[email protected]> wrote:

> 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
>

See RFC 6838, Section 5.6; you don't want "None" here.


> > 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]