[media-types] Re: [IANA #1453672] application/vnd.po rtableweb+zip registration request
"Murray S. Kucherawy" <[email protected]> Tue, 14 Jul 2026 22:31:39 -0700
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <CAL0qLwZ228BirUhHtPMSPaiYoB0qj5O3yY03r-MpaT9TFOJWmA@mail.gmail.com> |
--===============1887228575793539946== Content-Type: multipart/alternative; boundary="0000000000000d89ee06569fa486" --0000000000000d89ee06569fa486 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, sorry for the delay here. This is extremely verbose, even with the proposed revision. I suspect only the key points in each section need to be presented in the registration template and the rest could be detailed in the specification. Further inline, mostly about use of "SHOULD". -MSK On Tue, Jul 14, 2026 at 4:44=E2=80=AFPM Amanda Baber via RT < [email protected]> wrote: > #1 Also, if it is not too late, could you please update the General > Comments section as follows to keep it concise and avoid repeating conten= t > from the =E2=80=9CApplications which use this media=E2=80=9D section? > > General Comments: > > PortableWeb (Portable Web Content Format) .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. > > 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. > > #2 For clarity, I am also consolidating the previously requested > Author/Change Controller update below. > > Author: > Omprakash Selvaraj > [email protected] > > Change Controller: > PortableWeb Project > [email protected] > > =3D=3D=3D=3D=3D > > 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 > > > > =3D=3D=3D=3D=3D > > > > 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. > I'm not crazy about including BCP 14 key words throughout this application's language unless the registration cites BCP 14. Do we have any guidance about this? A common point about using BCP 14 SHOULD (and there are over 20 instances here) is that SHOULD presents implementers with a choice and encourages an educated one, but often (as is the case here) fails to explain the choice being offered. For instance: "Viewers SHOULD also prevent active content from escaping the sandbox ..." When might an implementer legitimately deviate from that advice? Or are we saying SHOULD simply because we don't want to say MUST? I suggest applying that test to all the SHOULDs here. A possible alternative is to just lowercase all of the BCP 14 key words, avoiding the problem. > 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. > Were there any prior versions of this payload that might be incompatible with the version current at publication time? > > 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. > Who are those? Are they all authorized to change this? If so, the change controller contact above probably shouldn't name a specific person. > > Specification repository: > > > > https://github.com/portableweb/spec > > > > Project website: > > > > https://portableweb.github.io > > https://portableweb.org > --0000000000000d89ee06569fa486 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><span style=3D"background-color:transparent">Hi, sorr= y for the delay here.</span></div><div><span style=3D"background-color:tran= sparent"><br></span></div><div><span style=3D"background-color:transparent"= >This is extremely verbose, even with the proposed revision.=C2=A0 I suspec= t only the key points in each section need to be presented in the registrat= ion template and the rest could be detailed in the specification.</span></d= iv><div dir=3D"ltr"><span style=3D"background-color:transparent"><br></span= ></div><div><span style=3D"background-color:transparent">Further inline, mo= stly about use of "SHOULD".</span></div><div><span style=3D"backg= round-color:transparent"><br></span></div><div><span style=3D"background-co= lor:transparent">-MSK<br><br></span></div><div dir=3D"ltr"><span style=3D"b= ackground-color:transparent">On Tue, Jul 14, 2026 at 4:44=E2=80=AFPM Amanda= Baber via RT <<a href=3D"mailto:[email protected]">iana-mime-c= [email protected]</a>> wrote:</span></div><div class=3D"gmail_quote gmail_= quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">#1 Also,= if it is not too late, could you please update the General Comments sectio= n as follows to keep it concise and avoid repeating content from the =E2=80= =9CApplications which use this media=E2=80=9D section?<br> <br> General Comments:<br> <br> PortableWeb (Portable Web Content Format) .pweb packages are intended to pr= ovide a portable, self-contained packaging format for interactive web-based= content that can be saved, shared, archived, and opened like a document wh= ile still behaving like an application inside a controlled viewer.<br> <br> The format is designed to be opened by viewer applications that validate th= e 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.<br> <br> #2 For clarity, I am also consolidating the previously requested Author/Cha= nge Controller update below.<br> <br> Author:<br> Omprakash Selvaraj<br> <a href=3D"mailto:[email protected]" target=3D"_blank">maintainer@= portableweb.org</a><br> <br> Change Controller:<br> PortableWeb Project<br> <a href=3D"mailto:[email protected]" target=3D"_blank">maintainer@= portableweb.org</a><br> <br> =3D=3D=3D=3D=3D<br> <br> Thanks,<br> Amanda<br> <br> On Sat Jun 06 03:56:05 2026, amanda.baber wrote:<br> > Hi Murray,<br> > <br> > Could you review this one by June 19th?<br> > <br> > thanks,<br> > Amanda<br> > <br> > =3D=3D=3D=3D=3D<br> > <br> > Name: Omprakash Selvaraj<br> > <br> > Email: <a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a><br> > <br> > Media type name: application<br> > <br> > Media subtype name: vnd.portableweb+zip<br> > <br> > Required parameters: N/A<br> > <br> > Optional parameters: N/A<br> > <br> > Encoding considerations: binary<br> > <br> > Security considerations: PortableWeb files may contain active web<br> > content, including HTML, CSS, ECMAScript/JavaScript, WebAssembly if<br= > > permitted by the viewer, and other resources referenced by the<br> > PortableWeb manifest. Implementations MUST treat PortableWeb files as<= br> > untrusted content unless obtained from a trusted source.<br> > <br> > PortableWeb content is intended to be processed by a PortableWeb<br> > viewer, not executed as native operating-system code. Viewers that<br> > render active content SHOULD do so in a sandboxed execution<br> > environment with no ambient access to the host application, local<br> > files, device APIs, credentials, cookies, or other user data except<br= > > where the user explicitly grants access. Viewer implementations SHOULD= <br> > isolate storage per PortableWeb package, restrict or mediate network<b= r> > access according to user or application policy, prevent script access<= br> > to the viewer application's privileged user interface, and apply t= he<br> > security model of the underlying web rendering engine. Viewers SHOULD<= br> > also prevent active content from escaping the sandbox through<br> > navigation, popups, downloads, same-origin confusion, or unrestricted<= br> > access to host-provided APIs.<br></blockquote><div><br></div><div>I= 9;m not crazy about including BCP 14 key words throughout this application&= #39;s language unless the registration cites BCP 14.=C2=A0 Do we have any g= uidance about this?</div><div><br></div><div>A common point about using BCP= 14 SHOULD (and there are over 20 instances here) is that SHOULD presents i= mplementers with a choice and encourages an educated one, but often (as is = the case here) fails to explain the choice being offered.=C2=A0=C2=A0<span = style=3D"background-color:transparent">For</span><span style=3D"background-= color:rgb(231,242,255)"> </span>instance: "Viewers SHOULD also prevent= active content from escaping the sandbox ..."=C2=A0 When might an imp= lementer legitimately deviate from that advice?=C2=A0 Or are we saying SHOU= LD simply because we don't want to say MUST?</div><div><br></div><div>I= suggest applying that test to all the SHOULDs here.=C2=A0 A possible alter= native is to just lowercase all of the BCP 14 key words, avoiding the probl= em.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&= gt; A PortableWeb package may include a manifest that declares the<br> > package's requested or expected capabilities, such as whether the<= br> > package is intended to run offline, whether external network access is= <br> > requested, which origins or URL patterns may be accessed, whether<br> > persistent storage is requested, and whether other higher-risk<br> > capabilities such as downloads, popups, external navigation, clipboard= <br> > access, device APIs, or WebAssembly are requested. These manifest<br> > declarations are not security guarantees by themselves. They are<br> > inputs to the viewer's security policy. A viewer SHOULD apply a de= ny-<br> > by-default policy, SHOULD allow only the capabilities explicitly<br> > permitted by both the manifest and the viewer/user policy, and SHOULD<= br> > keep storage, cache, cookies, and other persistent state isolated per<= br> > PortableWeb package. A viewer MAY ignore or further restrict manifest-= <br> > requested capabilities.<br> > <br> > The media type itself does not provide confidentiality, integrity,<br> > authentication, authorization, or replay protection. PortableWeb files= <br> > may contain private or sensitive information, and they may also<br> > contain active content whose behavior depends on the integrity of the<= br> > package. Where confidentiality or integrity is required, it should be<= br> > provided externally, such as by HTTPS/TLS during transport, a trusted<= br> > distribution channel, operating-system file protections, digital<br> > signatures, checksums, or application-level validation. A viewer<br> > SHOULD make trust decisions based on the source and integrity of the<b= r> > package before enabling higher-risk capabilities.<br> > <br> > PortableWeb files are ZIP-based binary containers. The security<br> > considerations for ZIP containers and compressed content apply.<br> > Implementations SHOULD protect against decompression bombs, excessive<= br> > memory or disk usage, deeply nested archives, duplicate or ambiguous<b= r> > filenames, absolute paths, path traversal such as "../", sym= bolic<br> > links or platform-specific path handling issues, filename<br> > normalization conflicts, and mismatches between ZIP metadata and<br> > actual content. Implementations SHOULD impose reasonable limits on<br> > total uncompressed size, file count, nesting depth, path length, and<b= r> > individual resource size before extraction or rendering.<br> > Implementations SHOULD not extract files outside an application-<br> > controlled temporary or storage area.<br> > <br> > PortableWeb packages may include resources using existing formats,<br> > including but not limited to JSON manifests, HTML, CSS, JavaScript,<br= > > images, audio, video, fonts, and WebAssembly where supported. The<br> > security considerations for those formats also apply. Implementations<= br> > SHOULD parse the manifest strictly, avoid unsafe content sniffing,<br> > validate resource references against the manifest and package<br> > boundaries, and avoid granting additional privileges based only on<br> > file extension or declared media type.<br> > <br> > PortableWeb packages may contain internal links between packaged<br> > resources and may optionally contain external links. External network<= br> > resources are not required to interpret a conforming local PortableWeb= <br> > package unless explicitly allowed by the package profile and viewer<br= > > policy. Viewers SHOULD clearly distinguish packaged local resources<br= > > from external resources and SHOULD mediate or block external<br> > navigation and network requests according to user or application<br> > policy.<br> > <br> > Interoperability considerations: PortableWeb packages are ZIP-based<br= > > containers with a manifest that identifies the package structure,<br> > entry resource, declared capabilities, and packaged resources.<br> > Interoperability depends on viewers interpreting the manifest<br> > consistently, resolving resource paths consistently, and enforcing<br> > package boundaries consistently.<br></blockquote><div><br></div><div>W= ere there any prior versions of this payload that might be incompatible wit= h the version current at publication time?</div><div>=C2=A0</div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">> Implementations SHOULD use UTF= -8 for manifest data and resource<br> > identifiers, SHOULD treat resource paths as case-sensitive package-<br= > > relative paths, and SHOULD avoid relying on platform-specific<br> > filesystem behavior such as case-insensitive matching, absolute paths,= <br> > drive letters, symbolic links, or path separators other than "/&q= uot;.<br> > Viewers SHOULD reject or normalize ambiguous paths, duplicate entries,= <br> > and references that resolve outside the package.<br> > <br> > PortableWeb packages may contain common web resource formats such as<b= r> > HTML, CSS, JavaScript, JSON, images, fonts, audio, video, and other<br= > > media. Rendering behavior may vary between web engines, operating<br> > systems, and viewer implementations, especially for optional web<br> > platform features, media codecs, fonts, storage behavior, network<br> > policy, and device APIs. Package authors SHOULD use widely supported<b= r> > web standards and SHOULD declare required or requested capabilities in= <br> > the manifest. Viewers SHOULD ignore unknown manifest fields that are<b= r> > not required for safe processing, and packages SHOULD be designed to<b= r> > fail gracefully when optional capabilities are unavailable.<br> > <br> > A conforming local PortableWeb package should be interpretable using<b= r> > only the resources contained in the package, unless the manifest and<b= r> > viewer policy explicitly allow external network access.<br> > Implementations SHOULD clearly distinguish packaged resources from<br> > external resources and SHOULD apply consistent origin, storage, and<br= > > caching rules for each package.<br> > <br> > The ".pweb" file extension and the "application/vnd.por= tableweb+zip"<br> > media type identify the package as a PortableWeb package. Operating<br= > > systems, browsers, and applications may vary in how they associate<br> > file extensions, media types, icons, and document-opening behavior.<br= > > Applications that support this media type SHOULD inspect and validate<= br> > the package manifest and container structure rather than relying only<= br> > on the filename extension or declared media type.<br> > <br> > Published specification:<br> > <a href=3D"https://github.com/portableweb/spec/blob/main/spec/MANIFEST= .md" rel=3D"noreferrer" target=3D"_blank">https://github.com/portableweb/sp= ec/blob/main/spec/MANIFEST.md</a><br> > <a href=3D"https://github.com/portableweb/spec/blob/main/spec/CONTAINE= R.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/portableweb/s= pec/blob/main/spec/CONTAINER.md</a><br> > <a href=3D"https://portableweb.org" rel=3D"noreferrer" target=3D"_blan= k">https://portableweb.org</a><br> > <br> > Applications which use this media: This media type is intended for use= <br> > by applications that create, distribute, inspect, validate, store, or<= br> > render PortableWeb .pweb packages.<br> > <br> > Typical applications include PortableWeb viewer applications,<br> > authoring tools, packaging tools, validation tools, document-<br> > management systems, file managers, web servers, content-distribution<b= r> > systems, and collaboration or archival systems that need to identify<b= r> > PortableWeb packages by media type or file extension.<br> > <br> > A PortableWeb viewer may open a .pweb package as a self-contained<br> > interactive document, presentation, game, educational module,<br> > demonstration, or other packaged web-based experience. Developer and<b= r> > authoring tools may use this media type when creating, exporting,<br> > importing, testing, or validating PortableWeb packages.<br> > <br> > Operating systems and application platforms may also use this media<br= > > type and the .pweb file extension for file association, document<br> > opening, icons, previews, sharing, and handoff to applications that<br= > > support PortableWeb packages.<br> > <br> > This format is useful for interactive presentations, educational<br> > explainers, games, scientific journals and supplements, interactive<br= > > reports, reproducible simulations, personal tools, calculators,<br> > planners, journals, and other packaged web-based experiences.<br> > <br> > PortableWeb is also intended to support AI-generated interactive<br> > artifacts. AI tools are increasingly capable of producing large<br> > numbers of small, useful web applications and interactive documents.<b= r> > Not all such artifacts need to be deployed to a web server in order to= <br> > be useful. A .pweb package gives users, authors, and AI tools a way to= <br> > package such content as a file, preserve it, send it, and view it<br> > elegantly in a compatible viewer application.<br> > <br> > Fragment identifier considerations: Fragment identifier semantics are<= br> > not defined by this media type registration for the PortableWeb<br> > package container as a whole.<br> > <br> > A PortableWeb package is a ZIP-based container that may include<br> > resources such as HTML, CSS, JavaScript, JSON, images, media, and<br> > other files. Fragment identifiers, where used inside packaged<br> > resources, are interpreted according to the rules of the individual<br= > > resource media type, such as HTML fragment navigation within an HTML<b= r> > document.<br> > <br> > A PortableWeb viewer MAY support application-specific navigation<br> > behavior for fragment identifiers, such as forwarding a fragment to<br= > > the package's declared entry resource, but such behavior is viewer= -<br> > defined unless specified by the PortableWeb specification. Fragment<br= > > identifiers MUST NOT be treated as granting access to resources or<br> > capabilities that are not otherwise allowed by the package manifest<br= > > and viewer security policy.<br> > <br> > If a future version of the PortableWeb specification defines<br> > PortableWeb-specific fragment identifier syntax for addressing<br> > packaged resources or internal navigation targets, this registration<b= r> > should be updated to describe those semantics.<br> > <br> > Restrictions on usage: There are no restrictions on usage imposed by<b= r> > this media type registration.<br> > <br> > PortableWeb .pweb packages may be created, distributed, stored,<br> > opened, inspected, validated, and rendered by any application or<br> > platform that supports the PortableWeb format. Use of this media type<= br> > is not limited to a particular operating system, application store,<br= > > browser engine, vendor, or viewer implementation.<br> > <br> > Applications that process PortableWeb packages are expected to follow<= br> > the PortableWeb specification and apply appropriate security controls<= br> > for active content, storage, networking, and package validation.<br> > <br> > Provisional registration? (standards tree only): No<br> > <br> > Additional information:<br> > <br> > 1. Deprecated alias names for this type: N/A<br> > 2. Magic number(s): 50 4B 03 04 (PK\003\004) (.pweb files are ZIP-<br> > based containers and therefore use the ZIP container signatures)<br> > 3. File extension(s): .pweb<br> > 4. Macintosh file type code: N/A<br> > 5. Object Identifiers: N/A<br> > <br> > General Comments: PortableWeb .pweb packages are intended to provide a= <br> > portable, self-contained packaging format for interactive web-based<br= > > content that can be saved, shared, archived, and opened like a<br> > document while still behaving like an application inside a controlled<= br> > viewer.<br> > <br> > This format is useful for interactive presentations, educational<br> > explainers, games, scientific journals and supplements, interactive<br= > > reports, reproducible simulations, personal tools, calculators,<br> > planners, journals, and other packaged web-based experiences.<br> > <br> > PortableWeb is also intended to support AI-generated interactive<br> > artifacts. AI tools are increasingly capable of producing large<br> > numbers of small, useful web applications and interactive documents.<b= r> > Not all such artifacts need to be deployed to a web server in order to= <br> > be useful. A .pweb package gives users, authors, and AI tools a way to= <br> > package such content as a file, preserve it, send it, and view it<br> > elegantly in a compatible viewer application.<br> > <br> > The format is designed to be opened by viewer applications that<br> > validate the package, read the PortableWeb manifest, and render the<br= > > packaged resources under an application-defined security policy. The<b= r> > .pweb file extension is the preferred extension for this media type.<b= r> > <br> > Specification and project information are available at:<br> > <br> > <a href=3D"https://portableweb.org" rel=3D"noreferrer" target=3D"_blan= k">https://portableweb.org</a><br> > <br> > <a href=3D"https://github.com/portableweb/spec" rel=3D"noreferrer" tar= get=3D"_blank">https://github.com/portableweb/spec</a><br> > <br> > Person to contact for further information:<br> > <br> > 1. Name: Omprakash Selvaraj<br> > 2. Email: <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a><br> > <br> > Intended usage: COMMON<br> > <br> > Author/Change controller: PortableWeb Project<br> > <br> > Contact: Omprakash Selvaraj <a href=3D"mailto:[email protected]= rg" target=3D"_blank">[email protected]</a><br> > <br> > Change control for this registration is maintained by the PortableWeb<= br> > Project and its specification maintainers.<br></blockquote><div><br></= div><div>Who are those?=C2=A0 Are they all authorized to change this?=C2=A0= If so, the change controller contact above probably shouldn't name a s= pecific person.</div><div><span style=3D"background-color:transparent">=C2= =A0</span></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Spec= ification repository:<br> > <br> > <a href=3D"https://github.com/portableweb/spec" rel=3D"noreferrer" tar= get=3D"_blank">https://github.com/portableweb/spec</a><br> > <br> > Project website:<br> > <br> > <a href=3D"https://portableweb.github.io" rel=3D"noreferrer" target=3D= "_blank">https://portableweb.github.io</a><br> > <a href=3D"https://portableweb.org" rel=3D"noreferrer" target=3D"_blan= k">https://portableweb.org</a><br> </blockquote></div></div> --0000000000000d89ee06569fa486-- --===============1887228575793539946== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK --===============1887228575793539946==--