Original text:
Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level <del> resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and </del>  efficiently store 8-bit resources. 1. The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII "1" followed by 3 0s) for this version of bundles.  If the recipient <del> doesn't support the version in this field, it MUST either ignore the bundle or fetch and use the content of the "primary-url" field instead. The "primary-url" field identifies both a fallback when the recipient doesn't understand the bundle and a default resource inside the bundle to use when the recipient doesn't have more specific instructions.  This field MAY be an empty string, although protocols using bundles MAY themselves forbid that empty value. </del>  The "section-lengths" and "sections" arrays contain the actual content of the bundle and are defined in sections.  The "section- ""index"" (index-section)  ""manifest"" (manifest-section) ""critical"" (critical-section) 4.2.2.  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. recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource. <del> 4.2.3. </del>  The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the

Reviewer comments:
Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL

Revised text:
Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level  <ins> resources, provide random access to their component exchanges, and </ins> efficiently store 8-bit resources. 1. The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII "1" followed by 3 0s) for this version of bundles.  If the recipient  <ins> doesn't support the version in this field, it MUST ignore the bundle. </ins> The "section-lengths" and "sections" arrays contain the actual content of the bundle and are defined in sections.  The "section- ""index"" (index-section) <ins> ""primary"" (primary-section) </ins> ""manifest"" (manifest-section) ""critical"" (critical-section) 4.2.2. <ins> 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. </ins> 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. recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource.  <ins> 4.2.4. </ins> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the