Draft: draft-ietf-wpack-bundled-responses

Commentary: This PR removes content negotiation from the spec . It is more efficient to use content negotiation on the server to select which bundle to send , rather than including several variants in the bundle and having that negotiation happen on the client 's side . Issue : Adapted from 
 Now that the working group has adopted the document , we actually need them to approve significant changes like this one , not me . We can check on this one during the IETF meeting . 
 Moved from It 's more efficient to use content negotiation to select which bundle to serve , rather than including several variants of a resource inside a bundle . Even most use cases around re - sharing bundles while offline can get away with including a single least - common - denominator resource . I only know of the case of translations that concretely need several variants of the same resource . Can we simplify the design by omitting content negotiation ? We 'd lose some fidelity in representing HTTP , but that might be acceptable . 
 I"m fine to remove the variants support from the bundle format , however , I 'm wondering how removing the variants support impacts on the chromium 's implementation . We should align somehow . Do you know any use case of variants ? Can we remove variants support from the bundle format without any impacts on the chromium ? 
  supports variants in Navigation to Web Bundles ( ) , but not in Subresource loading with Web Bundles . Since Navigation to Web Bundles has n't shipped yet , I think it 's fine to remove it from Chromium . 
 If we remove the content negotiation , it may become difficult to support new data formats like WebP in future . But removing it from the bundle format now and re - thinking when it will be more important sounds acceptable . 
 The idea here is that you would negotiate for the whole bundle , not for resources within the bundle . I think this could permit upgrade to new image formats over time , without shipping all the different options redundantly to the client . 
 I think we can close this issue . Content negotiation was already dropped . 
 Thanks for making a PR ! Per the discussion , the chromium side is okay to remove content negotiation . We probably have to change parser 's behavior by checking a bundle 's version . That should not be a significant issue for us . We might want to wait for 's approval before merge .
Paragraph (version A):
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
resources, provide random access to their component exchanges, and
efficiently store 8-bit resources.
Paragraph (version B):
Web bundles provide a way to bundle up groups of HTTP responses, with
the request URLs that produced them, to transmit or store together.
They can include multiple top-level resources, provide random access
to their component exchanges, and efficiently store 8-bit resources.
Paragraph (version A):
They can find a representation within the bundle given that
representation's URL (semantics-naming) and the content-
negotiation information that would appear in an HTTP request's
headers.
Paragraph (version B):
They can find a representation within the bundle given that
representation's URL (semantics-naming).
Paragraph (version A):
Multiple representations within a bundle can have the same URL, in
which case they are distinguished by the content negotiation
information contained in their "Variants" and "Variant-Key" headers
(I-D.ietf-httpbis-variants).
Paragraph (version A):
The ""index"" section defines the set of HTTP representations in the
bundle and identifies their locations in the ""responses"" section.
It consists of a CBOR map whose keys are the URLs of the
representations in the bundle (semantics-naming).  The value of an
index entry is an array whose first item is a "Variants" header field
value (I-D.ietf-httpbis-variants) or the empty string.  This is
followed by a sequence of offset/length pairs, one for each
representation of this resource.  The offset is relative to the start
of the ""responses"" section, with an offset of 0 referring to the
head of the CBOR "responses" array itself.  The length is the length
in bytes of the "response" CBOR item holding this representation
(responses-section).
Paragraph (version A):
If the first item in the value of an index entry is empty, it MUST be
followed by exactly one offset/length pair.  This means there is a
single representation for this resource, with no content negotiation.
Paragraph (version A):
Otherwise, the first item MUST be followed by one offset/length pair
for each of the possible combinations of available-values within the
"Variants" value (the first item of the array) in lexicographic (row-
major) order.
Paragraph (version A):
If the wrong number of offset/length pairs is present in a resource's
array, the entire index MUST fail to parse.
Paragraph (version A):
A combination of available-values that is omitted from the bundle
MUST be signaled by setting its offset and length to 0.
Paragraph (version B):
The ""index"" section defines the set of HTTP representations in the
bundle and identifies their locations in the ""responses"" section.
It consists of a CBOR map whose keys are the URLs of the
representations in the bundle (semantics-naming).  The value of an
index entry is an offset/length pair.  The offset is relative to the
start of the ""responses"" section, with an offset of 0 referring to
the head of the CBOR "responses" array itself.  The length is the
length in bytes of the "response" CBOR item holding this
representation (responses-section).