RFC 9239

Updates to ECMAScript Media Types

📅 published May 2022, from ietf

Updates to ECMAScript Media Types 🎀

Okay bestie, this is RFC 9239 🦋 It's from the IETF, it's Informational (not a Standards Track spec), and it came out in May 2022. The ISSN is 2070-1721. The authors are M. Miller, M. Borins (GitHub), M. Bynens (Google), and B. Farias. It obsoletes RFC 4329 ("Scripting Media Types)"), so it replaces those old registrations. The header doesn't list anything it updates. 💅

Abstract ✨

This doc is all about registering media types for ECMAScript and JavaScript, plus the conformance requirements for implementations of those types. It obsoletes RFC 4329 ("Scripting Media Types)") and swaps in new registrations and requirements that match what people actually do and what implementers have actually learned. 🌸

IESG Note 📝

This note explains the relationship between Ecma International's Technical Committee 39 work and the media types used to identify the relevant payloads. 🧚

That relationship was built outside the IETF, so it's not lined up with the best practices of BCP 13, which is kind of a lot 💀 The IETF agreed it's worth documenting the relationship and updating the matching IANA registrations anyway. Just know this is not an IETF endorsement of the media types picked for this work. 🙈

Status of This Memo 🦋

This document is not an Internet Standards Track specification. It's published for informational purposes. ✨

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious. 🎀

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9239. 🌈

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License. ⚖️

Table of Contents 📜

1.  Introduction
  1.1.  Terminology
2.  Compatibility
3.  Modules
4.  Encoding
  4.1.  Charset Parameter
  4.2.  Character Encoding Scheme Detection
  4.3.  Character Encoding Scheme Error Handling
5.  Security Considerations
6.  IANA Considerations
  6.1.  Common JavaScript Media Types
    6.1.1.  text/javascript
  6.2.  Historic JavaScript Media Types
    6.2.1.  text/ecmascript
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Changes from RFC 4329
Acknowledgements
Authors' Addresses

1. Introduction 🌸

Okay so this memo describes media types for the JavaScript and ECMAScript programming languages. If you want background on these languages, check the sections "Introduction" and "Overview" in [ECMA-262]. This document updates the descriptions and registrations for these media types so they match how people actually use them on the Internet, and it gives you up-to-date security considerations. 💖

This document replaces the media type registrations in [RFC4329] and updates the requirements for implementations that use those media types, which were defined in [RFC4329], based on what's happening in practice right now. Because of that, this document obsoletes [RFC4329]. ✨

1.1. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥

2. Compatibility 💅

This document defines equivalent processing requirements for the various script media types. The most widely supported media type in use is text/javascript. Everything else is considered historical and obsolete aliases of text/javascript. 👑

The types defined in this document apply to scripts written in [ECMA-262]. New editions of [ECMA-262] come with strong backward compatibility obligations, enforced by the standardization process of Ecma International's Technical Committee 39 (TC39). So JavaScript code written for an earlier edition is generally compatible with a JavaScript engine that follows a later edition. There are a few exceptions, and they're documented in [ECMA-262] in the section "Additions and Changes That Introduce Incompatibilities with Prior Editions". JavaScript developers often use feature detection so modern features only get used when the current environment supports them. ✨ Later editions of [ECMA-262] aren't directly addressed in this document, but implementations are expected to behave as if its applicability were extended to them. This document doesn't cover other extensions to [ECMA-262] or scripts written in other languages. 🌈

This document may be updated to take other content into account. Updates of this document may introduce new optional parameters, and implementations must consider the impact of such an update. 🦋

This document does not define how fragment identifiers in resource identifiers [RFC3986] [RFC3987] are resolved for documents labeled with one of the media types defined here. An update of this document may define how fragment identifiers get processed. 🧚

Note that this use of the "text" media type tree willfully does not line up with its original intent per [RFC2045], and the reason is historical. [RFC4329] registered both the text/* and application/* types and marked the text/* types obsolete. The goal was to push people toward application/, which matched the guidance in [RFC4288], the predecessor to [RFC6838]. But the industry widely adopted text/ anyway. The definitions here reflect where the JavaScript ecosystem actually is, in web browsers and in environments like Node.js alike, so existing applications stay backward compatible as much as possible. Future registrations should not treat this as a repeatable precedent. 🙅‍♀️

3. Modules 🌷

To formalize support for modular programs, [ECMA-262] (starting with the 6th Edition) defines two top-level goal symbols (or roots to the abstract syntax tree) for the ECMAScript grammar: Module and Script. The Script goal is the original structure, where code runs in the global scope. The Module goal is the module system built into ECMAScript starting with the 6th Edition. For details, see the section "ECMAScript Language: Scripts and Modules" in [ECMA-262]. 📦

Because of this split, and without extra information, any given ECMAScript source text could be read in two different ways. 🤔

Ecma International's Technical Committee 39 (TC39), the standards body in charge of ECMAScript, has decided that media types are outside their scope of work [TC39-MIME-ISSUE]. 🙃

You can't fully tell whether ECMAScript source text is meant to be parsed with the Module or Script grammar goal just from its content or media type. So, as the media types in this document allow, scripting environments use out-of-band information to decide which goal to use. Some scripting environments have chosen the file extension .mjs for this purpose. 🍓

4. Encoding 🎀

Refer to [RFC6365] for a discussion of the terminology used in this section. Source text (as defined in the section "Source Text" in [ECMA-262]) can be binary source text. Binary source text is a textual data object that represents source text encoded with a character encoding scheme. A textual data object is a whole text protocol message or a whole text document, or a part of one, that gets handled separately for external storage and retrieval. An implementation's internal representation of source text does not count as binary source text. 💜

Implementations need to determine a character encoding scheme in order to decode binary source text into source text. The media types defined in this document allow an optional charset parameter to explicitly specify the character encoding scheme used to encode the source text. 🌸

To ensure interoperability and line up with widespread implementation practice, the charset parameter is optional rather than required, even though BCP 13 [RFC6838] recommends it for text/* types. 🦋

How implementations determine the character encoding scheme can be subject to processing rules that are outside the scope of this document. For example, transport protocols can require that a specific character encoding scheme be assumed if the optional charset parameter is not specified, or they can require that the charset parameter be used in certain cases. This document does not define those requirements. 🧚

Implementations that support binary source text MUST support binary source text encoded using the UTF-8 [RFC3629] character encoding scheme. Module goal sources MUST be encoded as UTF-8; all other encodings will fail. Script goal sources SHOULD be encoded as UTF-8; other character encoding schemes MAY be supported but are discouraged. Whether U+FEFF is processed as a Byte Order Mark (BOM) signature or not depends on the host environment and is not defined by this document. 🔥

4.1. Charset Parameter 💖

The charset parameter lets you specify the character encoding scheme of binary source text. If it's present, the value of the charset parameter MUST be a registered charset [CHARSETS], and it's considered valid if it matches the mime-charset production defined in Section 2.3 of [RFC2978]. ✨

The charset parameter is only used when processing a Script goal source. Module goal sources MUST always be processed as UTF-8. 🌈

4.2. Character Encoding Scheme Detection ✨

okay so it's possible that implementations can't all land on one single character encoding scheme just by following every requirement in the applicable specs 🥺. to keep everyone on the same page, there's a little algorithm defined here. implementations run it until exactly one character encoding scheme is determined 💅

  1. okay step one 🎀: if the binary source text is not already determined to be using a Module goal and starts with a Unicode encoding form signature, the signature decides the encoding. these octet sequences, at the very beginning of the binary source text, get matched with their character encoding schemes:
+==================+==========+
| Leading sequence | Encoding |
+==================+==========+
| EF BB BF         | UTF-8    |
+------------------+----------+
| FF FE            | UTF-16LE |
+------------------+----------+
| FE FF            | UTF-16BE |
+------------------+----------+

            Table 1

Implementations of this step MUST use these octet sequences to determine the character encoding scheme, even if the determined scheme is not supported 🙈. If this step determines the character encoding scheme, the octet sequence representing the Unicode encoding form signature MUST be ignored when decoding the binary source text. no skipping the signature after that, bestie 🫶

  1. else, if a charset parameter is specified and its value is valid and supported by the implementation, the value determines the character encoding scheme ✨
  2. else, the character encoding scheme is assumed to be UTF-8 🌸

If the character encoding scheme is determined to be UTF-8 through any means other than step 1 as defined above and the binary source text starts with the octet sequence EF BB BF, the octet sequence is ignored when decoding the binary source text. so the BOM-looking bytes get tossed when they're not coming from step 1 💖

4.3. Character Encoding Scheme Error Handling 🙈

okay the vibe here is that binary source text that isn't properly encoded for the determined character encoding can pose a security risk, as discussed in Section 5 😬. BUT because scripts get run in so many varied and complicated environments, most of the error handling specifics are left up to the processors 🧚. the stuff below is just the broad guidelines processors follow.

If binary source text is determined to have been encoded using a certain character encoding scheme that the implementation is unable to process, implementations can consider the resource unsupported (i.e., do not decode the binary source text using a different character encoding scheme) 🍓

Binary source text can be determined to have been encoded using a certain character encoding scheme but contain octet sequences that are not valid according to that scheme. Implementations can substitute those invalid sequences with the replacement character U+FFFD (properly encoded for the scheme) or stop processing altogether. so you've got options, but you still have to pick one 💅

5. Security Considerations 💀

okay this section is serious, so get comfy 🫶. refer to [RFC3552] for a discussion of terminology used in this section. examples in this section and discussions of interactions of host environments with scripts, modules, and extensions to [ECMA-262] are to be understood as non-exhaustive and of a purely illustrative nature ✨

the programming language defined in [ECMA-262] is not intended to be computationally self-sufficient 🙈. instead, it's expected that the computational environment provides facilities to programs to enable specific functionality. those facilities are unknown factors, so this document doesn't define them.

derived programming languages are permitted to include additional functionality that is not described in [ECMA-262] 🌈. that functionality is also an unknown factor, so this document doesn't define it either. in particular, extensions to [ECMA-262] defined for the JavaScript programming language aren't discussed in this document.

uncontrolled execution of scripts can be exceedingly dangerous 😭🚨. implementations that execute scripts MUST give consideration to their application's threat models and those of the individual features they implement. in particular, they MUST ensure that untrusted content is not executed in an unprotected environment. this part is non-negotiable, periodt 💅

module scripts in ECMAScript can request the fetching and processing of additional scripts; this is called "importing". implementations that support modules need to process imported sources in the same way as scripts. see the section "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details. further, there may be additional privacy and security concerns, depending on the location(s) the original script and its imported modules are obtained from 👀. for instance, a script obtained from host-a.example could request to import a script from host-b.example, which could expose information about the executing environment (e.g., IP address) to host-b.example. it's giving "who's looking at my IP" energy 🙈

specifications for host environment facilities and for derived programming languages should include security considerations 🔍. if an implementation supports such facilities, the respective security considerations apply. in particular, if scripts can be referenced from or included in specific document formats, the considerations for the embedding or referencing document format apply.

for example, scripts embedded in application/xhtml+xml [RFC3236] documents could be enabled through the host environment to manipulate the document instance, which could cause the retrieval of remote resources 🦋. security considerations regarding retrieval of remote resources of the embedding document would apply in this case.

this circumstance can further be used to make information that is normally only available to the script also available to a web server 😳. it does this by encoding the information in the resource identifier of the resource, which can further enable eavesdropping attacks. implementation of such facilities is subject to the security considerations of the host environment, as discussed above.

the programming language defined in [ECMA-262] does include facilities to loop, cause computationally complex operations, or consume large amounts of memory 🌀. this includes, but is not limited to, facilities that allow dynamically generated source text to be executed (e.g., the eval() function). uncontrolled execution of such features can cause denial of service, which implementations MUST protect against. this is a MUST, bestie 🚨

with the addition of SharedArrayBuffer objects in ECMAScript version 8, it could be possible to implement a high-resolution timer 🕰️. that could lead to certain types of timing and side-channel attacks (e.g., [SPECTRE]). implementations can take steps to mitigate this concern, such as disabling or removing support for SharedArrayBuffer objects, or can take additional steps to ensure that this shared memory is only accessible between execution contexts that have some form of mutual trust.

a host environment can provide facilities to access external input 📥. scripts that pass such input to the eval() function or similar language features can be vulnerable to code injection attacks. scripts are expected to protect against such attacks.

a host environment can provide facilities to output computed results in a user-visible manner 💬. for example, host environments supporting a graphical user interface can provide facilities that enable scripts to present certain messages to the user. implementations MUST take steps to avoid confusion of the origin of such messages. in general, the security considerations for the host environment apply in such a case, as discussed above.

implementations are required to support the UTF-8 character encoding scheme; the security considerations of [RFC3629] apply. additional character encoding schemes may be supported; support for such schemes is subject to the security considerations of those schemes 🔐.

source text is expected to be in Unicode Normalization Form C 🌸. scripts and implementations MUST consider security implications of unnormalized source text and data. for a detailed discussion of such implications, refer to the security considerations in [RFC3629]. this one's sneaky, so pay attention 👀

scripts can be executed in an environment that is vulnerable to code injection attacks 💥. for example, a Common Gateway Interface (CGI) script [RFC3875] echoing user input could allow the inclusion of untrusted scripts that could be executed in an otherwise trusted environment. this threat scenario is subject to security considerations that are out of the scope of this document.

the "data" resource identifier scheme [RFC2397], in combination with the types defined in this document, could be used to cause execution of untrusted scripts through the inclusion of untrusted resource identifiers in otherwise trusted content 🫣. security considerations of [RFC2397] apply.

implementations can fail to implement a specific security model or other means to prevent possibly dangerous operations 😱. such failure could possibly be exploited to gain unauthorized access to a system or sensitive information. that failure is an unknown factor, so this document doesn't define it.

6. IANA Considerations 📋

okay the media type registrations here are split into two big categories 🗂️: (1) the sole media type text/javascript, which is now in common usage, and (2) all of the media types that are obsolete. the obsolete ones are application/ecmascript, application/javascript, application/x-ecmascript, application/x-javascript, text/ecmascript, text/javascript1.0, text/javascript1.1, text/javascript1.2, text/javascript1.3, text/javascript1.4, text/javascript1.5, text/jscript, text/livescript, and text/x-ecmascript 🥹.

for both categories, the "Published specification" entry for the media types is updated to reference [ECMA-262] ✨. also, a new file extension of .mjs has been added to the list of file extensions, with the restriction that contents should be parsed using the Module goal 🦋. finally, the [HTML] specification uses text/javascript as the default media type of ECMAScript when preparing script tags, so text/javascript intended usage has been moved from OBSOLETE to COMMON 👑.

these changes have been reflected in the IANA "Media Types" registry in accordance with [RFC6838]. all registrations will point to this document as the reference. the outdated note stating that the text/javascript media type has been "OBSOLETED in favor of application/javascript" has been removed 🧹. the outdated note stating that the text/ecmascript media type has been "OBSOLETED in favor of application/ecmascript" has been removed too. IANA has added the note "OBSOLETED in favor of text/javascript" to all registrations except text/javascript. that is, this note has been added to the text/ecmascript, application/javascript, and application/ecmascript registrations 💅

four of the legacy media types in this document have a subtype starting with the "x-" prefix 🫶:

  • application/x-ecmascript
  • application/x-javascript
  • text/x-ecmascript
  • text/x-javascript

note that these are grandfathered media types registered as per Appendix A of [RFC6838] 🍼. these registrations predate BCP 178 [RFC6648], which they violate, and are only included in this document for backward compatibility. it's a little messy history, but we keep them for the sake of compatibility 🥲

6.1. Common JavaScript Media Types 🦋

6.1.1. text/javascript 💖

Okay, this is the main one bestie 🧚 text/javascript is the JavaScript media type you actually want. Here's the full registration, copied exactly so nothing gets lost:

   Type name:  text

   Subtype name:  javascript

   Required parameters:  N/A

   Optional parameters:  charset.  See Section 4.1 of RFC 9239.

   Encoding considerations:  Binary

   Security considerations:  See Section 5 of RFC 9239.

   Interoperability considerations:  It is expected that implementations
      will behave as if this registration applies to later editions of
      [ECMA-262], and its published specification references may be
      updated accordingly from time to time.  Although this expectation
      is unusual among media type registrations, it matches widespread
      industry conventions.  See Section 2 of RFC 9239.

   Published specification:  [ECMA-262]

   Applications that use this media type:  Script interpreters as
      discussed in RFC 9239.

   Additional information:
      Deprecated alias names for this type:  application/javascript,
         application/x-javascript, text/javascript1.0, text/
         javascript1.1, text/javascript1.2, text/javascript1.3, text/
         javascript1.4, text/javascript1.5, text/jscript, text/
         livescript
      Magic number(s):  N/A
      File extension(s):  .js, .mjs
      Macintosh File Type Code(s):  TEXT

   Person & email address to contact for further information:  See the
      Authors' Addresses sections of RFC 9239 and [RFC4329].

   Intended usage:  COMMON

   Restrictions on usage:  The .mjs file extension signals that the file
      represents a JavaScript module.  Execution environments that rely
      on file extensions to determine how to process inputs parse .mjs
      files using the Module grammar of [ECMA-262].

   Author:  See the Authors' Addresses sections of RFC 9239 and
      [RFC4329].

   Change controller:  IESG <iesg@ietf.org>

So the vibe 💅 Implementations are expected to act as if this registration covers later editions of [ECMA-262], even though that's unusual for media types. It's basically the industry norm, so the spec just goes along with it ✨ .js and .mjs both live here, and .mjs is the signal that a file is a JavaScript module, parsed with the Module grammar of [ECMA-262] 🎀

6.2. Historic JavaScript Media Types 🕰️

These are the vintage ones 🍓 They're added or updated purely for history, and every single one has an intended usage of OBSOLETE. Modern implementations aren't expected to be using any of them, so consider this a museum tour, not a shopping list.

6.2.1. text/ecmascript 🦋

Obsolete, but let's still look at the receipts 🧾

   Type name:  text

   Subtype name:  ecmascript

   Required parameters:  N/A

   Optional parameters:  charset.  See Section 4.1 of RFC 9239.

   Encoding considerations:  Binary

   Security considerations:  See Section 5 of RFC 9239.

   Interoperability considerations:  It is expected that implementations
      will behave as if this registration applies to later editions of
      [ECMA-262], and its published specification references may be
      updated accordingly from time to time.  Although this expectation
      is unusual among media type registrations, it matches widespread
      industry conventions.  See Section 2 of RFC 9239.

   Published specification:  [ECMA-262]

   Applications that use this media type:  Script interpreters as
      discussed in RFC 9239.

   Additional information:
      Deprecated alias names for this type:  application/ecmascript,
         application/x-ecmascript, text/x-ecmascript
      Magic number(s):  N/A
      File extension(s):  .es, .mjs
      Macintosh File Type Code(s):  TEXT

   Person & email address to contact for further information:  See the
      Authors' Addresses sections of RFC 9239 and [RFC4329].

   Intended usage:  OBSOLETE

   Restrictions on usage:  This media type is obsolete; current
      implementations should use text/javascript as the only JavaScript/
      ECMAScript media type.  The .mjs file extension signals that the
      file represents a JavaScript module.  Execution environments that
      rely on file extensions to determine how to process inputs parse
      .mjs files using the Module grammar of [ECMA-262].

   Author:  See the Authors' Addresses sections of RFC 9239 and
      [RFC4329].

   Change controller:  IESG <iesg@ietf.org>

The tea ☕ This one is obsolete, and the spec says current implementations should use text/javascript as the only JavaScript/ECMAScript media type. Same .mjs module signal as before, same Module grammar of [ECMA-262] ✨

7. References 📚

7.1. Normative References 🔒

7.2. Informative References 🌈

Appendix A. Changes from RFC 4329 📝

  • Added a section discussing ECMAScript modules and the impact on processing. 🧩
  • Updated the Security Considerations section to discuss concerns associated with ECMAScript modules and SharedArrayBuffers. 🔐
  • Updated the character encoding scheme detection to remove normative guidance on its use, to better reflect operational reality. 🔄
  • Changed the intended usage of the media type "text/javascript" from OBSOLETE to COMMON. 🎉
  • Changed the intended usage for all other script media types to obsolete. 🪦
  • Updated various references where the original has been obsoleted. 🔗
  • Updated references to ECMA-262 to match the version at the time of publication. 📅

Acknowledgements 🫶

This work builds upon its antecedent document, authored by Björn Höhrmann. The authors would like to thank Adam Roach, Alexey Melnikov, Allen Wirfs-Brock, Anne van Kesteren, Ben Campbell, Benjamin Kaduk, Éric Vyncke, Francesca Palombini, James Snell, Kirsty Paine, Mark Nottingham, Murray Kucherawy, Ned Freed, Robert Sparks, and Suresh Krishnan for their guidance and feedback throughout this process. Everyone on that list is absolutely iconic 👑

Authors' Addresses 💌

  • Matthew A. Miller Email: linuxwolf+ietf@outer-planes.net
  • Myles Borins GitHub Email: mylesborins@github.com
  • Mathias Bynens Google Email: mths@google.com
  • Bradley Farias Email: bradley.meck@gmail.com
📦 where this page comes from