[media-types] [IANA #1453672] application/vnd.portable web+zip registration request

Hi Murray,

Sending a reminder for this request from June 5th.

The requester's going to replace the author/change controller with the following:

Author:
  Omprakash Selvaraj
  [email protected]

Change Controller:
  PortableWeb Project
  [email protected]

thanks,
Amanda

On Sat Jun 06 03:56:05 2026, amanda.baber wrote:
> Hi Murray,
> 
> Could you review this one by June 19th?
> 
> thanks,
> Amanda
> 
> =====
> 
> Name: Omprakash Selvaraj
> 
> Email: [email protected]
> 
> Media type name: application
> 
> Media subtype name: vnd.portableweb+zip
> 
> Required parameters: N/A
> 
> Optional parameters: N/A
> 
> Encoding considerations: binary
> 
> Security considerations: PortableWeb files may contain active web
> content, including HTML, CSS, ECMAScript/JavaScript, WebAssembly if
> permitted by the viewer, and other resources referenced by the
> PortableWeb manifest. Implementations MUST treat PortableWeb files as
> untrusted content unless obtained from a trusted source.
> 
> PortableWeb content is intended to be processed by a PortableWeb
> viewer, not executed as native operating-system code. Viewers that
> render active content SHOULD do so in a sandboxed execution
> environment with no ambient access to the host application, local
> files, device APIs, credentials, cookies, or other user data except
> where the user explicitly grants access. Viewer implementations SHOULD
> isolate storage per PortableWeb package, restrict or mediate network
> access according to user or application policy, prevent script access
> to the viewer application's privileged user interface, and apply the
> security model of the underlying web rendering engine. Viewers SHOULD
> also prevent active content from escaping the sandbox through
> navigation, popups, downloads, same-origin confusion, or unrestricted
> access to host-provided APIs.
> 
> A PortableWeb package may include a manifest that declares the
> package's requested or expected capabilities, such as whether the
> package is intended to run offline, whether external network access is
> requested, which origins or URL patterns may be accessed, whether
> persistent storage is requested, and whether other higher-risk
> capabilities such as downloads, popups, external navigation, clipboard
> access, device APIs, or WebAssembly are requested. These manifest
> declarations are not security guarantees by themselves. They are
> inputs to the viewer's security policy. A viewer SHOULD apply a deny-
> by-default policy, SHOULD allow only the capabilities explicitly
> permitted by both the manifest and the viewer/user policy, and SHOULD
> keep storage, cache, cookies, and other persistent state isolated per
> PortableWeb package. A viewer MAY ignore or further restrict manifest-
> requested capabilities.
> 
> The media type itself does not provide confidentiality, integrity,
> authentication, authorization, or replay protection. PortableWeb files
> may contain private or sensitive information, and they may also
> contain active content whose behavior depends on the integrity of the
> package. Where confidentiality or integrity is required, it should be
> provided externally, such as by HTTPS/TLS during transport, a trusted
> distribution channel, operating-system file protections, digital
> signatures, checksums, or application-level validation. A viewer
> SHOULD make trust decisions based on the source and integrity of the
> package before enabling higher-risk capabilities.
> 
> PortableWeb files are ZIP-based binary containers. The security
> considerations for ZIP containers and compressed content apply.
> Implementations SHOULD protect against decompression bombs, excessive
> memory or disk usage, deeply nested archives, duplicate or ambiguous
> filenames, absolute paths, path traversal such as "../", symbolic
> links or platform-specific path handling issues, filename
> normalization conflicts, and mismatches between ZIP metadata and
> actual content. Implementations SHOULD impose reasonable limits on
> total uncompressed size, file count, nesting depth, path length, and
> individual resource size before extraction or rendering.
> Implementations SHOULD not extract files outside an application-
> controlled temporary or storage area.
> 
> PortableWeb packages may include resources using existing formats,
> including but not limited to JSON manifests, HTML, CSS, JavaScript,
> images, audio, video, fonts, and WebAssembly where supported. The
> security considerations for those formats also apply. Implementations
> SHOULD parse the manifest strictly, avoid unsafe content sniffing,
> validate resource references against the manifest and package
> boundaries, and avoid granting additional privileges based only on
> file extension or declared media type.
> 
> PortableWeb packages may contain internal links between packaged
> resources and may optionally contain external links. External network
> resources are not required to interpret a conforming local PortableWeb
> package unless explicitly allowed by the package profile and viewer
> policy. Viewers SHOULD clearly distinguish packaged local resources
> from external resources and SHOULD mediate or block external
> navigation and network requests according to user or application
> policy.
> 
> Interoperability considerations: PortableWeb packages are ZIP-based
> containers with a manifest that identifies the package structure,
> entry resource, declared capabilities, and packaged resources.
> Interoperability depends on viewers interpreting the manifest
> consistently, resolving resource paths consistently, and enforcing
> package boundaries consistently.
> 
> Implementations SHOULD use UTF-8 for manifest data and resource
> identifiers, SHOULD treat resource paths as case-sensitive package-
> relative paths, and SHOULD avoid relying on platform-specific
> filesystem behavior such as case-insensitive matching, absolute paths,
> drive letters, symbolic links, or path separators other than "/".
> Viewers SHOULD reject or normalize ambiguous paths, duplicate entries,
> and references that resolve outside the package.
> 
> PortableWeb packages may contain common web resource formats such as
> HTML, CSS, JavaScript, JSON, images, fonts, audio, video, and other
> media. Rendering behavior may vary between web engines, operating
> systems, and viewer implementations, especially for optional web
> platform features, media codecs, fonts, storage behavior, network
> policy, and device APIs. Package authors SHOULD use widely supported
> web standards and SHOULD declare required or requested capabilities in
> the manifest. Viewers SHOULD ignore unknown manifest fields that are
> not required for safe processing, and packages SHOULD be designed to
> fail gracefully when optional capabilities are unavailable.
> 
> A conforming local PortableWeb package should be interpretable using
> only the resources contained in the package, unless the manifest and
> viewer policy explicitly allow external network access.
> Implementations SHOULD clearly distinguish packaged resources from
> external resources and SHOULD apply consistent origin, storage, and
> caching rules for each package.
> 
> The ".pweb" file extension and the "application/vnd.portableweb+zip"
> media type identify the package as a PortableWeb package. Operating
> systems, browsers, and applications may vary in how they associate
> file extensions, media types, icons, and document-opening behavior.
> Applications that support this media type SHOULD inspect and validate
> the package manifest and container structure rather than relying only
> on the filename extension or declared media type.
> 
> Published specification:
> https://github.com/portableweb/spec/blob/main/spec/MANIFEST.md
> https://github.com/portableweb/spec/blob/main/spec/CONTAINER.md
> https://portableweb.org
> 
> Applications which use this media: This media type is intended for use
> by applications that create, distribute, inspect, validate, store, or
> render PortableWeb .pweb packages.
> 
> Typical applications include PortableWeb viewer applications,
> authoring tools, packaging tools, validation tools, document-
> management systems, file managers, web servers, content-distribution
> systems, and collaboration or archival systems that need to identify
> PortableWeb packages by media type or file extension.
> 
> A PortableWeb viewer may open a .pweb package as a self-contained
> interactive document, presentation, game, educational module,
> demonstration, or other packaged web-based experience. Developer and
> authoring tools may use this media type when creating, exporting,
> importing, testing, or validating PortableWeb packages.
> 
> Operating systems and application platforms may also use this media
> type and the .pweb file extension for file association, document
> opening, icons, previews, sharing, and handoff to applications that
> support PortableWeb packages.
> 
> This format is useful for interactive presentations, educational
> explainers, games, scientific journals and supplements, interactive
> reports, reproducible simulations, personal tools, calculators,
> planners, journals, and other packaged web-based experiences.
> 
> PortableWeb is also intended to support AI-generated interactive
> artifacts. AI tools are increasingly capable of producing large
> numbers of small, useful web applications and interactive documents.
> Not all such artifacts need to be deployed to a web server in order to
> be useful. A .pweb package gives users, authors, and AI tools a way to
> package such content as a file, preserve it, send it, and view it
> elegantly in a compatible viewer application.
> 
> Fragment identifier considerations: Fragment identifier semantics are
> not defined by this media type registration for the PortableWeb
> package container as a whole.
> 
> A PortableWeb package is a ZIP-based container that may include
> resources such as HTML, CSS, JavaScript, JSON, images, media, and
> other files. Fragment identifiers, where used inside packaged
> resources, are interpreted according to the rules of the individual
> resource media type, such as HTML fragment navigation within an HTML
> document.
> 
> A PortableWeb viewer MAY support application-specific navigation
> behavior for fragment identifiers, such as forwarding a fragment to
> the package's declared entry resource, but such behavior is viewer-
> defined unless specified by the PortableWeb specification. Fragment
> identifiers MUST NOT be treated as granting access to resources or
> capabilities that are not otherwise allowed by the package manifest
> and viewer security policy.
> 
> If a future version of the PortableWeb specification defines
> PortableWeb-specific fragment identifier syntax for addressing
> packaged resources or internal navigation targets, this registration
> should be updated to describe those semantics.
> 
> Restrictions on usage: There are no restrictions on usage imposed by
> this media type registration.
> 
> PortableWeb .pweb packages may be created, distributed, stored,
> opened, inspected, validated, and rendered by any application or
> platform that supports the PortableWeb format. Use of this media type
> is not limited to a particular operating system, application store,
> browser engine, vendor, or viewer implementation.
> 
> Applications that process PortableWeb packages are expected to follow
> the PortableWeb specification and apply appropriate security controls
> for active content, storage, networking, and package validation.
> 
> 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 (PK\003\004) (.pweb files are ZIP-
> based containers and therefore use the ZIP container signatures)
> 3. File extension(s): .pweb
> 4. Macintosh file type code: N/A
> 5. Object Identifiers: N/A
> 
> General Comments: PortableWeb .pweb packages are intended to provide a
> portable, self-contained packaging format for interactive web-based
> content that can be saved, shared, archived, and opened like a
> document while still behaving like an application inside a controlled
> viewer.
> 
> This format is useful for interactive presentations, educational
> explainers, games, scientific journals and supplements, interactive
> reports, reproducible simulations, personal tools, calculators,
> planners, journals, and other packaged web-based experiences.
> 
> PortableWeb is also intended to support AI-generated interactive
> artifacts. AI tools are increasingly capable of producing large
> numbers of small, useful web applications and interactive documents.
> Not all such artifacts need to be deployed to a web server in order to
> be useful. A .pweb package gives users, authors, and AI tools a way to
> package such content as a file, preserve it, send it, and view it
> elegantly in a compatible viewer application.
> 
> The format is designed to be opened by viewer applications that
> validate the package, read the PortableWeb manifest, and render the
> packaged resources under an application-defined security policy. The
> .pweb file extension is the preferred extension for this media type.
> 
> Specification and project information are available at:
> 
> https://portableweb.org
> 
> https://github.com/portableweb/spec
> 
> Person to contact for further information:
> 
> 1. Name: Omprakash Selvaraj
> 2. Email: [email protected]
> 
> Intended usage: COMMON
> 
> Author/Change controller: PortableWeb Project
> 
> Contact: Omprakash Selvaraj [email protected]
> 
> Change control for this registration is maintained by the PortableWeb
> Project and its specification maintainers.
> 
> Specification repository:
> 
> https://github.com/portableweb/spec
> 
> Project website:
> 
> https://portableweb.github.io
> https://portableweb.org

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]