Draft: draft-ietf-wpack-bundled-responses

Commentary: 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 does n't need a primary URL , but I think " Navigate to Bundle " use case still needs it . 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 . 
 : I just opened to discuss the possibility of creating an extension of the spec as a separate document . 
 LGTM ( just for record ) . Thanks for working on this .
Mailing list commentary: Hello WPACK , My name is . I am working on Web bundles at Igalia together with . 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 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 : Best ,
Paragraph (version A):
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
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.
Paragraph (version B):
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
include optional metadata, which may be required by particular
applications.
Paragraph (version A):
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.
Paragraph (version A):
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.