draft-ietf-wpack-bundled-responses-00.txt   draft-ietf-wpack-bundled-responses-01.txt 
Network Working Group J. Yasskin Network Working Group J. Yasskin
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track 6 May 2021 Intended status: Standards Track 24 June 2021
Expires: 7 November 2021 Expires: 26 December 2021
Web Bundles Web Bundles
draft-ietf-wpack-bundled-responses-00 draft-ietf-wpack-bundled-responses-01
Abstract Abstract
Web bundles provide a way to bundle up groups of HTTP responses, with Web bundles provide a way to bundle up groups of HTTP responses, with
the request URLs and content negotiation that produced them, to the request URLs and content negotiation that produced them, to
transmit or store together. They can include multiple top-level transmit or store together. They can include multiple top-level
resources with one identified as the default by a primaryUrl resources, provide random access to their component exchanges, and
metadata, provide random access to their component exchanges, and
efficiently store 8-bit resources. efficiently store 8-bit resources.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Web Packaging Working Discussion of this document takes place on the Web Packaging Working
Group mailing list (wpack@ietf.org), which is archived at Group mailing list (wpack@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/wpack/. https://mailarchive.ietf.org/arch/browse/wpack/.
skipping to change at page 1, line 46 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 November 2021. This Internet-Draft will expire on 26 December 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3
2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Naming a representation . . . . . . . . . . . . . . . . . 3 2.2. Naming a representation . . . . . . . . . . . . . . . . . 3
3. Expected performance . . . . . . . . . . . . . . . . . . . . 4 3. Expected performance . . . . . . . . . . . . . . . . . . . . 4
3.1. Random access . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Random access . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Streaming . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Streaming . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Top-level structure . . . . . . . . . . . . . . . . . . . 4 4.1. Top-level structure . . . . . . . . . . . . . . . . . . . 4
4.1.1. Trailing length . . . . . . . . . . . . . . . . . . . 6 4.1.1. Trailing length . . . . . . . . . . . . . . . . . . . 5
4.1.2. Draft version numbers . . . . . . . . . . . . . . . . 6 4.1.2. Draft version numbers . . . . . . . . . . . . . . . . 6
4.2. Bundle sections . . . . . . . . . . . . . . . . . . . . . 6 4.2. Bundle sections . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. The index section . . . . . . . . . . . . . . . . . . 7 4.2.1. The index section . . . . . . . . . . . . . . . . . . 7
4.2.2. The manifest section . . . . . . . . . . . . . . . . 9 4.2.2. The primary section . . . . . . . . . . . . . . . . . 8
4.2.3. The critical section . . . . . . . . . . . . . . . . 9 4.2.3. The manifest section . . . . . . . . . . . . . . . . 8
4.2.4. The critical section . . . . . . . . . . . . . . . . 9
4.3. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Serving constraints . . . . . . . . . . . . . . . . . . . 10 4.4. Serving constraints . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Version skew . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Version skew . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Content sniffing . . . . . . . . . . . . . . . . . . . . 11 5.2. Content sniffing . . . . . . . . . . . . . . . . . . . . 10
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. Internet Media Type Registration . . . . . . . . . . . . 12 6.1. Internet Media Type Registration . . . . . . . . . . . . 12
6.2. Web Bundle Section Name Registry . . . . . . . . . . . . 13 6.2. Web Bundle Section Name Registry . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
To satisfy the use cases in [I-D.yasskin-wpack-use-cases], this To satisfy the use cases in [I-D.yasskin-wpack-use-cases], this
document proposes a new bundling format to group HTTP resources. The document proposes a new bundling format to group HTTP resources. The
format is structured as an initial table of "sections" within the format is structured as an initial table of "sections" within the
bundle followed by the content of those sections. bundle followed by the content of those sections.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the conventions and terminology defined in This specification uses the conventions and terminology defined in
the Infra Standard ([INFRA]). the Infra Standard ([INFRA]).
2. Semantics 2. Semantics
A bundle is logically a set of HTTP representations (Section 7 of A bundle is logically a set of HTTP representations (Section 3.2 of
[I-D.ietf-httpbis-semantics]), themselves represented by HTTP [I-D.ietf-httpbis-semantics]), themselves represented by HTTP
response messages (Section 2.1 of [I-D.ietf-httpbis-semantics]). The response messages (Section 3.4 of [I-D.ietf-httpbis-semantics]). The
bundle can include an optional URL identifying the primary resource bundle can include an optional URL identifying the primary resource
within the bundle and can include other optional metadata. within the bundle and can include other optional metadata.
Particular applications can require that the primary URL and/or other Particular applications can require that the primary URL and/or other
metadata is present. metadata is present.
While the order of the representations is not semantically While the order of the representations is not semantically
meaningful, it can significantly affect performance when the bundle meaningful, it can significantly affect performance when the bundle
is loaded from a network stream. is loaded from a network stream.
2.1. Operations 2.1. Operations
skipping to change at page 3, line 50 skipping to change at page 3, line 50
1. They can load the bundle's metadata given a prefix of the bundle. 1. They can load the bundle's metadata given a prefix of the bundle.
2. They can find a representation within the bundle given that 2. They can find a representation within the bundle given that
representation's URL (Section 2.2) and the content-negotiation representation's URL (Section 2.2) and the content-negotiation
information that would appear in an HTTP request's headers. information that would appear in an HTTP request's headers.
2.2. Naming a representation 2.2. Naming a representation
Representations within a bundle are named by their "Content-Location" Representations within a bundle are named by their "Content-Location"
(Section 7.8 of [I-D.ietf-httpbis-semantics]), which holds a URL. (Section 8.7 of [I-D.ietf-httpbis-semantics]), which holds a URL.
This is also known as the representation's URL. This is also known as the representation's URL.
Multiple representations within a bundle can have the same URL, in Multiple representations within a bundle can have the same URL, in
which case they are distinguished by the content negotiation which case they are distinguished by the content negotiation
information contained in their "Variants" and "Variant-Key" headers information contained in their "Variants" and "Variant-Key" headers
([I-D.ietf-httpbis-variants]). ([I-D.ietf-httpbis-variants]).
This identifying information for each representation is stored in an This identifying information for each representation is stored in an
index (Section 4.2.1) rather than in that representation's HTTP index (Section 4.2.1) rather than in that representation's HTTP
response message. response message.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
4. Format 4. Format
4.1. Top-level structure 4.1. Top-level structure
A bundle is a CBOR array ([CBORbis]) with the following CDDL ([CDDL]) A bundle is a CBOR array ([CBORbis]) with the following CDDL ([CDDL])
schema: schema:
webbundle = [ webbundle = [
magic: h'F0 9F 8C 90 F0 9F 93 A6', magic: h'F0 9F 8C 90 F0 9F 93 A6',
version: bytes .size 4, version: bytes .size 4,
primary-url: whatwg-url,
section-lengths: bytes .cbor section-lengths, section-lengths: bytes .cbor section-lengths,
sections: [* any ], sections: [* any ],
length: bytes .size 8, ; Big-endian number of bytes in the bundle. length: bytes .size 8, ; Big-endian number of bytes in the bundle.
] ]
whatwg-url = tstr whatwg-url = tstr
When serialized, the bundle MUST satisfy the core deterministic When serialized, the bundle MUST satisfy the core deterministic
encoding requirements from Section 4.2.1 of [CBORbis]. This format encoding requirements from Section 4.2.1 of [CBORbis]. This format
does not use floating point values or tags, so this specification does not use floating point values or tags, so this specification
skipping to change at page 5, line 38 skipping to change at page 5, line 37
The "magic" number is "🌐📦" (U+1F310 U+1F4E6) encoded in UTF-8. With The "magic" number is "🌐📦" (U+1F310 U+1F4E6) encoded in UTF-8. With
the CBOR initial bytes for the array and bytestring, this makes the the CBOR initial bytes for the array and bytestring, this makes the
format identifiable by looking for "8? 48" (in base 16) followed by format identifiable by looking for "8? 48" (in base 16) followed by
that UTF-8 encoding. Parsers MUST only check the initial nibble of that UTF-8 encoding. Parsers MUST only check the initial nibble of
the initial "8?" byte in order to accommodate any future version's the initial "8?" byte in order to accommodate any future version's
change in the number of array elements (up to 15). change in the number of array elements (up to 15).
The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII 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 "1" followed by 3 0s) for this version of bundles. If the recipient
doesn't support the version in this field, it MUST either ignore the doesn't support the version in this field, it MUST ignore the bundle.
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.
The "section-lengths" and "sections" arrays contain the actual The "section-lengths" and "sections" arrays contain the actual
content of the bundle and are defined in Section 4.2. The "section- content of the bundle and are defined in Section 4.2. The "section-
lengths" array is embedded in a byte string to facilitate reading it lengths" array is embedded in a byte string to facilitate reading it
from a network. This byte string MUST be less than 8192 (8*1024) from a network. This byte string MUST be less than 8192 (8*1024)
bytes long, and parsers MUST NOT load any data from a "section- bytes long, and parsers MUST NOT load any data from a "section-
lengths" item longer than this. lengths" item longer than this.
The bundle ends with an 8-byte integer holding the length of the The bundle ends with an 8-byte integer holding the length of the
whole bundle. whole bundle.
skipping to change at page 7, line 4 skipping to change at page 6, line 35
"version" string of "31 00 00 00" (base 16). They MUST instead "version" string of "31 00 00 00" (base 16). They MUST instead
define an implementation-specific 4-byte string starting with "62" define an implementation-specific 4-byte string starting with "62"
("b") to identify which draft is implemented. ("b") to identify which draft is implemented.
4.2. Bundle sections 4.2. Bundle sections
A bundle's content is in a series of sections, which can be accessed A bundle's content is in a series of sections, which can be accessed
randomly using the information in the "section-lengths" CBOR item: randomly using the information in the "section-lengths" CBOR item:
section-lengths = [* (section-name: tstr, length: uint) ], section-lengths = [* (section-name: tstr, length: uint) ],
This field lists the named sections in the bundle in the order they This field lists the named sections in the bundle in the order they
appear, with each section name followed by the length in bytes of the appear, with each section name followed by the length in bytes of the
corresponding CBOR item in the "sections" array. This allows a corresponding CBOR item in the "sections" array. This allows a
random-access parser (Section 3) to jump directly to the section it random-access parser (Section 3) to jump directly to the section it
needs. This specification defines the following sections: needs. This specification defines the following sections:
* ""index"" (Section 4.2.1) * ""index"" (Section 4.2.1)
* ""manifest"" (Section 4.2.2) * ""primary"" (Section 4.2.2)
* ""critical"" (Section 4.2.3) * ""manifest"" (Section 4.2.3)
* ""responses"" (Section 4.3) * ""critical"" (Section 4.2.4)
* ""responses"" (Section 4.3)
Future specifications can register new section names as described in Future specifications can register new section names as described in
Section 6.2, in order to extend the format without incrementing its Section 6.2, in order to extend the format without incrementing its
version number. version number.
The ""responses"" section MUST appear after the other three sections The ""responses"" section MUST appear after the other three sections
defined here, and parsers MUST NOT load any data if that is not the defined here, and parsers MUST NOT load any data if that is not the
case. case.
The "sections" array contains the sections' content. The length of The "sections" array contains the sections' content. The length of
this array MUST be exactly half the length of the "section-lengths" this array MUST be exactly half the length of the "section-lengths"
skipping to change at page 9, line 5 skipping to change at page 8, line 36
* (ja gzip) * (ja gzip)
* (ja br) * (ja br)
If the wrong number of offset/length pairs is present in a resource's If the wrong number of offset/length pairs is present in a resource's
array, the entire index MUST fail to parse. array, the entire index MUST fail to parse.
A combination of available-values that is omitted from the bundle A combination of available-values that is omitted from the bundle
MUST be signaled by setting its offset and length to 0. MUST be signaled by setting its offset and length to 0.
4.2.2. The manifest section 4.2.2. The primary section
primary = whatwg-url
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. The manifest section
manifest = whatwg-url manifest = whatwg-url
The "manifest" section records a single URL identifying the manifest The "manifest" section records a single URL identifying the manifest
of the bundle. The URL MUST refer to a resource with representations of the bundle. The URL MUST refer to a resource with representations
contained in the bundle itself. contained in the bundle itself.
The bundle can contain multiple representations at this URL, and the The bundle can contain multiple representations at this URL, and the
client is expected to content-negotiate for the best one. For client is expected to content-negotiate for the best one. For
example, a client might select the one matching an "accept" header of example, a client might select the one matching an "accept" header of
"application/manifest+json" ([appmanifest]) and an "accept-language" "application/manifest+json" ([appmanifest]) and an "accept-language"
header of "es-419". header of "es-419".
Many bundles have a choice between identifying their manifest in this Many bundles have a choice between identifying their manifest in this
section or in their primary resource, especially if that resource is section or in their primary resource, especially if that resource is
an HTML file. Identifying the manifest in this section can help an HTML file. Identifying the manifest in this section can help
recipients apply fields in the manifest sooner, for example to show a recipients apply fields in the manifest sooner, for example to show a
splash screen before parsing the primary resource. splash screen before parsing the primary resource.
4.2.3. The critical section 4.2.4. The critical section
critical = [*tstr] critical = [*tstr]
The "critical" section consists of the names of sections of the The "critical" section consists of the names of sections of the
bundle that the client needs to understand in order to load the bundle that the client needs to understand in order to load the
bundle correctly. Other sections are assumed to be optional. bundle correctly. Other sections are assumed to be optional.
If the client has not implemented a section named by one of the items If the client has not implemented a section named by one of the items
in this list, the client MUST fail to parse the bundle as a whole. in this list, the client MUST fail to parse the bundle as a whole.
skipping to change at page 10, line 19 skipping to change at page 10, line 10
The keys of the headers map MUST consist of lowercase ASCII as The keys of the headers map MUST consist of lowercase ASCII as
described in Section 8.1.2 of [RFC7540]. Response pseudo-headers described in Section 8.1.2 of [RFC7540]. Response pseudo-headers
(Section 8.1.2.4 of [RFC7540] are included in this headers map. (Section 8.1.2.4 of [RFC7540] are included in this headers map.
Each response's headers MUST include a ":status" pseudo-header with Each response's headers MUST include a ":status" pseudo-header with
exactly 3 ASCII decimal digits and MUST NOT include any other pseudo- exactly 3 ASCII decimal digits and MUST NOT include any other pseudo-
headers. headers.
If a response's payload is not empty, its headers MUST include a If a response's payload is not empty, its headers MUST include a
"Content-Type" header (Section 7.4 of [I-D.ietf-httpbis-semantics]). "Content-Type" header (Section 8.3 of [I-D.ietf-httpbis-semantics]).
The client MUST interpret the following payload as this specified The client MUST interpret the following payload as this specified
media type instead of trying to sniff a media type from the bytes of media type instead of trying to sniff a media type from the bytes of
the payload, for example by appending an artificial "X-Content-Type- the payload, for example by appending an artificial "X-Content-Type-
Options: nosniff" header field ([FETCH]) to downstream protocols. Options: nosniff" header field ([FETCH]) to downstream protocols.
4.4. Serving constraints 4.4. Serving constraints
When served over HTTP, a response containing an "application/ When served over HTTP, a response containing an "application/
webbundle" payload MUST include at least the following response webbundle" payload MUST include at least the following response
header fields, to reduce content sniffing vulnerabilities header fields, to reduce content sniffing vulnerabilities
skipping to change at page 14, line 10 skipping to change at page 13, line 37
Review Process: Specification Required Review Process: Specification Required
Initial Assignments: Initial Assignments:
+==============+===============+ +==============+===============+
| Section Name | Specification | | Section Name | Specification |
+==============+===============+ +==============+===============+
| "index" | Section 4.2.1 | | "index" | Section 4.2.1 |
+--------------+---------------+ +--------------+---------------+
| "manifest" | Section 4.2.2 | | "manifest" | Section 4.2.3 |
+--------------+---------------+ +--------------+---------------+
| "critical" | Section 4.2.3 | | "critical" | Section 4.2.4 |
+--------------+---------------+ +--------------+---------------+
| "responses" | Section 4.3 | | "responses" | Section 4.3 |
+--------------+---------------+ +--------------+---------------+
Table 1 Table 1
Requirements on new assignments: Requirements on new assignments:
Section Names MUST be encoded in UTF-8. Section Names MUST be encoded in UTF-8.
skipping to change at page 14, line 48 skipping to change at page 14, line 27
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>. <https://www.rfc-editor.org/rfc/rfc8949>.
[CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>. June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[FETCH] WHATWG, "Fetch", May 2021, [FETCH] WHATWG, "Fetch", June 2021,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[I-D.ietf-httpbis-semantics] [I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-15, 30 March 2021, httpbis-semantics-16, 27 May 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-semantics- <https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
15>. 16>.
[I-D.ietf-httpbis-variants] [I-D.ietf-httpbis-variants]
Nottingham, M., "HTTP Representation Variants", Work in Nottingham, M., "HTTP Representation Variants", Work in
Progress, Internet-Draft, draft-ietf-httpbis-variants-06, Progress, Internet-Draft, draft-ietf-httpbis-variants-06,
3 November 2019, <https://tools.ietf.org/html/draft-ietf- 3 November 2019, <https://tools.ietf.org/html/draft-ietf-
httpbis-variants-06>. httpbis-variants-06>.
[IANA.media-types] [IANA.media-types]
IANA, "Media Types", IANA, "Media Types",
<http://www.iana.org/assignments/media-types>. <http://www.iana.org/assignments/media-types>.
[INFRA] WHATWG, "Infra", May 2021, [INFRA] WHATWG, "Infra", June 2021,
<https://infra.spec.whatwg.org/>. <https://infra.spec.whatwg.org/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
skipping to change at page 15, line 44 skipping to change at page 15, line 24
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[URL] WHATWG, "URL", May 2021, <https://url.spec.whatwg.org/>. [URL] WHATWG, "URL", June 2021, <https://url.spec.whatwg.org/>.
7.2. Informative References 7.2. Informative References
[I-D.yasskin-wpack-use-cases] [I-D.yasskin-wpack-use-cases]
Yasskin, J., "Use Cases and Requirements for Web Yasskin, J., "Use Cases and Requirements for Web
Packages", Work in Progress, Internet-Draft, draft- Packages", Work in Progress, Internet-Draft, draft-
yasskin-wpack-use-cases-02, 13 April 2021, yasskin-wpack-use-cases-02, 13 April 2021,
<https://tools.ietf.org/html/draft-yasskin-wpack-use- <https://tools.ietf.org/html/draft-yasskin-wpack-use-
cases-02>. cases-02>.
Appendix A. Change Log Appendix A. Change Log
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
draft-01
* Turned the top-level primary URL into an optional section.
draft-00 draft-00
* No changes from draft-yasskin-wpack-bundled-exchanges-04. * No changes from draft-yasskin-wpack-bundled-exchanges-04.
draft-yasskin-wpack-bundled-exchanges-04 draft-yasskin-wpack-bundled-exchanges-04
* Rewrite to be more declarative and less algorithmic. * Rewrite to be more declarative and less algorithmic.
* Make a bundle represent a set of HTTP Representations, with the * Make a bundle represent a set of HTTP Representations, with the
Content-Location replacing what was the request URL, and the Content-Location replacing what was the request URL, and the
skipping to change at page 17, line 5 skipping to change at page 16, line 34
* Retitle to "web bundles". * Retitle to "web bundles".
draft-yasskin-wpack-bundled-exchanges-02 draft-yasskin-wpack-bundled-exchanges-02
* Fix the initial bytes of the format. * Fix the initial bytes of the format.
* Allow empty responses to omit their content type. * Allow empty responses to omit their content type.
* Provisionally register application/webbundle. * Provisionally register application/webbundle.
draft-yasskin-wpack-bundled-exchanges-01
* Include only section lengths in the section index, requiring * Include only section lengths in the section index, requiring
sections to be listed in order. sections to be listed in order.
* Have the "index" section map URLs to sets of responses negotiated * Have the "index" section map URLs to sets of responses negotiated
using the Variants system ([I-D.ietf-httpbis-variants]). using the Variants system ([I-D.ietf-httpbis-variants]).
* Require the "manifest" to be embedded into the bundle. * Require the "manifest" to be embedded into the bundle.
* Add a content sniffing security consideration. * Add a content sniffing security consideration.
 End of changes. 30 change blocks. 
37 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/