Change:
This PR removes the primary URL section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading. This and other removed sections can be defined in other documents in the future.
The subresource loading doesn't need a primary URL, but I think "Navigate to Bundle" use case still needs it. URL NAME NAME Please correct me if I am wrong. I'm assuming "Navigate to Bundle" uses a primary URL as a main resource URL.
That's correct. For a bundle to be navigable into, it needs to be possible to specify its main resource URL.
Yes, to open the web bundle file in the browser (eg: Drag and drop) we need either the primary URL or the manifest's . So, we need to keep either as an optional section.
The idea of this PR is that a primary URL could be defined in a separate section. However, it is outside the scope of the "core" bundle specification to define this section.
Thanks for making a PR! Could we see a path to having other document more clearly? Since we need a primary URL defined somewhere, it might be difficult to remove a primary URL section without a clear path how a primary URL is defined.
(Just in case if someone missed it) It seems this PR is one of agenda points at IETF 111 Wpack. URL
NAME : I just opened URL to discuss the possibility of creating an extension of the spec as a separate document.
LGTM (just for record). Thanks for working on this. Hello WPACK, My name is Felipe Erias. I am working on Web bundles at Igalia together with Dan Ehrenberg. I have just created several PRs at wpack-wg/bundled-responses and I am writing this email to request the addition of a point to discuss them to the agenda for the group's upcoming meeting at the end of July. These PRs address the removal of the primary URL section, the manifest section, and content negotiation. Most of this has been adapted from previous work by Dan on the WICG/webpackage repo. The overarching goal is to simplify the "core" Web Bundles specification so it includes just the minimal amount needed to support use cases like subresource loading. The removed sections may be defined in other documents in the future. These are the PRs: URL URL URL Best, Felipe

Discussion:
A bundle is logically a set of HTTP representations (Section 3.2 of I-D.ietf-httpbis-semantics), themselves represented by HTTP response messages (Section 3.4 of I-D.ietf-httpbis-semantics).  The bundle can <del> include an optional URL identifying the primary resource within the bundle and can include other optional metadata.  Particular applications can require that the primary URL and/or other metadata is present. </del> <ins> include optional metadata, which may be required by particular applications. </ins> While the order of the representations is not semantically meaningful, it can significantly affect performance when the bundle

""index"" (index-section) <del> ""primary"" (primary-section) </del> ""manifest"" (manifest-section) ""critical"" (critical-section)

4.2.2. <del> The "primary" section records a single URL identifying the primary URL of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. 4.2.3. </del> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself.

"application/manifest+json" (appmanifest) and an "accept-language" header of "es-419". <del> Many bundles have a choice between identifying their manifest in this section or in their primary resource, especially if that resource is an HTML file.  Identifying the manifest in this section can help recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource. 4.2.4. </del> <ins> 4.2.3. </ins> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the