[media-types] [IANA #1459410] application/vnd.dai registration request

[Amanda Baber via RT <[e-mail]>]

Hi Murray,

Resending this request from September 12th.

thanks,
Amanda

On Sun Sep 13 00:25:10 2026, david.dong wrote:
> Hi Murray,
> 
> Please see below for the response and updated template from the
> requester:
> 
> ===
> 
> Thank you for sending the review. My revised application is below.
> Changes to note: the BCP 14 language has been removed from Security
> and Interoperability, which now describe the format and cites the
> specification sections where the normative requirements live; the "by
> name" phrasing in Interoperability has been replaced with plain
> wording; and the "N/A" that appeared to dangle is the answer to the
> "Other Information & Comments" field, whose heading is restored below.
> 
> One substantive change to the specification followed from their first
> comment: the decompression bound was a requirement the implementations
> honored but the specification never stated. It is now a normative
> clause in §7 with a refusal code and a conformance vector, and the
> Security section cites it rather than asserting it.
> 
> 
> Application Revision:
> 
> Name: Christopher Whitlow
> Email: [e-mail]
> 
> Media type name: application
> Media subtype name: vnd.dai
> 
> Required parameters: N/A
> Optional parameters: N/A
> 
> Encoding considerations: binary
> 
> The file is a sectioned container: a header, a section table, page-
> aligned sections holding a JSON manifest, a zip archive of the
> application, and a SQLite database, and a 64-byte footer. The footer
> carries a generation counter and the SHA-256 of the database section.
> 
> Security considerations:
> 
> A DAI container carries executable content: an HTML application
> intended to run only inside a host that applies the isolation defined
> in §4 of the specification (an opaque-origin sandboxed frame under a
> Content Security Policy permitting no network connection). The
> specification requires that a host not applying that isolation does
> not execute the content.
> 
> The container is a sectioned binary file holding a JSON manifest, a
> zip archive of the application, and a SQLite database. The manifest
> carries SHA-256 digests of every archive entry and may carry an ECDSA
> P-256 signature over them in a COSE_Sign1 envelope. The specification
> requires a host to verify every digest before running anything and to
> verify the signature when a key is present (§7). The signature covers
> the manifest and the application, not the database; the database
> section is verified separately against a SHA-256 digest held in the
> file's footer (§2). Verification establishes that the file is
> unchanged since it was signed, not the identity of the signer; §8 and
> §9.6 describe what a host may claim about a publisher.
> 
> Because the archive is inflated before its manifest can be checked,
> the specification requires a reader to bound decompression in advance
> — a limit on the bytes produced for any one entry, on the total across
> entries, and on the number of entries — refusing rather than
> allocating when a declared size, the declared total, or the entry
> count exceeds that limit, and stopping if an entry inflates past the
> size it declares (§7). The manifest contains no active content.
> 
> The application may read and write the SQLite database. The format
> grants it no capability to reach the network, the filesystem beyond
> the file itself, or other origins.
> 
> Privacy: the file may contain personal data the application stored. It
> contains no tracking, and the specification requires that a host send
> nothing when opening a file.
> 
> Interoperability considerations:
> 
> The format is versioned by the manifestVersion field in the manifest.
> A reader accepts the versions it implements and refuses others,
> reporting a refusal that tells the person to update the host (§9.1).
> The specification defines versions 2 and 3. A conformance suite and an
> independent reference reader in Python are published with the
> specification.
> 
> Published specification: DAI Container Format v0.2, §2 (the sectioned
> form), §7 (verification), and §9 (manifestVersion 3):
> https://github.com/dynamicapplicationinterface/dai-
> core/blob/main/docs/spec-v0.2.md
> 
> Applications which use this media: The DAI opener
> (https://opendai.app) the DAI desktop application, and the dai
> command line tool; any host implementing the specification.
> 
> Fragment identifier considerations: N/A
> Restrictions on usage: N/A
> Provisional registration? (standards tree only): No
> 
> Additional information:
> 
> Deprecated alias names for this type: N/A
> Magic number(s): the first four bytes are DAI (0x44 0x41 0x49 0x00)
> File extension(s): '.dai'
> Macintosh file type code: N/A
> Object Identifiers: N/A
> 
> Other Information & Comments: N/A
> 
> Person to contact for further information:
> 
> Name: Christopher Whitlow
> Email: [e-mail]
> 
> Intended usage: COMMON
> 
> Author/Change controller: Christopher Whitlow / Dynamic Application
> Interface Opensource Project
> 
> ===
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Wed Sep 09 19:54:13 2026, [e-mail] wrote:
> > A couple of minor things.
> >
> > -MSK
> >
> > On Tue, Sep 8, 2026 at 6:25 PM David Dong via RT
> > <[e-mail]> wrote:
> > > Name: Christopher Whitlow
> > >
> > > Email: [e-mail]
> > >
> > > Media type name: application
> > >
> > > Media subtype name: vnd.dai
> > >
> > > Required parameters: N/A
> > >
> > > Optional parameters: N/A
> > >
> > > Encoding considerations: binary
> > >
> > > The file is a sectioned container: a header, a section table, page-
> > > aligned sections holding a JSON manifest, a zip archive of the
> > > application, and a SQLite database, and a 64-byte footer. The
> > > footer
> > > carries a generation counter and the SHA-256 of the database
> > > section.
> > >
> > > Security considerations: A DAI container carries executable
> > > content:
> > > an HTML application intended to run only inside a host that applies
> > > the isolation defined in §4 of the specification, namely an opaque-
> > > origin sandboxed frame under a Content Security Policy that permits
> > > no network connection of any kind. A host that does not apply that
> > > isolation MUST NOT execute the content.
> > >
> > > The container is a sectioned binary file holding a JSON manifest, a
> > > zip archive of the application, and a SQLite database. The manifest
> > > carries SHA-256 digests of every archive entry and MAY carry an
> > > ECDSA
> > > P-256 signature over them in a COSE_Sign1 envelope. A host MUST
> > > verify every digest before running anything and MUST verify the
> > > signature when a key is present. The signature covers the manifest
> > > and the application, not the database; the database section is
> > > verified separately against a SHA-256 digest held in the file's
> > > footer, and a host MUST check it. Verification proves the file is
> > > unchanged since it was signed, not who signed it. §8 and §9.6 of
> > > the
> > > specification describe what a host may and may not claim about a
> > > publisher.
> >
> > BCP 14 language isn't appropriate in the registration template.
> > Normative stuff (security or otherwise) should be in the
> > specification.
> >
> > > Because the archive must be inflated before its manifest can be
> > > checked, a reader MUST bound decompression by the declared size of
> > > each entry, the declared total, and the entry count, and MUST
> > > refuse
> > > a file that exceeds those bounds rather than allocate for it. The
> > > manifest contains no active content.
> > >
> > > The application may read and write the SQLite database. The format
> > > grants it no capability to reach the network, the filesystem beyond
> > > the file itself, or other origins.
> > >
> > > Privacy: the file may contain personal data the application stored.
> > > It contains no tracking, and the specification requires that a host
> > > send nothing on open.
> > >
> > > Interoperability considerations: The format is versioned by
> > > `manifestVersion` in the manifest. Readers accept versions 2 and 3
> > > and refuse others by name. A conformance suite and an independent
> > > reference reader in Python are published with the specification.
> >
> > What does "by name" mean here?
> >
> > > Published specification: DAI Container Format v0.2, §2 (the
> > > sectioned
> > > form) and §9 (manifestVersion 3):
> > > <https://github.com/dynamicapplicationinterface/dai-
> > > core/blob/main/docs/spec-v0.2.md>
> > >
> > > Applications which use this media: The DAI opener
> > > (<https://opendai.app>), the DAI desktop application, and the `dai`
> > > command line tool; any host implementing the specification.
> > >
> > > Fragment identifier considerations: N/A
> > >
> > > Restrictions on usage: N/A
> > >
> > > Provisional registration? (standards tree only): No
> > >
> > > Additional information:
> > >
> > > 1. Deprecated alias names for this type: N/A
> > > 2. Magic number(s): the first four bytes are `DAI` (0x44 0x41 0x49
> > > 0x00)
> > > 3. File extension(s): '.dai'
> > > 4. Macintosh file type code: N/A
> > > 5. Object Identifiers: N/A
> > >
> > > General Comments: N/A
> > >
> > > Person to contact for further information:
> > >
> > > 1. Name: Christopher Whitlow
> > > 2. Email: [e-mail]
> > >
> > > Intended usage: COMMON
> > >
> > > N/A
> >
> > What's this dangling "N/A" for?
> >
> > > Author/Change controller: Christopher Whitlow / Dynamic Application
> > > Interface Opensource Project