rfc9239.original   rfc9239.txt 
DISPATCH M. Miller Internet Engineering Task Force (IETF) M. Miller
Internet-Draft Request for Comments: 9239
Obsoletes: 4329 (if approved) M. Borins Obsoletes: 4329 M. Borins
Intended status: Informational GitHub Category: Informational GitHub
Expires: 3 September 2022 M. Bynens ISSN: 2070-1721 M. Bynens
Google Google
B. Farias B. Farias
2 March 2022 May 2022
ECMAScript Media Types Updates Updates to ECMAScript Media Types
draft-ietf-dispatch-javascript-mjs-17
Abstract Abstract
This document describes the registration of media types for the This document describes the registration of media types for the
ECMAScript and JavaScript programming languages and conformance ECMAScript and JavaScript programming languages and conformance
requirements for implementations of these types. This document requirements for implementations of these types. This document
obsoletes RFC4329, "Scripting Media Types", replacing the previous obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous
registrations for "text/javascript" and "application/javascript" with registrations with information and requirements aligned with common
information and requirements aligned with common usage and usage and implementation experiences.
implementation experiences.
Status of This Memo IESG Note
This Internet-Draft is submitted in full conformance with the This document records the relationship between the work of Ecma
provisions of BCP 78 and BCP 79. International's Technical Committee 39 and the media types used to
identify relevant payloads.
Internet-Drafts are working documents of the Internet Engineering That relationship was developed outside of the IETF and as a result
Task Force (IETF). Note that other groups may also distribute is unfortunately not aligned with the best practices of BCP 13.
working documents as Internet-Drafts. The list of current Internet- Consequently, consensus exists in the IETF to document the
Drafts is at https://datatracker.ietf.org/drafts/current/. relationship and update the relevant IANA registrations for those
media types, but this is not an IETF endorsement of the media types
chosen for this work.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 September 2022. This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9239.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Compatibility
3. Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Modules
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encoding
4.1. Charset Parameter . . . . . . . . . . . . . . . . . . . . 5 4.1. Charset Parameter
4.2. Character Encoding Scheme Detection . . . . . . . . . . . 5 4.2. Character Encoding Scheme Detection
4.3. Character Encoding Scheme Error Handling . . . . . . . . 6 4.3. Character Encoding Scheme Error Handling
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations
6.1. Common JavaScript Media Types . . . . . . . . . . . . . . 10 6.1. Common JavaScript Media Types
6.1.1. text/javascript . . . . . . . . . . . . . . . . . . . 10 6.1.1. text/javascript
6.2. Historic JavaScript Media Types . . . . . . . . . . . . . 11 6.2. Historic JavaScript Media Types
6.2.1. text/ecmascript . . . . . . . . . . . . . . . . . . . 12 6.2.1. text/ecmascript
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. Changes from RFC 4329
Appendix B. Changes from RFC 4329 . . . . . . . . . . . . . . . 15 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
1. Introduction 1. Introduction
This memo describes media types for the JavaScript and ECMAScript This memo describes media types for the JavaScript and ECMAScript
programming languages. Refer to the sections "Introduction" and programming languages. Refer to the sections "Introduction" and
"Overview" in [ECMA-262] for background information on these "Overview" in [ECMA-262] for background information on these
languages. This document updates the descriptions and registrations languages. This document updates the descriptions and registrations
for these media types to reflect existing usage on the Internet, and for these media types to reflect existing usage on the Internet, and
provides up-to-date security considerations. it provides up-to-date security considerations.
This document replaces the media types registrations in [RFC4329], This document replaces the media type registrations in [RFC4329] and
and updates the requirements for implementations using those media updates the requirements for implementations using those media types
types defined in [RFC4329] based on current existing practices. As a defined in [RFC4329] based on current existing practices. As a
consequence, this document obsoletes [RFC4329]. consequence, this document obsoletes [RFC4329].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 BCP "OPTIONAL" in this document are to be interpreted as described in
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.
2. Compatibility 2. Compatibility
This document defines equivalent processing requirements for the This document defines equivalent processing requirements for the
types text/javascript, text/ecmascript, and application/javascript. various script media types. The most widely supported media type in
The most widely supported media type in use is text/javascript; all use is text/javascript; all others are considered historical and
others are considered historical and obsolete aliases of text/ obsolete aliases of text/javascript.
javascript.
The types defined in this document are applicable to scripts written The types defined in this document are applicable to scripts written
in [ECMA-262]. New editions of [ECMA-262] are subjected to strong in [ECMA-262]. New editions of [ECMA-262] are subjected to strong
obligations of backward compatibility, imposed by the standardization obligations of backward compatibility, imposed by the standardization
process of Ecma International's Technical Committee 39 (TC39). As a process of Ecma International's Technical Committee 39 (TC39). As a
result, JavaScript code based on an earlier edition is generally result, JavaScript code based on an earlier edition is generally
compatible with a JavaScript engine adhering to a later edition. The compatible with a JavaScript engine adhering to a later edition. The
few exceptions to this are documented in [ECMA-262] in the section few exceptions to this are documented in [ECMA-262] in the section
"Additions and Changes That Introduce Incompatibilities with Prior "Additions and Changes That Introduce Incompatibilities with Prior
Editions". JavaScript developers commonly use feature detection to Editions". JavaScript developers commonly use feature detection to
ensure modern JavaScript features are only used when available in the ensure that modern JavaScript features are only used when available
current environment. Later editions of [ECMA-262] are not directly in the current environment. Later editions of [ECMA-262] are not
addressed in this document, although it is expected that directly addressed in this document, although it is expected that
implementations will behave as if applicability were extended to implementations will behave as if applicability were extended to
them. This document does not address other extensions to [ECMA-262] them. This document does not address other extensions to [ECMA-262]
or scripts written in other languages. or scripts written in other languages.
This document may be updated to take other content into account. This document may be updated to take other content into account.
Updates of this document may introduce new optional parameters; Updates of this document may introduce new optional parameters;
implementations must consider the impact of such an update. implementations must consider the impact of such an update.
This document does not define how fragment identifiers in resource This document does not define how fragment identifiers in resource
identifiers ([RFC3986], [RFC3987]) for documents labeled with one of identifiers [RFC3986] [RFC3987] for documents labeled with one of the
the media types defined in this document are resolved. An update of media types defined in this document are resolved. An update of this
this document may define processing of fragment identifiers. document may define processing of fragment identifiers.
Note that this use of the "text" media type tree willfully does not Note that this use of the "text" media type tree willfully does not
align with its original intent per [RFC2045]. The reason for this is align with its original intent per [RFC2045]. The reason for this is
historical. [RFC4329] registered both the text/* and application/* historical. [RFC4329] registered both the text/* and application/*
types, marking the text/* ones obsolete. This was done to encourage types, marking the text/* types obsolete. This was done to encourage
people toward application/*, matching the guidance in [RFC4288], the people toward application/*, matching the guidance in [RFC4288], the
predecessor to [RFC6838]. Since then, however, the industry widely predecessor to [RFC6838]. Since then, however, the industry widely
adopted text/* anyway. The definitions in this document reflect the adopted text/* anyway. The definitions in this document reflect the
current state of implementation across the JavaScript ecosystem, in current state of implementation across the JavaScript ecosystem, in
web browsers and other environments such as Node.js alike, in order web browsers and other environments such as Node.js alike, in order
to guarantee backwards compatibility with existing applications as to guarantee backward compatibility with existing applications as
much as possible. Future registrations should not view this as a much as possible. Future registrations should not view this as a
repeatable precedent. repeatable precedent.
3. Modules 3. Modules
In order to formalize support for modular programs, [ECMA-262] In order to formalize support for modular programs, [ECMA-262]
(starting with 6th Edition) defines two top-level goal symbols (or (starting with the 6th Edition) defines two top-level goal symbols
roots to the abstract syntax tree) for the ECMAScript grammar: Module (or roots to the abstract syntax tree) for the ECMAScript grammar:
and Script. The Script goal represents the original structure where Module and Script. The Script goal represents the original structure
the code executes in the global scope, while the Module goal where the code executes in the global scope, while the Module goal
represents the module system built into ECMAScript starting with 6th represents the module system built into ECMAScript starting with the
Edition. See the section "ECMAScript Language: Scripts and Modules" 6th Edition. See the section "ECMAScript Language: Scripts and
of [ECMA-262] for details. Modules" in [ECMA-262] for details.
This separation means that (in the absence of additional information) This separation means that (in the absence of additional information)
there are two possible interpretations for any given ECMAScript there are two possible interpretations for any given ECMAScript
source text. source text.
Ecma International's Technical Committee 39 (TC39), the standards Ecma International's Technical Committee 39 (TC39), the standards
body in charge of ECMAScript, has determined that media types are body in charge of ECMAScript, has determined that media types are
outside of their scope of work [TC39-MIME-ISSUE]. outside of their scope of work [TC39-MIME-ISSUE].
It is not possible to fully determine if a source text of ECMAScript It is not possible to fully determine if a source text of ECMAScript
is meant to be parsed using the Module or Script grammar goals based is meant to be parsed using the Module or Script grammar goals based
upon content or media type alone. Therefore, as permitted by the upon content or media type alone. Therefore, as permitted by the
media types in this document, scripting environments use out-of-band media types in this document, scripting environments use out-of-band
information in order to determine what goal should be used. Some information in order to determine what goal should be used. Some
scripting environments have chosen to adopt the file extension of scripting environments have chosen to adopt the file extension of
.mjs for this purpose. .mjs for this purpose.
4. Encoding 4. Encoding
Refer to [RFC6365] for a discussion of terminology used in this Refer to [RFC6365] for a discussion of terminology used in this
section. Source text (as defined in [ECMA-262], section "Source section. Source text (as defined in the section "Source Text" in
Text") can be binary source text. Binary source text is a textual [ECMA-262]) can be binary source text. Binary source text is a
data object that represents source text encoded using a character textual data object that represents source text encoded using a
encoding scheme. A textual data object is a whole text protocol character encoding scheme. A textual data object is a whole text
message or a whole text document, or a part of it, that is treated protocol message or a whole text document, or a part of it, that is
separately for purposes of external storage and retrieval. An treated separately for purposes of external storage and retrieval.
implementation's internal representation of source text is not An implementation's internal representation of source text is not
considered binary source text. considered binary source text.
Implementations need to determine a character encoding scheme in Implementations need to determine a character encoding scheme in
order to decode binary source text to source text. The media types order to decode binary source text to source text. The media types
defined in this document allow an optional charset parameter to defined in this document allow an optional charset parameter to
explicitly specify the character encoding scheme used to encode the explicitly specify the character encoding scheme used to encode the
source text. source text.
In order to ensure interoperability and align with widespread In order to ensure interoperability and align with widespread
implementation practices, the charset parameter is optional rather implementation practices, the charset parameter is optional rather
skipping to change at page 5, line 28 skipping to change at line 218
document. For example, transport protocols can require that a document. For example, transport protocols can require that a
specific character encoding scheme is to be assumed if the optional specific character encoding scheme is to be assumed if the optional
charset parameter is not specified, or they can require that the charset parameter is not specified, or they can require that the
charset parameter is used in certain cases. Such requirements are charset parameter is used in certain cases. Such requirements are
not defined by this document. not defined by this document.
Implementations that support binary source text MUST support binary Implementations that support binary source text MUST support binary
source text encoded using the UTF-8 [RFC3629] character encoding source text encoded using the UTF-8 [RFC3629] character encoding
scheme. Module goal sources MUST be encoded as UTF-8; all other scheme. Module goal sources MUST be encoded as UTF-8; all other
encodings will fail. Source goal sources SHOULD be encoded as UTF-8; encodings will fail. Source goal sources SHOULD be encoded as UTF-8;
other character encoding schemes MAY be supported, but are other character encoding schemes MAY be supported but are
discouraged. Whether U+FEFF is processed as a Byte Order Mark (BOM) discouraged. Whether U+FEFF is processed as a Byte Order Mark (BOM)
signature or not depends on the host environment, and is not defined signature or not depends on the host environment and is not defined
by this document. by this document.
4.1. Charset Parameter 4.1. Charset Parameter
The charset parameter provides a means to specify the character The charset parameter provides a means to specify the character
encoding scheme of binary source text. If present, the value of the encoding scheme of binary source text. If present, the value of the
charset parameter MUST be a registered charset [CHARSETS], and is charset parameter MUST be a registered charset [CHARSETS] and is
considered valid if it matches the mime-charset production defined in considered valid if it matches the mime-charset production defined in
[RFC2978], section 2.3. Section 2.3 of [RFC2978].
The charset parameter is only used when processing a Script goal The charset parameter is only used when processing a Script goal
source; Module goal sources MUST always be processed as UTF-8. source; Module goal sources MUST always be processed as UTF-8.
4.2. Character Encoding Scheme Detection 4.2. Character Encoding Scheme Detection
It is possible that implementations cannot interoperably determine a It is possible that implementations cannot interoperably determine a
single character encoding scheme simply by complying with all single character encoding scheme simply by complying with all
requirements of the applicable specifications. To foster requirements of the applicable specifications. To foster
interoperability in such cases, the following algorithm is defined. interoperability in such cases, the following algorithm is defined.
Implementations apply this algorithm until a single character Implementations apply this algorithm until a single character
encoding scheme is determined. encoding scheme is determined.
1. If the binary source text is not already determined to be using a 1. If the binary source text is not already determined to be using a
Module goal and starts with a Unicode encoding form signature, Module goal and starts with a Unicode encoding form signature,
the signature determines the encoding. The following octet the signature determines the encoding. The following octet
sequences, at the very beginning of the binary source text, are sequences, at the very beginning of the binary source text, are
considered with their corresponding character encoding schemes: considered with their corresponding character encoding schemes:
+------------------+----------+ +==================+==========+
| Leading sequence | Encoding | | Leading sequence | Encoding |
|------------------+----------| +==================+==========+
| EF BB BF | UTF-8 | | EF BB BF | UTF-8 |
+------------------+----------+
| FF FE | UTF-16LE | | FF FE | UTF-16LE |
+------------------+----------+
| FE FF | UTF-16BE | | FE FF | UTF-16BE |
+------------------+----------+ +------------------+----------+
Table 1
Implementations of this step MUST use these octet sequences to Implementations of this step MUST use these octet sequences to
determine the character encoding scheme, even if the determined determine the character encoding scheme, even if the determined
scheme is not supported. If this step determines the character scheme is not supported. If this step determines the character
encoding scheme, the octet sequence representing the Unicode encoding scheme, the octet sequence representing the Unicode
encoding form signature MUST be ignored when decoding the binary encoding form signature MUST be ignored when decoding the binary
source text. source text.
2. Else, if a charset parameter is specified and its value is valid 2. Else, if a charset parameter is specified and its value is valid
and supported by the implementation, the value determines the and supported by the implementation, the value determines the
character encoding scheme. character encoding scheme.
skipping to change at page 6, line 40 skipping to change at line 282
3. Else, the character encoding scheme is assumed to be UTF-8. 3. Else, the character encoding scheme is assumed to be UTF-8.
If the character encoding scheme is determined to be UTF-8 through 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 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 text starts with the octet sequence EF BB BF, the octet sequence is
ignored when decoding the binary source text. ignored when decoding the binary source text.
4.3. Character Encoding Scheme Error Handling 4.3. Character Encoding Scheme Error Handling
Binary source text that is not properly encoded for the determined Binary source text that is not properly encoded for the determined
character encoding can pose a security risk, as discussed in section character encoding can pose a security risk, as discussed in
5. That said, because of the varied and complex environments scripts Section 5. That said, because of the varied and complex environments
are executed in, most of the error handling specifics are left to the scripts are executed in, most of the error handling specifics are
processors. The following are broad guidelines that processors left to the processors. The following are broad guidelines that
follow. processors follow.
If binary source text is determined to have been encoded using a If binary source text is determined to have been encoded using a
certain character encoding scheme that the implementation is unable certain character encoding scheme that the implementation is unable
to process, implementations can consider the resource unsupported to process, implementations can consider the resource unsupported
(i.e., do not decode the binary source text using a different (i.e., do not decode the binary source text using a different
character encoding scheme). character encoding scheme).
Binary source text can be determined to have been encoded using a Binary source text can be determined to have been encoded using a
certain character encoding scheme but contain octet sequences that certain character encoding scheme but contain octet sequences that
are not valid according to that scheme. Implementations can are not valid according to that scheme. Implementations can
substitute those invalid sequences with the replacement character substitute those invalid sequences with the replacement character
U+FFFD (properly encoded for the scheme), or stop processing U+FFFD (properly encoded for the scheme) or stop processing
altogether. altogether.
5. Security Considerations 5. Security Considerations
Refer to [RFC3552] for a discussion of terminology used in this Refer to [RFC3552] for a discussion of terminology used in this
section. Examples in this section and discussions of interactions of section. Examples in this section and discussions of interactions of
host environments with scripts, modules, and extensions to [ECMA-262] host environments with scripts, modules, and extensions to [ECMA-262]
are to be understood as non-exhaustive and of a purely illustrative are to be understood as non-exhaustive and of a purely illustrative
nature. nature.
The programming language defined in [ECMA-262] is not intended to be The programming language defined in [ECMA-262] is not intended to be
computationally self-sufficient, rather, it is expected that the computationally self-sufficient; rather, it is expected that the
computational environment provides facilities to programs to enable computational environment provides facilities to programs to enable
specific functionality. Such facilities constitute unknown factors specific functionality. Such facilities constitute unknown factors
and are thus not defined by this document. and are thus not defined by this document.
Derived programming languages are permitted to include additional Derived programming languages are permitted to include additional
functionality that is not described in [ECMA-262]; such functionality functionality that is not described in [ECMA-262]; such functionality
constitutes an unknown factor and is thus not defined by this constitutes an unknown factor and is thus not defined by this
document. In particular, extensions to [ECMA-262] defined for the document. In particular, extensions to [ECMA-262] defined for the
JavaScript programming language are not discussed in this document. JavaScript programming language are not discussed in this document.
Uncontrolled execution of scripts can be exceedingly dangerous. Uncontrolled execution of scripts can be exceedingly dangerous.
Implementations that execute scripts MUST give consideration to their Implementations that execute scripts MUST give consideration to their
application's threat models and those of the individual features they application's threat models and those of the individual features they
implement; in particular, they MUST ensure that untrusted content is implement; in particular, they MUST ensure that untrusted content is
not executed in an unprotected environment. not executed in an unprotected environment.
Module scripts in ECMAScript can request the fetching and processing Module scripts in ECMAScript can request the fetching and processing
of additional scripts, called importing. Implementations that of additional scripts; this is called "importing". Implementations
support modules need to process imported sources in the same way as that support modules need to process imported sources in the same way
scripts. See the section "ECMAScript Language: Scripts and Modules" as scripts. See the section "ECMAScript Language: Scripts and
in [ECMA-262] for details. Further, there may be additional privacy Modules" in [ECMA-262] for details. Further, there may be additional
and security concerns depending on the location(s) the original privacy and security concerns, depending on the location(s) the
script and its imported modules are obtained from. For instance, a original script and its imported modules are obtained from. For
script obtained from "host-a.example" could request to import a instance, a script obtained from "host-a.example" could request to
script from "host-b.example", which could expose information about import a script from "host-b.example", which could expose information
the executing environment (e.g., IP address) to "host-b.example". about the executing environment (e.g., IP address) to "host-
b.example".
Specifications for host environment facilities and for derived Specifications for host environment facilities and for derived
programming languages should include security considerations. If an programming languages should include security considerations. If an
implementation supports such facilities, the respective security implementation supports such facilities, the respective security
considerations apply. In particular, if scripts can be referenced considerations apply. In particular, if scripts can be referenced
from or included in specific document formats, the considerations for from or included in specific document formats, the considerations for
the embedding or referencing document format apply. the embedding or referencing document format apply.
For example, scripts embedded in application/xhtml+xml [RFC3236] For example, scripts embedded in application/xhtml+xml [RFC3236]
documents could be enabled through the host environment to manipulate documents could be enabled through the host environment to manipulate
the document instance, which could cause the retrieval of remote the document instance, which could cause the retrieval of remote
resources; security considerations regarding retrieval of remote resources; security considerations regarding retrieval of remote
resources of the embedding document would apply in this case. resources of the embedding document would apply in this case.
This circumstance can further be used to make information, that is This circumstance can further be used to make information that is
normally only available to the script, available to a web server by normally only available to the script also available to a web server
encoding the information in the resource identifier of the resource, by encoding the information in the resource identifier of the
which can further enable eavesdropping attacks. Implementation of resource, which can further enable eavesdropping attacks.
such facilities is subject to the security considerations of the host Implementation of such facilities is subject to the security
environment, as discussed above. considerations of the host environment, as discussed above.
The programming language defined in [ECMA-262] does include The programming language defined in [ECMA-262] does include
facilities to loop, cause computationally complex operations, or facilities to loop, cause computationally complex operations, or
consume large amounts of memory; this includes, but is not limited consume large amounts of memory; this includes, but is not limited
to, facilities that allow dynamically generated source text to be to, facilities that allow dynamically generated source text to be
executed (e.g., the eval() function); uncontrolled execution of such executed (e.g., the eval() function); uncontrolled execution of such
features can cause denial of service, which implementations MUST features can cause denial of service, which implementations MUST
protect against. protect against.
With the addition of SharedArrayBuffer objects in ECMAScript version With the addition of SharedArrayBuffer objects in ECMAScript version
8, it could be possible to implement a high-resolution timer which 8, it could be possible to implement a high-resolution timer, which
could lead to certain types of timing and side-channel attacks (e.g., could lead to certain types of timing and side-channel attacks (e.g.,
[SPECTRE]). Implementations can take steps to mitigate this concern, [SPECTRE]). Implementations can take steps to mitigate this concern,
such as disabling or removing support for SharedArrayBuffer objects, such as disabling or removing support for SharedArrayBuffer objects,
or take additional steps to ensure access to this shared memory is or can take additional steps to ensure that this shared memory is
only accessible between execution contexts that have some form of only accessible between execution contexts that have some form of
mutual trust. mutual trust.
A host environment can provide facilities to access external input. A host environment can provide facilities to access external input.
Scripts that pass such input to the eval() function or similar Scripts that pass such input to the eval() function or similar
language features can be vulnerable to code injection attacks. language features can be vulnerable to code injection attacks.
Scripts are expected to protect against such attacks. Scripts are expected to protect against such attacks.
A host environment can provide facilities to output computed results A host environment can provide facilities to output computed results
in a user-visible manner. For example, host environments supporting in a user-visible manner. For example, host environments supporting
skipping to change at page 9, line 21 skipping to change at line 397
case as discussed above. case as discussed above.
Implementations are required to support the UTF-8 character encoding Implementations are required to support the UTF-8 character encoding
scheme; the security considerations of [RFC3629] apply. Additional scheme; the security considerations of [RFC3629] apply. Additional
character encoding schemes may be supported; support for such schemes character encoding schemes may be supported; support for such schemes
is subject to the security considerations of those schemes. is subject to the security considerations of those schemes.
Source text is expected to be in Unicode Normalization Form C. Source text is expected to be in Unicode Normalization Form C.
Scripts and implementations MUST consider security implications of Scripts and implementations MUST consider security implications of
unnormalized source text and data. For a detailed discussion of such unnormalized source text and data. For a detailed discussion of such
implications refer to the security considerations in [RFC3629]. implications, refer to the security considerations in [RFC3629].
Scripts can be executed in an environment that is vulnerable to code Scripts can be executed in an environment that is vulnerable to code
injection attacks. For example, a CGI script [RFC3875] echoing user injection attacks. For example, a Common Gateway Interface (CGI)
input could allow the inclusion of untrusted scripts that could be script [RFC3875] echoing user input could allow the inclusion of
executed in an otherwise trusted environment. This threat scenario untrusted scripts that could be executed in an otherwise trusted
is subject to security considerations that are out of the scope of environment. This threat scenario is subject to security
this document. considerations that are out of the scope of this document.
The "data" resource identifier scheme [RFC2397], in combination with The "data" resource identifier scheme [RFC2397], in combination with
the types defined in this document, could be used to cause execution the types defined in this document, could be used to cause execution
of untrusted scripts through the inclusion of untrusted resource of untrusted scripts through the inclusion of untrusted resource
identifiers in otherwise trusted content. Security considerations of identifiers in otherwise trusted content. Security considerations of
[RFC2397] apply. [RFC2397] apply.
Implementations can fail to implement a specific security model or Implementations can fail to implement a specific security model or
other means to prevent possibly dangerous operations. Such failure other means to prevent possibly dangerous operations. Such failure
could possibly be exploited to gain unauthorized access to a system could possibly be exploited to gain unauthorized access to a system
or sensitive information; such failure constitutes an unknown factor or sensitive information; such failure constitutes an unknown factor
and is thus not defined by this document. and is thus not defined by this document.
6. IANA Considerations 6. IANA Considerations
The media type registrations herein are divided into two major The media type registrations herein are divided into two major
categories: the sole media type "text/javascript" which is now in categories: (1) the sole media type "text/javascript", which is now
common usage, and all of the media types that are obsolete. in common usage and (2) all of the media types that are obsolete
(i.e., "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 media types are updated to reference For both categories, the "Published specification" entry for the
[ECMA-262]. In addition, a new file extension of .mjs is added to media types is updated to reference [ECMA-262]. In addition, a new
the list of file extensions with the restriction that contents should file extension of .mjs has been added to the list of file extensions
be parsed using the Module goal. Finally, the [HTML] specification with the restriction that contents should be parsed using the Module
uses "text/javascript" as the default media type of ECMAScript when goal. Finally, the [HTML] specification uses "text/javascript" as
preparing script tags; therefore, "text/javascript" intended usage is the default media type of ECMAScript when preparing script tags;
to be moved from OBSOLETE to COMMON. therefore, "text/javascript" intended usage has been moved from
OBSOLETE to COMMON.
These changes are to be reflected in the IANA Media Types registry in These changes have been reflected in the IANA "Media Types" registry
accordance with [RFC6838]. All registrations will point to this in accordance with [RFC6838]. All registrations will point to this
document as reference. The outdated note stating that the "text/ document as the reference. The outdated note stating that the "text/
javascript" media type has been "OBSOLETED in favor of application/ javascript" media type has been "OBSOLETED in favor of application/
javascript" is to be removed. The outdated note stating that the javascript" has been removed. The outdated note stating that the
"text/ecmascript" media type has been "OBSOLETED in favor of "text/ecmascript" media type has been "OBSOLETED in favor of
application/ecmascript" is to be removed. IANA is requested to add application/ecmascript" has been removed. IANA has added the note
the note "OBSOLETED in favor of text/javascript" to all registrations "OBSOLETED in favor of text/javascript" to all registrations except
except "text/javascript". "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 Four of the legacy media types in this document have a subtype
starting with the "x-" prefix: starting with the "x-" prefix:
* application/x-ecmascript * application/x-ecmascript
* application/x-javascript * application/x-javascript
* text/x-ecmascript * text/x-ecmascript
* text/x-javascript * text/x-javascript
Note that these are grandfathered media types registered as per Note that these are grandfathered media types registered as per
Appendix A of [RFC6838]. These registrations predate BCP 178 Appendix A of [RFC6838]. These registrations predate BCP 178
[RFC6648], which they violate, and are only included in this document [RFC6648], which they violate, and are only included in this document
for backwards compatibility. for backward compatibility.
6.1. Common JavaScript Media Types 6.1. Common JavaScript Media Types
6.1.1. text/javascript 6.1.1. text/javascript
Type name: text Type name: text
Subtype name: javascript Subtype name: javascript
Required parameters: N/A Required parameters: N/A
Optional parameters: charset, see section 4.1 of [this document]. Optional parameters: charset. See Section 4.1 of RFC 9239.
Encoding considerations: Binary Encoding considerations: Binary
Security considerations: See section 5 of [this document].
Security considerations: See Section 5 of RFC 9239.
Interoperability considerations: It is expected that implementations Interoperability considerations: It is expected that implementations
will behave as if this registration applies to later editions of will behave as if this registration applies to later editions of
[ECMA-262], and its published specification references may be [ECMA-262], and its published specification references may be
updated accordingly from time to time. Although this expectation updated accordingly from time to time. Although this expectation
is unusual among media type registrations, it matches widespread is unusual among media type registrations, it matches widespread
industry conventions. See section 2 of [this document]. industry conventions. See Section 2 of RFC 9239.
Published specification: [ECMA-262] Published specification: [ECMA-262]
Applications which use this media type: Script interpreters as Applications that use this media type: Script interpreters as
discussed in [this document]. discussed in RFC 9239.
Additional information: Additional information:
Deprecated alias names for this type: application/javascript,
Deprecated alias names for this type: application/javascript, application/x-javascript, text/javascript1.0, text/
application/x-javascript, text/javascript1.0, text/javascript1.1, javascript1.1, text/javascript1.2, text/javascript1.3, text/
text/javascript1.2, text/javascript1.3, text/javascript1.4, text/ javascript1.4, text/javascript1.5, text/jscript, text/
javascript1.5, text/jscript, text/livescript livescript
Magic number(s): N/A
Magic number(s): n/a
File extension(s): .js, .mjs File extension(s): .js, .mjs
Macintosh File Type Code(s): TEXT Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: See Person & email address to contact for further information: See the
Author's Address section of [this document] and [RFC4329]. Authors' Addresses sections of RFC 9239 and [RFC4329].
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: The .mjs file extension signals that the file Restrictions on usage: The .mjs file extension signals that the file
represents a JavaScript module. Execution environments that rely represents a JavaScript module. Execution environments that rely
on file extensions to determine how to process inputs parse .mjs on file extensions to determine how to process inputs parse .mjs
files using the Module grammar of [ECMA-262]. files using the Module grammar of [ECMA-262].
Author: See Author's Address section of [this document] and Author: See the Authors' Addresses sections of RFC 9239 and
[RFC4329]. [RFC4329].
Change controller: IESG <iesg@ietf.org> Change controller: IESG <iesg@ietf.org>
6.2. Historic JavaScript Media Types 6.2. Historic JavaScript Media Types
The following media types and legacy aliases are added or updated for The following media types and legacy aliases are added or updated for
historical purposes. All herein have an intended usage of OBSOLETE, historical purposes. All herein have an intended usage of OBSOLETE
and are not expected to be in use with modern implementations. and are not expected to be in use with modern implementations.
6.2.1. text/ecmascript 6.2.1. text/ecmascript
Type name: application Type name: text
Subtype name: ecmascript Subtype name: ecmascript
Required parameters: N/A Required parameters: N/A
Optional parameters: charset, see section 4.1 of [this document]. Optional parameters: charset. See Section 4.1 of RFC 9239.
Encoding considerations: Binary Encoding considerations: Binary
Security considerations: See section 5 of [this document]. Security considerations: See Section 5 of RFC 9239.
Interoperability considerations: It is expected that implementations Interoperability considerations: It is expected that implementations
will behave as if this registration applies to later editions of will behave as if this registration applies to later editions of
[ECMA-262], and its published specification references may be [ECMA-262], and its published specification references may be
updated accordingly from time to time. Although this expectation updated accordingly from time to time. Although this expectation
is unusual among media type registrations, it matches widespread is unusual among media type registrations, it matches widespread
industry conventions. See section 2 of [this document]. industry conventions. See Section 2 of RFC 9239.
Published specification: [ECMA-262] Published specification: [ECMA-262]
Applications which use this media type: Script interpreters as Applications that use this media type: Script interpreters as
discussed in [this document]. discussed in RFC 9239.
Additional information: 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
Deprecated alias names for this type: application/ecmascript, Person & email address to contact for further information: See the
application/x-ecmascript, text/x-ecmascript Authors' Addresses sections of RFC 9239 and [RFC4329].
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
Author's Address section of [this document] and [RFC4329].
Intended usage: OBSOLETE Intended usage: OBSOLETE
Restrictions on usage: This media type is obsolete; current Restrictions on usage: This media type is obsolete; current
implementations should use text/javascript as the only JavaScript/ implementations should use text/javascript as the only JavaScript/
ECMAScript media type. The .mjs file extension signals that the ECMAScript media type. The .mjs file extension signals that the
file represents a JavaScript module. Execution environments that file represents a JavaScript module. Execution environments that
rely on file extensions to determine how to process inputs parse rely on file extensions to determine how to process inputs parse
.mjs files using the Module grammar of [ECMA-262]. .mjs files using the Module grammar of [ECMA-262].
Author: See Author's Address section of [this document] and Author: See the Authors' Addresses sections of RFC 9239 and
[RFC4329]. [RFC4329].
Change controller: IESG <iesg@ietf.org> Change controller: IESG <iesg@ietf.org>
7. References 7. References
7.1. Normative References 7.1. Normative References
[CHARSETS] IANA, "Assigned character sets", n.d., [CHARSETS] IANA, "Character Sets",
<https://www.iana.org/assignments/character-sets>. <https://www.iana.org/assignments/character-sets>.
[ECMA-262] Ecma International, "ECMAScript 2021 language [ECMA-262] Ecma International, "ECMA-262 12th Edition, June 2021.
specification, ECMA-262 12th Edition, June 2021", June ECMAScript 2021 language specification", June 2021,
2021, <https://262.ecma-international.org/12.0/>. <https://262.ecma-international.org/12.0/>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[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/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 31 skipping to change at line 644
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[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/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[HTML] WHATWG, "HTML Living Standard", August 2017, [HTML] WHATWG, "HTML Living Standard", May 2022,
<https://html.spec.whatwg.org/multipage/ <https://html.spec.whatwg.org/multipage/
scripting.html#prepare-a-script>. scripting.html#prepare-a-script>.
[RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media [RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
Type", RFC 3236, DOI 10.17487/RFC3236, January 2002, Type", RFC 3236, DOI 10.17487/RFC3236, January 2002,
<https://www.rfc-editor.org/info/rfc3236>. <https://www.rfc-editor.org/info/rfc3236>.
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface
(CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875, (CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875,
October 2004, <https://www.rfc-editor.org/info/rfc3875>. October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/info/rfc3987>. January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[SPECTRE] Kocher, P., Fogh, A., Gerkin, D., Gruss, D., Haas, W., [SPECTRE] Kocher, P., Genkin, D., Gruss, D., Haas, W., Hamburg, M.,
Hamburg, M., Lipp, M., Mangard, S., Prescher, T., Schwarz, Lipp, M., Mangard, S., Prescher, T., Schwarz, M., and Y.
M., and Y. Yarom, "Spectre Attacks: Exploiting Speculative Yarom, "Spectre Attacks: Exploiting Speculative
Execution", January 2018, Execution", DOI 10.48550/arXiv.1801.01203, January 2018,
<https://arxiv.org/abs/1801.01203>. <https://arxiv.org/abs/1801.01203>.
[TC39-MIME-ISSUE] [TC39-MIME-ISSUE]
TC39, "Add `application/javascript+module` mime to remove TC39, "Add 'application/javascript+module' mime to remove
ambiguity", August 2017, <https://web.archive.org/web/2017 ambiguity", Wayback Machine archive, August 2017, <https:/
0814193912/https://github.com/tc39/ecma262/issues/322>. /web.archive.org/web/20170814193912/https://github.com/
tc39/ecma262/issues/322>.
Appendix A. Acknowledgements
This work builds upon its antecedent document, authored by Bjoern
Hoehrmann. The authors would like to thank Adam Roach, Alexey
Melnikov, Allen Wirfs-Brock, Anne van Kesteren, Ben Campbell,
Benjamin Kaduk, Eric 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.
Appendix B. Changes from RFC 4329 Appendix A. Changes from RFC 4329
* Added a section discussing ECMAScript modules and the impact on * Added a section discussing ECMAScript modules and the impact on
processing. processing.
* Updated the Security Considerations to discuss concerns associated * Updated the Security Considerations section to discuss concerns
with ECMAScript modules and SharedArrayBuffers. associated with ECMAScript modules and SharedArrayBuffers.
* Updated the character encoding scheme detection to remove * Updated the character encoding scheme detection to remove
normative guidance on its use, to better reflect operational normative guidance on its use, to better reflect operational
reality. reality.
* Changed the intended usage of the media type text/javascript from * Changed the intended usage of the media type "text/javascript"
obsolete to common. from OBSOLETE to COMMON.
* Changed the intended usage for all other script media types to * Changed the intended usage for all other script media types to
obsolete. obsolete.
* Updated various references where the original has been obsoleted. * Updated various references where the original has been obsoleted.
* Updated references to ECMA-262 to match the version at time of * Updated references to ECMA-262 to match the version at the time of
publication. 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.
Authors' Addresses Authors' Addresses
Matthew A. Miller Matthew A. Miller
Email: linuxwolf+ietf@outer-planes.net Email: linuxwolf+ietf@outer-planes.net
Myles Borins Myles Borins
GitHub GitHub
Email: mylesborins@github.com Email: mylesborins@github.com
Mathias Bynens Mathias Bynens
Google Google
Email: mths@google.com Email: mths@google.com
Bradley Farias Bradley Farias
Email: bradley.meck@gmail.com Email: bradley.meck@gmail.com
 End of changes. 73 change blocks. 
201 lines changed or deleted 220 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/