idnits 2.17.1 draft-ietf-dispatch-javascript-mjs-17.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (2 March 2022) is 784 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4329 (Obsoleted by RFC 9239) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH M. Miller 3 Internet-Draft 4 Obsoletes: 4329 (if approved) M. Borins 5 Intended status: Informational GitHub 6 Expires: 3 September 2022 M. Bynens 7 Google 8 B. Farias 9 2 March 2022 11 ECMAScript Media Types Updates 12 draft-ietf-dispatch-javascript-mjs-17 14 Abstract 16 This document describes the registration of media types for the 17 ECMAScript and JavaScript programming languages and conformance 18 requirements for implementations of these types. This document 19 obsoletes RFC4329, "Scripting Media Types", replacing the previous 20 registrations for "text/javascript" and "application/javascript" with 21 information and requirements aligned with common usage and 22 implementation experiences. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 3 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Charset Parameter . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Character Encoding Scheme Detection . . . . . . . . . . . 5 64 4.3. Character Encoding Scheme Error Handling . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Common JavaScript Media Types . . . . . . . . . . . . . . 10 68 6.1.1. text/javascript . . . . . . . . . . . . . . . . . . . 10 69 6.2. Historic JavaScript Media Types . . . . . . . . . . . . . 11 70 6.2.1. text/ecmascript . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 7.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 75 Appendix B. Changes from RFC 4329 . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 This memo describes media types for the JavaScript and ECMAScript 81 programming languages. Refer to the sections "Introduction" and 82 "Overview" in [ECMA-262] for background information on these 83 languages. This document updates the descriptions and registrations 84 for these media types to reflect existing usage on the Internet, and 85 provides up-to-date security considerations. 87 This document replaces the media types registrations in [RFC4329], 88 and updates the requirements for implementations using those media 89 types defined in [RFC4329] based on current existing practices. As a 90 consequence, this document obsoletes [RFC4329]. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 2. Compatibility 102 This document defines equivalent processing requirements for the 103 types text/javascript, text/ecmascript, and application/javascript. 104 The most widely supported media type in use is text/javascript; all 105 others are considered historical and obsolete aliases of text/ 106 javascript. 108 The types defined in this document are applicable to scripts written 109 in [ECMA-262]. New editions of [ECMA-262] are subjected to strong 110 obligations of backward compatibility, imposed by the standardization 111 process of Ecma International's Technical Committee 39 (TC39). As a 112 result, JavaScript code based on an earlier edition is generally 113 compatible with a JavaScript engine adhering to a later edition. The 114 few exceptions to this are documented in [ECMA-262] in the section 115 "Additions and Changes That Introduce Incompatibilities with Prior 116 Editions". JavaScript developers commonly use feature detection to 117 ensure modern JavaScript features are only used when available in the 118 current environment. Later editions of [ECMA-262] are not directly 119 addressed in this document, although it is expected that 120 implementations will behave as if applicability were extended to 121 them. This document does not address other extensions to [ECMA-262] 122 or scripts written in other languages. 124 This document may be updated to take other content into account. 125 Updates of this document may introduce new optional parameters; 126 implementations must consider the impact of such an update. 128 This document does not define how fragment identifiers in resource 129 identifiers ([RFC3986], [RFC3987]) for documents labeled with one of 130 the media types defined in this document are resolved. An update of 131 this document may define processing of fragment identifiers. 133 Note that this use of the "text" media type tree willfully does not 134 align with its original intent per [RFC2045]. The reason for this is 135 historical. [RFC4329] registered both the text/* and application/* 136 types, marking the text/* ones obsolete. This was done to encourage 137 people toward application/*, matching the guidance in [RFC4288], the 138 predecessor to [RFC6838]. Since then, however, the industry widely 139 adopted text/* anyway. The definitions in this document reflect the 140 current state of implementation across the JavaScript ecosystem, in 141 web browsers and other environments such as Node.js alike, in order 142 to guarantee backwards compatibility with existing applications as 143 much as possible. Future registrations should not view this as a 144 repeatable precedent. 146 3. Modules 148 In order to formalize support for modular programs, [ECMA-262] 149 (starting with 6th Edition) defines two top-level goal symbols (or 150 roots to the abstract syntax tree) for the ECMAScript grammar: Module 151 and Script. The Script goal represents the original structure where 152 the code executes in the global scope, while the Module goal 153 represents the module system built into ECMAScript starting with 6th 154 Edition. See the section "ECMAScript Language: Scripts and Modules" 155 of [ECMA-262] for details. 157 This separation means that (in the absence of additional information) 158 there are two possible interpretations for any given ECMAScript 159 source text. 161 Ecma International's Technical Committee 39 (TC39), the standards 162 body in charge of ECMAScript, has determined that media types are 163 outside of their scope of work [TC39-MIME-ISSUE]. 165 It is not possible to fully determine if a source text of ECMAScript 166 is meant to be parsed using the Module or Script grammar goals based 167 upon content or media type alone. Therefore, as permitted by the 168 media types in this document, scripting environments use out-of-band 169 information in order to determine what goal should be used. Some 170 scripting environments have chosen to adopt the file extension of 171 .mjs for this purpose. 173 4. Encoding 175 Refer to [RFC6365] for a discussion of terminology used in this 176 section. Source text (as defined in [ECMA-262], section "Source 177 Text") can be binary source text. Binary source text is a textual 178 data object that represents source text encoded using a character 179 encoding scheme. A textual data object is a whole text protocol 180 message or a whole text document, or a part of it, that is treated 181 separately for purposes of external storage and retrieval. An 182 implementation's internal representation of source text is not 183 considered binary source text. 185 Implementations need to determine a character encoding scheme in 186 order to decode binary source text to source text. The media types 187 defined in this document allow an optional charset parameter to 188 explicitly specify the character encoding scheme used to encode the 189 source text. 191 In order to ensure interoperability and align with widespread 192 implementation practices, the charset parameter is optional rather 193 than required, despite the recommendation in BCP 13 [RFC6838] for 194 text/* types. 196 How implementations determine the character encoding scheme can be 197 subject to processing rules that are out of the scope of this 198 document. For example, transport protocols can require that a 199 specific character encoding scheme is to be assumed if the optional 200 charset parameter is not specified, or they can require that the 201 charset parameter is used in certain cases. Such requirements are 202 not defined by this document. 204 Implementations that support binary source text MUST support binary 205 source text encoded using the UTF-8 [RFC3629] character encoding 206 scheme. Module goal sources MUST be encoded as UTF-8; all other 207 encodings will fail. Source goal sources SHOULD be encoded as UTF-8; 208 other character encoding schemes MAY be supported, but are 209 discouraged. Whether U+FEFF is processed as a Byte Order Mark (BOM) 210 signature or not depends on the host environment, and is not defined 211 by this document. 213 4.1. Charset Parameter 215 The charset parameter provides a means to specify the character 216 encoding scheme of binary source text. If present, the value of the 217 charset parameter MUST be a registered charset [CHARSETS], and is 218 considered valid if it matches the mime-charset production defined in 219 [RFC2978], section 2.3. 221 The charset parameter is only used when processing a Script goal 222 source; Module goal sources MUST always be processed as UTF-8. 224 4.2. Character Encoding Scheme Detection 226 It is possible that implementations cannot interoperably determine a 227 single character encoding scheme simply by complying with all 228 requirements of the applicable specifications. To foster 229 interoperability in such cases, the following algorithm is defined. 230 Implementations apply this algorithm until a single character 231 encoding scheme is determined. 233 1. If the binary source text is not already determined to be using a 234 Module goal and starts with a Unicode encoding form signature, 235 the signature determines the encoding. The following octet 236 sequences, at the very beginning of the binary source text, are 237 considered with their corresponding character encoding schemes: 239 +------------------+----------+ 240 | Leading sequence | Encoding | 241 |------------------+----------| 242 | EF BB BF | UTF-8 | 243 | FF FE | UTF-16LE | 244 | FE FF | UTF-16BE | 245 +------------------+----------+ 247 Implementations of this step MUST use these octet sequences to 248 determine the character encoding scheme, even if the determined 249 scheme is not supported. If this step determines the character 250 encoding scheme, the octet sequence representing the Unicode 251 encoding form signature MUST be ignored when decoding the binary 252 source text. 254 2. Else, if a charset parameter is specified and its value is valid 255 and supported by the implementation, the value determines the 256 character encoding scheme. 258 3. Else, the character encoding scheme is assumed to be UTF-8. 260 If the character encoding scheme is determined to be UTF-8 through 261 any means other than step 1 as defined above and the binary source 262 text starts with the octet sequence EF BB BF, the octet sequence is 263 ignored when decoding the binary source text. 265 4.3. Character Encoding Scheme Error Handling 267 Binary source text that is not properly encoded for the determined 268 character encoding can pose a security risk, as discussed in section 269 5. That said, because of the varied and complex environments scripts 270 are executed in, most of the error handling specifics are left to the 271 processors. The following are broad guidelines that processors 272 follow. 274 If binary source text is determined to have been encoded using a 275 certain character encoding scheme that the implementation is unable 276 to process, implementations can consider the resource unsupported 277 (i.e., do not decode the binary source text using a different 278 character encoding scheme). 280 Binary source text can be determined to have been encoded using a 281 certain character encoding scheme but contain octet sequences that 282 are not valid according to that scheme. Implementations can 283 substitute those invalid sequences with the replacement character 284 U+FFFD (properly encoded for the scheme), or stop processing 285 altogether. 287 5. Security Considerations 289 Refer to [RFC3552] for a discussion of terminology used in this 290 section. Examples in this section and discussions of interactions of 291 host environments with scripts, modules, and extensions to [ECMA-262] 292 are to be understood as non-exhaustive and of a purely illustrative 293 nature. 295 The programming language defined in [ECMA-262] is not intended to be 296 computationally self-sufficient, rather, it is expected that the 297 computational environment provides facilities to programs to enable 298 specific functionality. Such facilities constitute unknown factors 299 and are thus not defined by this document. 301 Derived programming languages are permitted to include additional 302 functionality that is not described in [ECMA-262]; such functionality 303 constitutes an unknown factor and is thus not defined by this 304 document. In particular, extensions to [ECMA-262] defined for the 305 JavaScript programming language are not discussed in this document. 307 Uncontrolled execution of scripts can be exceedingly dangerous. 308 Implementations that execute scripts MUST give consideration to their 309 application's threat models and those of the individual features they 310 implement; in particular, they MUST ensure that untrusted content is 311 not executed in an unprotected environment. 313 Module scripts in ECMAScript can request the fetching and processing 314 of additional scripts, called importing. Implementations that 315 support modules need to process imported sources in the same way as 316 scripts. See the section "ECMAScript Language: Scripts and Modules" 317 in [ECMA-262] for details. Further, there may be additional privacy 318 and security concerns depending on the location(s) the original 319 script and its imported modules are obtained from. For instance, a 320 script obtained from "host-a.example" could request to import a 321 script from "host-b.example", which could expose information about 322 the executing environment (e.g., IP address) to "host-b.example". 324 Specifications for host environment facilities and for derived 325 programming languages should include security considerations. If an 326 implementation supports such facilities, the respective security 327 considerations apply. In particular, if scripts can be referenced 328 from or included in specific document formats, the considerations for 329 the embedding or referencing document format apply. 331 For example, scripts embedded in application/xhtml+xml [RFC3236] 332 documents could be enabled through the host environment to manipulate 333 the document instance, which could cause the retrieval of remote 334 resources; security considerations regarding retrieval of remote 335 resources of the embedding document would apply in this case. 337 This circumstance can further be used to make information, that is 338 normally only available to the script, available to a web server by 339 encoding the information in the resource identifier of the resource, 340 which can further enable eavesdropping attacks. Implementation of 341 such facilities is subject to the security considerations of the host 342 environment, as discussed above. 344 The programming language defined in [ECMA-262] does include 345 facilities to loop, cause computationally complex operations, or 346 consume large amounts of memory; this includes, but is not limited 347 to, facilities that allow dynamically generated source text to be 348 executed (e.g., the eval() function); uncontrolled execution of such 349 features can cause denial of service, which implementations MUST 350 protect against. 352 With the addition of SharedArrayBuffer objects in ECMAScript version 353 8, it could be possible to implement a high-resolution timer which 354 could lead to certain types of timing and side-channel attacks (e.g., 355 [SPECTRE]). Implementations can take steps to mitigate this concern, 356 such as disabling or removing support for SharedArrayBuffer objects, 357 or take additional steps to ensure access to this shared memory is 358 only accessible between execution contexts that have some form of 359 mutual trust. 361 A host environment can provide facilities to access external input. 362 Scripts that pass such input to the eval() function or similar 363 language features can be vulnerable to code injection attacks. 364 Scripts are expected to protect against such attacks. 366 A host environment can provide facilities to output computed results 367 in a user-visible manner. For example, host environments supporting 368 a graphical user interface can provide facilities that enable scripts 369 to present certain messages to the user. Implementations MUST take 370 steps to avoid confusion of the origin of such messages. In general, 371 the security considerations for the host environment apply in such a 372 case as discussed above. 374 Implementations are required to support the UTF-8 character encoding 375 scheme; the security considerations of [RFC3629] apply. Additional 376 character encoding schemes may be supported; support for such schemes 377 is subject to the security considerations of those schemes. 379 Source text is expected to be in Unicode Normalization Form C. 380 Scripts and implementations MUST consider security implications of 381 unnormalized source text and data. For a detailed discussion of such 382 implications refer to the security considerations in [RFC3629]. 384 Scripts can be executed in an environment that is vulnerable to code 385 injection attacks. For example, a CGI script [RFC3875] echoing user 386 input could allow the inclusion of untrusted scripts that could be 387 executed in an otherwise trusted environment. This threat scenario 388 is subject to security considerations that are out of the scope of 389 this document. 391 The "data" resource identifier scheme [RFC2397], in combination with 392 the types defined in this document, could be used to cause execution 393 of untrusted scripts through the inclusion of untrusted resource 394 identifiers in otherwise trusted content. Security considerations of 395 [RFC2397] apply. 397 Implementations can fail to implement a specific security model or 398 other means to prevent possibly dangerous operations. Such failure 399 could possibly be exploited to gain unauthorized access to a system 400 or sensitive information; such failure constitutes an unknown factor 401 and is thus not defined by this document. 403 6. IANA Considerations 405 The media type registrations herein are divided into two major 406 categories: the sole media type "text/javascript" which is now in 407 common usage, and all of the media types that are obsolete. 409 For both categories, the media types are updated to reference 410 [ECMA-262]. In addition, a new file extension of .mjs is added to 411 the list of file extensions with the restriction that contents should 412 be parsed using the Module goal. Finally, the [HTML] specification 413 uses "text/javascript" as the default media type of ECMAScript when 414 preparing script tags; therefore, "text/javascript" intended usage is 415 to be moved from OBSOLETE to COMMON. 417 These changes are to be reflected in the IANA Media Types registry in 418 accordance with [RFC6838]. All registrations will point to this 419 document as reference. The outdated note stating that the "text/ 420 javascript" media type has been "OBSOLETED in favor of application/ 421 javascript" is to be removed. The outdated note stating that the 422 "text/ecmascript" media type has been "OBSOLETED in favor of 423 application/ecmascript" is to be removed. IANA is requested to add 424 the note "OBSOLETED in favor of text/javascript" to all registrations 425 except "text/javascript". 427 Four of the legacy media types in this document have a subtype 428 starting with the "x-" prefix: 430 * application/x-ecmascript 432 * application/x-javascript 434 * text/x-ecmascript 436 * text/x-javascript 438 Note that these are grandfathered media types registered as per 439 Appendix A of [RFC6838]. These registrations predate BCP 178 440 [RFC6648], which they violate, and are only included in this document 441 for backwards compatibility. 443 6.1. Common JavaScript Media Types 445 6.1.1. text/javascript 447 Type name: text 449 Subtype name: javascript 451 Required parameters: N/A 453 Optional parameters: charset, see section 4.1 of [this document]. 455 Encoding considerations: Binary 456 Security considerations: See section 5 of [this document]. 458 Interoperability considerations: It is expected that implementations 459 will behave as if this registration applies to later editions of 460 [ECMA-262], and its published specification references may be 461 updated accordingly from time to time. Although this expectation 462 is unusual among media type registrations, it matches widespread 463 industry conventions. See section 2 of [this document]. 465 Published specification: [ECMA-262] 467 Applications which use this media type: Script interpreters as 468 discussed in [this document]. 470 Additional information: 472 Deprecated alias names for this type: application/javascript, 473 application/x-javascript, text/javascript1.0, text/javascript1.1, 474 text/javascript1.2, text/javascript1.3, text/javascript1.4, text/ 475 javascript1.5, text/jscript, text/livescript 477 Magic number(s): n/a 479 File extension(s): .js, .mjs 481 Macintosh File Type Code(s): TEXT 483 Person & email address to contact for further information: See 484 Author's Address section of [this document] and [RFC4329]. 486 Intended usage: COMMON 488 Restrictions on usage: The .mjs file extension signals that the file 489 represents a JavaScript module. Execution environments that rely 490 on file extensions to determine how to process inputs parse .mjs 491 files using the Module grammar of [ECMA-262]. 493 Author: See Author's Address section of [this document] and 494 [RFC4329]. 496 Change controller: IESG 498 6.2. Historic JavaScript Media Types 500 The following media types and legacy aliases are added or updated for 501 historical purposes. All herein have an intended usage of OBSOLETE, 502 and are not expected to be in use with modern implementations. 504 6.2.1. text/ecmascript 506 Type name: application 508 Subtype name: ecmascript 510 Required parameters: N/A 512 Optional parameters: charset, see section 4.1 of [this document]. 514 Encoding considerations: Binary 516 Security considerations: See section 5 of [this document]. 518 Interoperability considerations: It is expected that implementations 519 will behave as if this registration applies to later editions of 520 [ECMA-262], and its published specification references may be 521 updated accordingly from time to time. Although this expectation 522 is unusual among media type registrations, it matches widespread 523 industry conventions. See section 2 of [this document]. 525 Published specification: [ECMA-262] 527 Applications which use this media type: Script interpreters as 528 discussed in [this document]. 530 Additional information: 532 Deprecated alias names for this type: application/ecmascript, 533 application/x-ecmascript, text/x-ecmascript 535 Magic number(s): n/a 537 File extension(s): .es, .mjs 539 Macintosh File Type Code(s): TEXT 541 Person & email address to contact for further information: See 542 Author's Address section of [this document] and [RFC4329]. 544 Intended usage: OBSOLETE 546 Restrictions on usage: This media type is obsolete; current 547 implementations should use text/javascript as the only JavaScript/ 548 ECMAScript media type. The .mjs file extension signals that the 549 file represents a JavaScript module. Execution environments that 550 rely on file extensions to determine how to process inputs parse 551 .mjs files using the Module grammar of [ECMA-262]. 553 Author: See Author's Address section of [this document] and 554 [RFC4329]. 556 Change controller: IESG 558 7. References 560 7.1. Normative References 562 [CHARSETS] IANA, "Assigned character sets", n.d., 563 . 565 [ECMA-262] Ecma International, "ECMAScript 2021 language 566 specification, ECMA-262 12th Edition, June 2021", June 567 2021, . 569 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 570 Extensions (MIME) Part One: Format of Internet Message 571 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 572 . 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 580 DOI 10.17487/RFC2397, August 1998, 581 . 583 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 584 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, 585 October 2000, . 587 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 588 Text on Security Considerations", BCP 72, RFC 3552, 589 DOI 10.17487/RFC3552, July 2003, 590 . 592 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 593 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 594 2003, . 596 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 597 Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, 598 December 2005, . 600 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 601 DOI 10.17487/RFC4329, April 2006, 602 . 604 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 605 Internationalization in the IETF", BCP 166, RFC 6365, 606 DOI 10.17487/RFC6365, September 2011, 607 . 609 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 610 "Deprecating the "X-" Prefix and Similar Constructs in 611 Application Protocols", BCP 178, RFC 6648, 612 DOI 10.17487/RFC6648, June 2012, 613 . 615 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 616 Specifications and Registration Procedures", BCP 13, 617 RFC 6838, DOI 10.17487/RFC6838, January 2013, 618 . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 7.2. Informative References 626 [HTML] WHATWG, "HTML Living Standard", August 2017, 627 . 630 [RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media 631 Type", RFC 3236, DOI 10.17487/RFC3236, January 2002, 632 . 634 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface 635 (CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875, 636 October 2004, . 638 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 639 Resource Identifier (URI): Generic Syntax", STD 66, 640 RFC 3986, DOI 10.17487/RFC3986, January 2005, 641 . 643 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 644 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 645 January 2005, . 647 [SPECTRE] Kocher, P., Fogh, A., Gerkin, D., Gruss, D., Haas, W., 648 Hamburg, M., Lipp, M., Mangard, S., Prescher, T., Schwarz, 649 M., and Y. Yarom, "Spectre Attacks: Exploiting Speculative 650 Execution", January 2018, 651 . 653 [TC39-MIME-ISSUE] 654 TC39, "Add `application/javascript+module` mime to remove 655 ambiguity", August 2017, . 658 Appendix A. Acknowledgements 660 This work builds upon its antecedent document, authored by Bjoern 661 Hoehrmann. The authors would like to thank Adam Roach, Alexey 662 Melnikov, Allen Wirfs-Brock, Anne van Kesteren, Ben Campbell, 663 Benjamin Kaduk, Eric Vyncke, Francesca Palombini, James Snell, Kirsty 664 Paine, Mark Nottingham, Murray Kucherawy, Ned Freed, Robert Sparks, 665 and Suresh Krishnan for their guidance and feedback throughout this 666 process. 668 Appendix B. Changes from RFC 4329 670 * Added a section discussing ECMAScript modules and the impact on 671 processing. 673 * Updated the Security Considerations to discuss concerns associated 674 with ECMAScript modules and SharedArrayBuffers. 676 * Updated the character encoding scheme detection to remove 677 normative guidance on its use, to better reflect operational 678 reality. 680 * Changed the intended usage of the media type text/javascript from 681 obsolete to common. 683 * Changed the intended usage for all other script media types to 684 obsolete. 686 * Updated various references where the original has been obsoleted. 688 * Updated references to ECMA-262 to match the version at time of 689 publication. 691 Authors' Addresses 693 Matthew A. Miller 694 Email: linuxwolf+ietf@outer-planes.net 695 Myles Borins 696 GitHub 697 Email: mylesborins@github.com 699 Mathias Bynens 700 Google 701 Email: mths@google.com 703 Bradley Farias 704 Email: bradley.meck@gmail.com