(registered 2026-09-16, last updated 2026-09-16) Media type name: application Media subtype name: vnd.excelano.slipcase+zip Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: A slipcase container is a ZIP archive, so the security considerations of "application/zip" apply to it in full. RFC 6839 notes that a media type registered with a +zip suffix may have additional ones. The following are additional. Identifying a container is a parse of untrusted input. A consumer cannot know whether a file is a container without locating the archive's central directory, decompressing the member named "slipcase.metadata.toml", and parsing it as TOML, and it must do all of that before anything about the file has been established. This is not the position of a general ZIP consumer, which chooses what to extract and may decline. Deflate returns a little over a thousand bytes for every byte it is given, before whatever the TOML parser then spends, and a consumer invoked automatically (a scanner, an indexer, a shell extension asked for a preview) is invoked on whatever happens to be present. The specification therefore requires an implementation to bound the decompressed size of the metadata member, and the depth to which it parses that member, and to report a container exceeding either bound as undetermined rather than as non-conformant. The size the central directory records for a member is not that bound. Nothing checks that figure against what the member inflates to, and mainstream ZIP implementations do not enforce it, so a directory entry declaring a hundred bytes may still yield two hundred megabytes. The bound has to be applied to the bytes as they arrive. The payload is arbitrary. The format constrains neither its type nor its content nor its length, so the security considerations of whatever the payload turns out to be apply to the payload, and a container is a transport for them. A consumer that hands a payload to a system handler is invoking that handler on content that arrived from elsewhere, and should treat it with whatever care its platform's rules for downloaded content require. Two practices follow from that and are not requirements of this specification, which takes no position on what a consumer does with a payload once it has one. Where the host platform records that a file arrived from elsewhere, an implementation that extracts a payload can put the same record on the copy, so that the platform's own handling of downloaded content reaches the payload rather than stopping at the container. And where a consumer reports what it found rather than deciding for the user, what it reports should come from the container: the specification's requirement that an extracted payload not receive the archive's permission bits means a payload stored executable does not extract executable, which is a fact a consumer can state without guessing at the payload's type from its name. The metadata is unauthenticated. This version of the format defines no signature, attestation, checksum, or fixity mechanism. Nothing inside a container establishes who wrote it, or that its metadata describes its payload, and a consumer must not present the metadata as though something had. The payload's name cannot express a path. "payload.file" is required to be a plain filename: non-empty, not "." or "..", not equal to the metadata member's name, and containing no solidus, reverse solidus, colon, C0 character, or DEL. An implementation is required to reject a container violating this rather than to sanitize the name, so that a container cannot direct a write outside the directory its caller chose. An implementation is separately required to create an extracted payload with the permissions a newly created file would ordinarily receive, and never to apply permission bits recorded in the archive, so that a container cannot make the file it extracts executable. A member name is attacker-controlled text that a person reads in order to decide whether to open something. The specification requires the Unicode bidirectional formatting characters (U+061C, U+200E-U+200F, U+202A-U+202E, U+2066-U+2069) to be displayed in an escaped form rather than applied, so that a name cannot be arranged to read as an extension it does not have. Undetermined can be arranged. The format defines no encryption of its own and forbids none, so a container whose metadata member is encrypted can be established neither as conformant nor as non-conformant. A program treating that verdict as a reason to skip the file can be made to skip on purpose, while the payload sits in the same archive unencrypted and legible to anything that never consulted the metadata. Undetermined is a reason to look further rather than a reason to stop. Nesting is not bounded. A payload may itself be a container, the arrangement carries no defined meaning, and nothing in the specification limits how deep it may go. An implementation that follows a payload into another container needs a depth limit of its own. Interoperability considerations: A container is an ordinary ZIP archive, so a consumer that has never heard of the format can open one with any ZIP tool and recover both members. The relationship holds in one direction only. An archive preceded by other data, such as a self-extracting stub, and a file holding one archive after another, are both readable by many ZIP implementations and both excluded by the format, which requires the end of central directory record to end the file and its recorded offsets to be taken from the start of it. Member names are decoded before they are compared, as UTF-8 where general purpose bit 11 is set and as CP437 otherwise, and are then compared exactly over code points, case-sensitively and with no Unicode normalization applied to either side. An implementation applying a different rule can fail to find a payload that another implementation finds. The format defines no canonical TOML serialization, because TOML defines none. Two writers given the same metadata need not produce identical bytes, so comparing bytes is not a test of equivalence. The value of "slipcase_version" implies no compatibility at any level, including between values differing only in their minor component. An implementation written against one version cannot assume it can read a container declaring a higher one. A conformance corpus accompanies the specification, at . It gives an implementer a set of containers with recorded verdicts to check against. Published specification: slipcase - Specification, version 1.0, final. Dedicated to the public domain under CC0 1.0, so it may be implemented, quoted, or embedded by anyone. Applications which use this media: Slipcase, a desktop application for Linux, macOS, and Windows that opens a container, presents its metadata as an editable tree, and hands the payload to the system handler registered for it. slpc, a Rust library that reads and writes containers. The list is not exhaustive. Fragment identifier considerations: As specified for the +zip structured syntax suffix in RFC 6839. No fragment identifier syntax is defined for "application/zip", and this specification defines none of its own for this type. Restrictions on usage: N/A Additional information: 1. Deprecated alias names for this type: application/x.slipcase+zip, provisional in the unregistered x. tree of RFC 6838 section 3.4. It is what the specification and the released implementations named before this registration, and it is kept as an alias so that installations predating the registration continue to resolve. 2. Magic number(s): None. The specification reserves no magic bytes and defines no identification by content. A container begins with the bytes any ZIP archive begins with, and is identified by opening the archive and finding a conformant metadata member. 3. File extension(s): slpc 4. Macintosh file type code: N/A. The Uniform Type Identifier is com.excelano.slipcase, which conforms to public.zip-archive and public.data. 5. Object Identifiers: N/A General Comments: The extension and the media type both live outside the container and neither appears inside one. This is deliberate: a container carries no member recording its own type, and a reader establishes what it is holding by reading the metadata member rather than by trusting a name. Person to contact for further information: 1. Name: David M. Anderson 2. Email: hello&excelano.com Intended usage: COMMON Author/Change controller: Excelano LLC