idnits 2.17.1 draft-ietf-wpack-bundled-responses-00.txt: -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 May 2021) is 1079 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-15 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-variants' -- Possible downref: Non-RFC (?) normative reference: ref. 'INFRA' ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Possible downref: Non-RFC (?) normative reference: ref. 'URL' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yasskin 3 Internet-Draft Google 4 Intended status: Standards Track 6 May 2021 5 Expires: 7 November 2021 7 Web Bundles 8 draft-ietf-wpack-bundled-responses-00 10 Abstract 12 Web bundles provide a way to bundle up groups of HTTP responses, with 13 the request URLs and content negotiation that produced them, to 14 transmit or store together. They can include multiple top-level 15 resources with one identified as the default by a primaryUrl 16 metadata, provide random access to their component exchanges, and 17 efficiently store 8-bit resources. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Discussion of this document takes place on the Web Packaging Working 24 Group mailing list (wpack@ietf.org), which is archived at 25 https://mailarchive.ietf.org/arch/browse/wpack/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/wpack-wg/bundled-responses. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 7 November 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 65 2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. Naming a representation . . . . . . . . . . . . . . . . . 3 68 3. Expected performance . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Random access . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Streaming . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.1. Top-level structure . . . . . . . . . . . . . . . . . . . 4 73 4.1.1. Trailing length . . . . . . . . . . . . . . . . . . . 6 74 4.1.2. Draft version numbers . . . . . . . . . . . . . . . . 6 75 4.2. Bundle sections . . . . . . . . . . . . . . . . . . . . . 6 76 4.2.1. The index section . . . . . . . . . . . . . . . . . . 7 77 4.2.2. The manifest section . . . . . . . . . . . . . . . . 9 78 4.2.3. The critical section . . . . . . . . . . . . . . . . 9 79 4.3. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.4. Serving constraints . . . . . . . . . . . . . . . . . . . 10 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 5.1. Version skew . . . . . . . . . . . . . . . . . . . . . . 10 83 5.2. Content sniffing . . . . . . . . . . . . . . . . . . . . 11 84 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. Internet Media Type Registration . . . . . . . . . . . . 12 86 6.2. Web Bundle Section Name Registry . . . . . . . . . . . . 13 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 7.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 91 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 To satisfy the use cases in [I-D.yasskin-wpack-use-cases], this 97 document proposes a new bundling format to group HTTP resources. The 98 format is structured as an initial table of "sections" within the 99 bundle followed by the content of those sections. 101 1.1. Terminology and Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 This specification uses the conventions and terminology defined in 110 the Infra Standard ([INFRA]). 112 2. Semantics 114 A bundle is logically a set of HTTP representations (Section 7 of 115 [I-D.ietf-httpbis-semantics]), themselves represented by HTTP 116 response messages (Section 2.1 of [I-D.ietf-httpbis-semantics]). The 117 bundle can include an optional URL identifying the primary resource 118 within the bundle and can include other optional metadata. 119 Particular applications can require that the primary URL and/or other 120 metadata is present. 122 While the order of the representations is not semantically 123 meaningful, it can significantly affect performance when the bundle 124 is loaded from a network stream. 126 2.1. Operations 128 Bundle parsers support two primary operations: 130 1. They can load the bundle's metadata given a prefix of the bundle. 132 2. They can find a representation within the bundle given that 133 representation's URL (Section 2.2) and the content-negotiation 134 information that would appear in an HTTP request's headers. 136 2.2. Naming a representation 138 Representations within a bundle are named by their "Content-Location" 139 (Section 7.8 of [I-D.ietf-httpbis-semantics]), which holds a URL. 140 This is also known as the representation's URL. 142 Multiple representations within a bundle can have the same URL, in 143 which case they are distinguished by the content negotiation 144 information contained in their "Variants" and "Variant-Key" headers 145 ([I-D.ietf-httpbis-variants]). 147 This identifying information for each representation is stored in an 148 index (Section 4.2.1) rather than in that representation's HTTP 149 response message. 151 3. Expected performance 153 Bundles can be used in two different situations: they can be loaded 154 from storage that provides O(1) access to any byte within the bundle, 155 or they can be sent across a stream that provides bytes 156 incrementally. An implementation MAY prefer either or both 157 situations and SHOULD provide the following performance 158 characteristics in its preferred situations: 160 3.1. Random access 162 To load a resource when seeing a bundle for the first time, the 163 implementation reads O(size of the metadata and resource index) 164 before starting to return bytes of the resource. 166 TODO: Is big-O notation the right way to express expectations here? 168 3.2. Streaming 170 When sending a bundle over a stream, the implementation will need to 171 wait until it has the sizes of all contained resources before 172 starting to send the resource index. 174 When reading a bundle from a stream, the implementation starts 175 returning bytes of a resource after receiving O(1) bytes of that 176 resource, which comes after the O(# of resources) bytes of the index. 178 4. Format 180 4.1. Top-level structure 182 A bundle is a CBOR array ([CBORbis]) with the following CDDL ([CDDL]) 183 schema: 185 webbundle = [ 186 magic: h'F0 9F 8C 90 F0 9F 93 A6', 187 version: bytes .size 4, 188 primary-url: whatwg-url, 189 section-lengths: bytes .cbor section-lengths, 190 sections: [* any ], 191 length: bytes .size 8, ; Big-endian number of bytes in the bundle. 192 ] 194 whatwg-url = tstr 196 When serialized, the bundle MUST satisfy the core deterministic 197 encoding requirements from Section 4.2.1 of [CBORbis]. This format 198 does not use floating point values or tags, so this specification 199 does not add any deterministic encoding rules for them. If an item 200 doesn't follow these requirements, or a byte-sequence being decoded 201 as a CBOR item contains extra bytes, the parser MUST signal an error 202 instead of any data it can extract from that item. 204 High-level fields in the bundle format are designed to provide their 205 length-in-bytes before the field starts so that a recipient trying to 206 stream a bundle from the network can always wait for a known number 207 of bytes instead of needing to implement a streaming CBOR parser. 209 The "magic" number is "🌐📦" (U+1F310 U+1F4E6) encoded in UTF-8. With 210 the CBOR initial bytes for the array and bytestring, this makes the 211 format identifiable by looking for "8? 48" (in base 16) followed by 212 that UTF-8 encoding. Parsers MUST only check the initial nibble of 213 the initial "8?" byte in order to accommodate any future version's 214 change in the number of array elements (up to 15). 216 The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII 217 "1" followed by 3 0s) for this version of bundles. If the recipient 218 doesn't support the version in this field, it MUST either ignore the 219 bundle or fetch and use the content of the "primary-url" field 220 instead. 222 The "primary-url" field identifies both a fallback when the recipient 223 doesn't understand the bundle and a default resource inside the 224 bundle to use when the recipient doesn't have more specific 225 instructions. This field MAY be an empty string, although protocols 226 using bundles MAY themselves forbid that empty value. 228 The "section-lengths" and "sections" arrays contain the actual 229 content of the bundle and are defined in Section 4.2. The "section- 230 lengths" array is embedded in a byte string to facilitate reading it 231 from a network. This byte string MUST be less than 8192 (8*1024) 232 bytes long, and parsers MUST NOT load any data from a "section- 233 lengths" item longer than this. 235 The bundle ends with an 8-byte integer holding the length of the 236 whole bundle. 238 4.1.1. Trailing length 240 A bundle ends with an 8-byte CBOR byte string holding a big-endian 241 integer that represents the byte-length of the whole bundle. 243 +------------+-----+----+----+----+----+----+----+----+----+----+ 244 | first byte | ... | 48 | 00 | 00 | 00 | 00 | 00 | BC | 61 | 4E | 245 +------------+-----+----+----+----+----+----+----+----+----+----+ 246 / \ 247 0xBC614E-10=12345668 omitted bytes 249 Figure 1: Example trailing bytes 251 Recipients loading the bundle in a random-access context SHOULD start 252 by reading the last 8 bytes and seeking backwards by that many bytes 253 to find the start of the bundle, instead of assuming that the start 254 of the file is also the start of the bundle. This allows the bundle 255 to be appended to another format such as a generic self-extracting 256 executable. 258 4.1.2. Draft version numbers 260 This section is to be removed before publishing as an RFC. 262 Implementations of drafts of this specification MUST NOT use a 263 "version" string of "31 00 00 00" (base 16). They MUST instead 264 define an implementation-specific 4-byte string starting with "62" 265 ("b") to identify which draft is implemented. 267 4.2. Bundle sections 269 A bundle's content is in a series of sections, which can be accessed 270 randomly using the information in the "section-lengths" CBOR item: 272 section-lengths = [* (section-name: tstr, length: uint) ], 273 This field lists the named sections in the bundle in the order they 274 appear, with each section name followed by the length in bytes of the 275 corresponding CBOR item in the "sections" array. This allows a 276 random-access parser (Section 3) to jump directly to the section it 277 needs. This specification defines the following sections: 279 * ""index"" (Section 4.2.1) 281 * ""manifest"" (Section 4.2.2) 283 * ""critical"" (Section 4.2.3) 285 * ""responses"" (Section 4.3) 287 Future specifications can register new section names as described in 288 Section 6.2, in order to extend the format without incrementing its 289 version number. 291 The ""responses"" section MUST appear after the other three sections 292 defined here, and parsers MUST NOT load any data if that is not the 293 case. 295 The "sections" array contains the sections' content. The length of 296 this array MUST be exactly half the length of the "section-lengths" 297 array, and parsers MUST NOT load any data if that is not the case. 299 The bundle MUST contain the ""index"" and ""responses"" sections. 300 All other sections are optional. 302 4.2.1. The index section 304 index = {* whatwg-url => [ variants-value, +location-in-responses ] } 305 variants-value = bstr 306 location-in-responses = (offset: uint, length: uint) 308 The ""index"" section defines the set of HTTP representations in the 309 bundle and identifies their locations in the ""responses"" section. 310 It consists of a CBOR map whose keys are the URLs of the 311 representations in the bundle (Section 2.2). The value of an index 312 entry is an array whose first item is a "Variants" header field value 313 ([I-D.ietf-httpbis-variants]) or the empty string. This is followed 314 by a sequence of offset/length pairs, one for each representation of 315 this resource. The offset is relative to the start of the 316 ""responses"" section, with an offset of 0 referring to the head of 317 the CBOR "responses" array itself. The length is the length in bytes 318 of the "response" CBOR item holding this representation 319 (Section 4.3). 321 If the first item in the value of an index entry is empty, it MUST be 322 followed by exactly one offset/length pair. This means there is a 323 single representation for this resource, with no content negotiation. 325 Otherwise, the first item MUST be followed by one offset/length pair 326 for each of the possible combinations of available-values within the 327 "Variants" value (the first item of the array) in lexicographic (row- 328 major) order. 330 For example, given a "Variants" value of "accept-encoding=(gzip br), 331 accept-language=(en fr ja)", the list of offset/length pairs will 332 correspond to the "Variant-Key"s: 334 * (gzip en) 336 * (gzip fr) 338 * (gzip ja) 340 * (br en) 342 * (br fr) 344 * (br ja) 346 The order of variant-axes is important. If the "Variants" value were 347 "accept-language=(en fr ja), accept-encoding=(gzip br)" instead, the 348 "location-in-responses" pairs would instead correspond to: 350 * (en gzip) 352 * (en br) 354 * (fr gzip) 356 * (fr br) 358 * (ja gzip) 360 * (ja br) 362 If the wrong number of offset/length pairs is present in a resource's 363 array, the entire index MUST fail to parse. 365 A combination of available-values that is omitted from the bundle 366 MUST be signaled by setting its offset and length to 0. 368 4.2.2. The manifest section 370 manifest = whatwg-url 372 The "manifest" section records a single URL identifying the manifest 373 of the bundle. The URL MUST refer to a resource with representations 374 contained in the bundle itself. 376 The bundle can contain multiple representations at this URL, and the 377 client is expected to content-negotiate for the best one. For 378 example, a client might select the one matching an "accept" header of 379 "application/manifest+json" ([appmanifest]) and an "accept-language" 380 header of "es-419". 382 Many bundles have a choice between identifying their manifest in this 383 section or in their primary resource, especially if that resource is 384 an HTML file. Identifying the manifest in this section can help 385 recipients apply fields in the manifest sooner, for example to show a 386 splash screen before parsing the primary resource. 388 4.2.3. The critical section 390 critical = [*tstr] 392 The "critical" section consists of the names of sections of the 393 bundle that the client needs to understand in order to load the 394 bundle correctly. Other sections are assumed to be optional. 396 If the client has not implemented a section named by one of the items 397 in this list, the client MUST fail to parse the bundle as a whole. 399 4.3. Responses 401 responses = [*response] 402 response = [headers: bstr .cbor headers, payload: bstr] 403 headers = {* bstr => bstr} 405 The "responses" section holds the HTTP responses that represent the 406 HTTP representations in the bundle. It consists of a CBOR array of 407 responses, each of which is pointed to by one or more entries in the 408 "index" section (Section 4.2.1). 410 The length of the "headers" byte string in a response MUST be less 411 than 524288 (512*1024) bytes, and recipients MUST fail to load a 412 response with longer headers. 414 When receiving a bundle in a stream, the recipient MAY process the 415 headers before the payload has been received and MAY start processing 416 the beginning of the payload before the end of the payload has been 417 received. 419 The keys of the headers map MUST consist of lowercase ASCII as 420 described in Section 8.1.2 of [RFC7540]. Response pseudo-headers 421 (Section 8.1.2.4 of [RFC7540] are included in this headers map. 423 Each response's headers MUST include a ":status" pseudo-header with 424 exactly 3 ASCII decimal digits and MUST NOT include any other pseudo- 425 headers. 427 If a response's payload is not empty, its headers MUST include a 428 "Content-Type" header (Section 7.4 of [I-D.ietf-httpbis-semantics]). 429 The client MUST interpret the following payload as this specified 430 media type instead of trying to sniff a media type from the bytes of 431 the payload, for example by appending an artificial "X-Content-Type- 432 Options: nosniff" header field ([FETCH]) to downstream protocols. 434 4.4. Serving constraints 436 When served over HTTP, a response containing an "application/ 437 webbundle" payload MUST include at least the following response 438 header fields, to reduce content sniffing vulnerabilities 439 (Section 5.2): 441 * Content-Type: application/webbundle 443 * X-Content-Type-Options: nosniff 445 5. Security Considerations 447 5.1. Version skew 449 Bundles currently have no mechanism for ensuring that any signed 450 exchanges they contain constitute a consistent version of those 451 resources. Even if a website never has a security vulnerability when 452 resources are fetched at a single time, an attacker might be able to 453 combine a set of resources pulled from different versions of the 454 website to build a vulnerable site. While the vulnerable site could 455 have occurred by chance on a client's machine due to normal HTTP 456 caching, bundling allows an attacker to guarantee that it happens. 457 Future work in this specification might allow a bundle to constrain 458 its resources to come from a consistent version. 460 5.2. Content sniffing 462 While modern browsers tend to trust the "Content-Type" header sent 463 with a resource, especially when accompanied by "X-Content-Type- 464 Options: nosniff", plugins will sometimes search for executable 465 content buried inside a resource and execute it in the context of the 466 origin that served the resource, leading to XSS vulnerabilities. For 467 example, some PDF reader plugins look for "%PDF" anywhere in the 468 first 1kB and execute the code that follows it. 470 The "application/webbundle" format defined above includes URLs and 471 request headers early in the format, which an attacker could use to 472 cause these plugins to sniff a bad content type. 474 To avoid vulnerabilities, in addition to the response header 475 requirements in Section 4.4, servers are advised to only serve an 476 "application/webbundle" resource from a domain if it would also be 477 safe for that domain to serve the bundle's content directly, and to 478 follow at least one of the following strategies: 480 1. Only serve bundles from dedicated domains that don't have access 481 to sensitive cookies or user storage. 483 2. Generate bundles "offline", that is, in response to a trusted 484 author submitting content or existing signatures reaching a 485 certain age, rather than in response to untrusted-reader queries. 487 3. Do all of: 489 1. If the bundle's contained URLs (e.g. in the manifest and 490 index) are derived from the request for the bundle, percent- 491 encode (https://url.spec.whatwg.org/#percent-encode) ([URL]) 492 any bytes that are greater than 0x7E or are not URL code 493 points (https://url.spec.whatwg.org/#url-code-points) ([URL]) 494 in these URLs. It is particularly important to make sure no 495 unescaped nulls (0x00) or angle brackets (0x3C and 0x3E) 496 appear. 498 2. Similarly, if the request headers for any contained resource 499 are based on the headers sent while requesting the bundle, 500 only include request header field names *and values* that 501 appear in a static allowlist. Keep the set of allowed 502 request header fields smaller than 24 elements to prevent 503 attackers from controlling a whole CBOR length byte. 505 3. Restrict the number of items a request can direct the server 506 to include in a bundle to less than 12, again to prevent 507 attackers from controlling a whole CBOR length byte. 509 4. Do not reflect request header fields into the set of response 510 headers. 512 If the server serves responses that are written by a potential 513 attacker but then escaped, the "application/webbundle" format allows 514 the attacker to use the length of the response to control a few bytes 515 before the start of the response. Any existing mechanisms that 516 prevent polyglot documents probably keep working in the face of this 517 new attack, but we don't have a guarantee of that. 519 To encourage servers to include the "X-Content-Type-Options: nosniff" 520 header field, clients SHOULD reject bundles served without it. 522 6. IANA considerations 524 6.1. Internet Media Type Registration 526 IANA is requested to register the MIME media type 527 ([IANA.media-types]) for web bundles, application/webbundle, as 528 follows: 530 * Type name: application 532 * Subtype name: webbundle 534 * Required parameters: 536 - v: A string denoting the version of the file format. 537 ([RFC5234] ABNF: "version = 1*(DIGIT/%x61-7A)") The version 538 defined in this specification is "1". 540 Note: RFC EDITOR PLEASE DELETE THIS NOTE; Implementations of 541 drafts of this specification MUST NOT use simple integers to 542 describe their versions, and MUST instead define 543 implementation-specific strings to identify which draft is 544 implemented. 546 * Optional parameters: N/A 548 * Encoding considerations: binary 550 * Security considerations: See Section 5 of this document. 552 * Interoperability considerations: N/A 554 * Published specification: This document 555 * Applications that use this media type: None yet, but it is 556 expected that web browsers will use this format. 558 * Fragment identifier considerations: N/A 560 * Additional information: 562 - Deprecated alias names for this type: N/A 564 - Magic number(s): 86 48 F0 9F 8C 90 F0 9F 93 A6 566 - File extension(s): .wbn 568 - Macintosh file type code(s): N/A 570 * Person & email address to contact for further information: See the 571 Author's Address section of this specification. 573 * Intended usage: COMMON 575 * Restrictions on usage: N/A 577 * Author: See the Author's Address section of this specification. 579 * Change controller: The IESG iesg@ietf.org (mailto:iesg@ietf.org) 581 * Provisional registration? Yes. 583 6.2. Web Bundle Section Name Registry 585 IANA is directed to create a new registry with the following 586 attributes: 588 Name: Web Bundle Section Names 590 Review Process: Specification Required 592 Initial Assignments: 594 +==============+===============+ 595 | Section Name | Specification | 596 +==============+===============+ 597 | "index" | Section 4.2.1 | 598 +--------------+---------------+ 599 | "manifest" | Section 4.2.2 | 600 +--------------+---------------+ 601 | "critical" | Section 4.2.3 | 602 +--------------+---------------+ 603 | "responses" | Section 4.3 | 604 +--------------+---------------+ 606 Table 1 608 Requirements on new assignments: 610 Section Names MUST be encoded in UTF-8. 612 A section's specification MAY say that, if it is present, another 613 section is not processed. 615 7. References 617 7.1. Normative References 619 [appmanifest] 620 Caceres, M., Christiansen, K., Lamouri, M., Kostiainen, 621 A., Dolin, R., and M. Giuca, "Web App Manifest", World 622 Wide Web Consortium WD WD-appmanifest-20180523, 23 May 623 2018, 624 . 626 [CBORbis] Bormann, C. and P. Hoffman, "Concise Binary Object 627 Representation (CBOR)", STD 94, RFC 8949, 628 DOI 10.17487/RFC8949, December 2020, 629 . 631 [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 632 Definition Language (CDDL): A Notational Convention to 633 Express Concise Binary Object Representation (CBOR) and 634 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 635 June 2019, . 637 [FETCH] WHATWG, "Fetch", May 2021, 638 . 640 [I-D.ietf-httpbis-semantics] 641 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 642 Semantics", Work in Progress, Internet-Draft, draft-ietf- 643 httpbis-semantics-15, 30 March 2021, 644 . 647 [I-D.ietf-httpbis-variants] 648 Nottingham, M., "HTTP Representation Variants", Work in 649 Progress, Internet-Draft, draft-ietf-httpbis-variants-06, 650 3 November 2019, . 653 [IANA.media-types] 654 IANA, "Media Types", 655 . 657 [INFRA] WHATWG, "Infra", May 2021, 658 . 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, 662 DOI 10.17487/RFC2119, March 1997, 663 . 665 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 666 Specifications: ABNF", STD 68, RFC 5234, 667 DOI 10.17487/RFC5234, January 2008, 668 . 670 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 671 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 672 DOI 10.17487/RFC7540, May 2015, 673 . 675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 676 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 677 May 2017, . 679 [URL] WHATWG, "URL", May 2021, . 681 7.2. Informative References 683 [I-D.yasskin-wpack-use-cases] 684 Yasskin, J., "Use Cases and Requirements for Web 685 Packages", Work in Progress, Internet-Draft, draft- 686 yasskin-wpack-use-cases-02, 13 April 2021, 687 . 690 Appendix A. Change Log 692 This section is to be removed before publishing as an RFC. 694 draft-00 696 * No changes from draft-yasskin-wpack-bundled-exchanges-04. 698 draft-yasskin-wpack-bundled-exchanges-04 700 * Rewrite to be more declarative and less algorithmic. 702 * Make a bundle represent a set of HTTP Representations, with the 703 Content-Location replacing what was the request URL, and the 704 Variants information, as before, driving content negotiation. 706 * Make the primary URL optional. 708 * Remove the signatures section. 710 * Update Variants examples for the latest Variants draft. 712 * Removed the distinction between "metadata" and non-metadata 713 sections. 715 draft-yasskin-wpack-bundled-exchanges-03 717 * Make the manifest optional. 719 * Update the reference to draft-yasskin-wpack-use-cases. 721 * Retitle to "web bundles". 723 draft-yasskin-wpack-bundled-exchanges-02 725 * Fix the initial bytes of the format. 727 * Allow empty responses to omit their content type. 729 * Provisionally register application/webbundle. 731 * Include only section lengths in the section index, requiring 732 sections to be listed in order. 734 * Have the "index" section map URLs to sets of responses negotiated 735 using the Variants system ([I-D.ietf-httpbis-variants]). 737 * Require the "manifest" to be embedded into the bundle. 739 * Add a content sniffing security consideration. 741 * Add a version string to the format and its mime type. 743 * Add a fallback URL in a fixed location in the format, and use that 744 fallback URL as the primary URL of the bundle. 746 * Add a "signatures" section to let authorities (like domain-trusted 747 X.509 certificates) vouch for subsets of a bundle. 749 * Use the CBORbis "deterministic encoding" requirements instead of 750 "canonicalization" requirements. 752 Appendix B. Acknowledgements 754 Thanks to the Chrome loading team, especially Kinuko Yasuda and 755 Kouhei Ueno for making the format work well when streamed. 757 Author's Address 759 Jeffrey Yasskin 760 Google 762 Email: jyasskin@chromium.org