Change:
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: URL Adapted from URL
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 NAME URL 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. NAME NAME Do you know any use case of variants? Can we remove variants support from the bundle format without any impacts on the chromium?
Chromium supports variants in Navigation to Web Bundles (URL), but not in Subresource loading with Web Bundles. Since Navigation to Web Bundles hasn'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 URL, 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 NAME 's approval before merge.

Discussion:
Abstract Web bundles provide a way to bundle up groups of HTTP responses, with <del> 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. </del> <ins> 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. </ins> 1.

They can load the bundle's metadata given a prefix of the bundle. They can find a representation within the bundle given that <del> representation's URL (semantics-naming) and the content- negotiation information that would appear in an HTTP request's headers. </del> <ins> representation's URL (semantics-naming). </ins> 2.2.

(Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This is also known as the representation's URL. <del> 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). </del> This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP response message.

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 <del> 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). 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. 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. For example, given a "Variants" value of "accept-encoding=(gzip br), accept-language=(en fr ja)", the list of offset/length pairs will correspond to the "Variant-Key"s: (gzip en) (gzip fr) (gzip ja) (br en) (br fr) (br ja) The order of variant-axes is important.  If the "Variants" value were "accept-language=(en fr ja), accept-encoding=(gzip br)" instead, the "location-in-responses" pairs would instead correspond to: (en gzip) (en br) (fr gzip) (fr br) (ja gzip) (ja br) If the wrong number of offset/length pairs is present in a resource's array, the entire index MUST fail to parse. A combination of available-values that is omitted from the bundle MUST be signaled by setting its offset and length to 0. </del> <ins> 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). </ins> 4.2.2.