The format
File structure
The roots of an IDOP package, path rules, limits and deterministic packing.
Roots
Every entry name starts with one of these roots. Anything else is refused (IDOP-PATH-010).
| Root | Contains | Executable |
|---|---|---|
mimetype |
application/vnd.idop+zip, stored, first |
no |
idop.json |
the manifest | no |
code/** |
.html, .js, .mjs, .css, .json |
yes |
resources/** |
images, fonts, data | no |
storage/** |
saved state, written by the reader | no |
_idop/** |
reserved for the specification | no |
extensions/<namespace>/** |
extension data | no |
Path rules
Entry names are UTF-8 in Unicode NFC, separated by /, with no empty segments, no . or .., no backslashes, no Windows device names (CON, NUL, …), and no two names that collide when compared case-insensitively. There are no directory entries; directories exist only as prefixes.
ZIP profile
- No bytes before the first local header or after the end-of-central-directory record.
- No ZIP64, spanning or encryption.
- Store or Deflate only.
- Local headers and the central directory must agree on every entry.
- The first entry is
mimetype, stored, with no extra field.
Limits
Readers enforce limits on the compressed file size, the number of entries, each entry’s uncompressed size, the total uncompressed size, and the compression ratio of each entry. Exceeding one refuses the file with an IDOP-LIMIT-… code. The exact values are in §6 of the specification.
Deterministic packing
Producers should write mimetype first, idop.json second, then the remaining entries in byte-wise order of their names, with fixed timestamps and permissions — so the same inputs produce byte-identical files. idop pack does this.