[media-types] [IANA #1449148] application/vnd.digitals tack.document+zip registration request
"Amanda Baber via RT" <[email protected]> Mon, 11 May 2026 19:36:58 +0000
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <[email protected]> |
Hi Darrel, They've made the update in the spec: https://www.digitalstack360.com/specs/dstack-document-package/v1 We'll go ahead and register this today. thanks, Amanda On Sat May 09 18:18:34 2026, [email protected] wrote: > Reviewed. This registration looks good. One call out is that the > registration in the spec does not mention dsdoc. It would be good to > update the registration in the spec to match this registration. > > Darrel > > ________________________________ > From: Amanda Baber via RT <[email protected]> > Sent: Thursday, May 7, 2026 3:39 PM > Cc: [email protected] <[email protected]>; Darrel Miller > <[email protected]> > Subject: [IANA #1449148] application/vnd.digitalstack.document+zip > registration request > > Hi Darrel, > > Sending a reminder for this request from April 2nd. > > thanks, > Amanda > > On Thu Apr 02 16:27:35 2026, amanda.baber wrote: > > Hi Darrel, > > > > Another new request here. Can you review this by April 16th? > > > > thanks, > > Amanda > > > > ===== > > > > Name: Edwin Spradley > > > > Email: [email protected] > > > > Media type name: application > > > > Media subtype name: vnd.digitalstack.document+zip > > > > Required parameters: N/A > > > > Optional parameters: version: optional format version identifier for > > diagnostics or negotiation. If omitted, consumers MUST determine the > > version from the package manifest contained in the archive. Unknown > > optional parameters MUST be ignored. > > > > Encoding considerations: binary > > > > This media type is a ZIP-based container format and may contain JSON, > > text, signatures, and binary assets. Because it is a ZIP archive and > > may include arbitrary binary members and lines longer than 998 > > octets, > > binary encoding is required for transports that do not natively > > support binary content. The +zip structured syntax suffix is used to > > indicate the underlying container syntax. > > > > Security considerations: This media type does not itself define > > executable content and is intended to carry structured document > > packages. However, processors must treat package contents as > > untrusted > > input. Implementations should protect against malformed or malicious > > ZIP archives, including decompression bombs, oversized members, > > duplicate paths, directory traversal attempts, and corrupted central > > directory records. If the package contains embedded markup, scripts, > > attachments, or externally referenced resources, consuming > > applications must apply the security controls appropriate to those > > embedded formats and should avoid automatic execution or retrieval. > > > > The format may contain confidential business documents, signatures, > > comments, metadata, and audit information. As a result, privacy and > > integrity protections are often important. The media type itself does > > not guarantee confidentiality or authenticity; those protections > > should be provided externally, such as through TLS in transit, access > > controls at rest, and optional package signing or detached signatures > > where supported by the format. Because this type uses a ZIP > > container, > > the security considerations associated with +zip also apply. > > > > Interoperability considerations: Interoperability depends on > > consistent package structure and manifest semantics. Producers should > > generate a canonical package layout, stable UTF-8 manifest encoding, > > normalized path rules, and deterministic handling of optional > > members. > > Consumers should ignore unknown manifest fields and unknown package > > entries unless they are marked required by the specification. > > Interoperability may be reduced if implementations rely on vendor- > > specific extensions, noncanonical ZIP features, or undocumented > > required files. > > > > Published specification: https://digitalstack360.com/specs/dstack- > > document-package/v1#encoding > > > > Applications which use this media: Used by DigitalStack and > > compatible > > tools to exchange packaged business documents, reviewable artifacts, > > signatures, metadata, and related assets as a single portable file. > > > > Fragment identifier considerations: Fragment identifiers for > > application/vnd.digitalstack.document+zip follow the rules for > > application/zip unless otherwise defined by the DigitalStack package > > specification. This registration does not currently define additional > > fragment semantics beyond those associated with +zip. > > > > 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): 50 4B 03 04 > > 3. File extension(s): .dstack,.dsdoc > > 4. Macintosh file type code: N/A > > 5. Object Identifiers: N/A > > > > General Comments: This media type is intended for interoperable > > package exchange among DigitalStack-compatible systems and may also > > be > > used by third parties implementing the published specification. > > > > Person to contact for further information: > > > > 1. Name: Edwin Spradley > > 2. Email: [email protected] > > > > Intended usage: LIMITED USE > > > > This media type is used by DigitalStack and compatible tools to > > exchange structured document packages, including manifests, metadata, > > and associated assets, as a single portable archive. It is primarily > > intended for use within the DigitalStack ecosystem, but the format is > > publicly specified and may be implemented by third-party systems. > > > > Author/Change controller: DigitalStack a subsidiary of Edwin Digital _______________________________________________ media-types mailing list -- [email protected] To unsubscribe send an email to [email protected]