[要約] RFC 9239 は、ECMAScript および JavaScript プログラミング言語のメディアタイプの登録と実装の適合要件を記載しています。RFC 9239 は、一般的な使用法と実装経験に合わせた情報と要件を提供し、以前の登録情報を置き換えるため、RFC 4329 ("Scripting Media Types)" を廃止します。
Internet Engineering Task Force (IETF) M. Miller
Request for Comments: 9239
Obsoletes: 4329 M. Borins
Category: Informational GitHub
ISSN: 2070-1721 M. Bynens
Google
B. Farias
May 2022
Updates to ECMAScript Media Types
ECMAScriptメディアタイプの更新
Abstract
概要
This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences.
このドキュメントでは、ECMAScriptおよびJavaScriptプログラミング言語のメディアタイプの登録と、これらのタイプの実装に関する適合要件について説明します。このドキュメントは、RFC 4329（「スクリプトメディアタイプ）」を廃止し、以前の登録を一般的な使用と実装の経験に沿った情報と要件に置き換えます。
IESG Note
IESGノート
This document records the relationship between the work of Ecma International's Technical Committee 39 and the media types used to identify relevant payloads.
このドキュメントは、ECMA Internationalの技術委員会39の作業と、関連するペイロードを特定するために使用されるメディアタイプとの関係を記録します。
That relationship was developed outside of the IETF and as a result is unfortunately not aligned with the best practices of BCP 13. Consequently, consensus exists in the IETF to document the 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.
その関係はIETF以外で開発され、その結果、残念ながらBCP 13のベストプラクティスとは一致していません。その結果、IETFにはコンセンサスが存在し、関係を文書化し、それらのメディアタイプの関連するIANA登録を更新しますが、これはそうではありません。この作業に選択されたメディアタイプのIETFの承認。
Status of This Memo
本文書の位置付け
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9239で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
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
This memo describes media types for the JavaScript and ECMAScript programming languages. Refer to the sections "Introduction" and "Overview" in [ECMA-262] for background information on these languages. This document updates the descriptions and registrations for these media types to reflect existing usage on the Internet, and it provides up-to-date security considerations.
このメモは、JavaScriptおよびECMAScriptプログラミング言語のメディアタイプについて説明しています。これらの言語の背景情報については、[ECMA-262]のセクション「紹介」と「概要」を参照してください。このドキュメントは、これらのメディアタイプの説明と登録を更新して、インターネット上の既存の使用を反映しており、最新のセキュリティに関する考慮事項を提供します。
This document replaces the media type registrations in [RFC4329] and updates the requirements for implementations using those media types defined in [RFC4329] based on current existing practices. As a consequence, this document obsoletes [RFC4329].
このドキュメントは、[RFC4329]のメディアタイプの登録を置き換え、現在の既存のプラクティスに基づいて[RFC4329]で定義されているメディアタイプを使用して実装の要件を更新します。結果として、この文書は廃止されます[RFC4329]。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document defines equivalent processing requirements for the various script media types. The most widely supported media type in use is text/javascript; all others are considered historical and obsolete aliases of text/javascript.
このドキュメントでは、さまざまなスクリプトメディアタイプの同等の処理要件を定義します。使用されている最も広くサポートされているメディアタイプは、Text/JavaScriptです。他のすべては、テキスト/javascriptの歴史的および時代遅れのエイリアスと見なされます。
The types defined in this document are applicable to scripts written in [ECMA-262]. New editions of [ECMA-262] are subjected to strong obligations of backward compatibility, imposed by the standardization process of Ecma International's Technical Committee 39 (TC39). As a result, JavaScript code based on an earlier edition is generally compatible with a JavaScript engine adhering to a later edition. The few exceptions to this are documented in [ECMA-262] in the section "Additions and Changes That Introduce Incompatibilities with Prior Editions". JavaScript developers commonly use feature detection to ensure that modern JavaScript features are only used when available in the current environment. Later editions of [ECMA-262] are not directly addressed in this document, although it is expected that implementations will behave as if applicability were extended to them. This document does not address other extensions to [ECMA-262] or scripts written in other languages.
このドキュメントで定義されているタイプは、[ECMA-262]で書かれたスクリプトに適用されます。[ECMA-262]の新しいエディションは、ECMA Internationalの技術委員会39（TC39）の標準化プロセスによって課される、後方互換性の強力な義務を科せられます。その結果、以前のエディションに基づいたJavaScriptコードは、一般に後のエディションを順守するJavaScriptエンジンと互換性があります。これに対するいくつかの例外は、[ECMA-262]に「以前のエディションとの非互換性を導入する追加と変更」セクションに文書化されています。JavaScript開発者は一般に、機能検出を使用して、現在の環境で利用可能な場合にのみ最新のJavaScript機能が使用されるようにします。[ECMA-262]の後のエディションは、このドキュメントでは直接対処されていませんが、実装が適用可能性が拡張されたかのように動作することが予想されます。このドキュメントは、[ECMA-262]または他の言語で記述されたスクリプトの他の拡張機能には対応していません。
This document may be updated to take other content into account. Updates of this document may introduce new optional parameters; implementations must consider the impact of such an update.
このドキュメントは、他のコンテンツを考慮に入れるために更新される場合があります。このドキュメントの更新により、新しいオプションのパラメーターが導入される場合があります。実装は、このような更新の影響を考慮する必要があります。
This document does not define how fragment identifiers in resource identifiers [RFC3986] [RFC3987] for documents labeled with one of the media types defined in this document are resolved. An update of this document may define processing of fragment identifiers.
このドキュメントでは、このドキュメントで定義されたメディアタイプの1つにラベル付けされたドキュメントについて、リソース識別子[RFC3986] [RFC3987]のフラグメント識別子が解決される方法を定義しません。このドキュメントの更新では、フラグメント識別子の処理を定義する場合があります。
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
historical. [RFC4329] registered both the text/* and application/*
types, marking the text/* types obsolete. This was done to encourage
people toward application/*, matching the guidance in [RFC4288], the
predecessor to [RFC6838]. Since then, however, the industry widely
adopted text/* anyway. The definitions in this document reflect the
current state of implementation across the JavaScript ecosystem, in
web browsers and other environments such as Node.js alike, in order
to guarantee backward compatibility with existing applications as
much as possible. Future registrations should not view this as a
repeatable precedent.
In order 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 represents the original structure where the code executes in the global scope, while the Module goal represents the module system built into ECMAScript starting with the 6th Edition. See the section "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details.
モジュラープログラムのサポートを正式にするために、[ECMA-262]（第6版から始まる）は、ECMAScript文法の2つのトップレベルのゴールシンボル（または抽象的構文ツリーへのルーツ）を定義します：モジュールとスクリプト。スクリプトの目標は、コードがグローバルスコープで実行される元の構造を表し、モジュール目標は第6版から始まるECMAScriptに組み込まれたモジュールシステムを表します。詳細については、[ECMA-262]の[ECMAScript言語：スクリプトとモジュール]セクションを参照してください。
This separation means that (in the absence of additional information) there are two possible interpretations for any given ECMAScript source text.
この分離は、（追加情報がない場合）、特定のECMAScriptソーステキストに対して2つの可能な解釈があることを意味します。
Ecma International's Technical Committee 39 (TC39), the standards body in charge of ECMAScript, has determined that media types are outside of their scope of work [TC39-MIME-ISSUE].
ECMAScriptを担当する基準機関であるECMA Internationalの技術委員会39（TC39）は、メディアタイプが作業の範囲外であると判断しました[TC39-Mime-Issue]。
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 upon content or media type alone. Therefore, as permitted by the media types in this document, scripting environments use out-of-band information in order to determine what goal should be used. Some scripting environments have chosen to adopt the file extension of .mjs for this purpose.
ECMAScriptのソーステキストが、コンテンツまたはメディアタイプのみに基づいてモジュールまたはスクリプトの文法目標を使用して解析されることを意図しているかどうかを完全に判断することはできません。したがって、このドキュメントのメディアタイプで許可されているように、スクリプト環境は、どの目標を使用すべきかを決定するために、バンド外情報を使用します。一部のスクリプト環境は、この目的のために.mjsのファイル拡張機能を採用することを選択しています。
Refer to [RFC6365] for a discussion of 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 using a character encoding scheme. A textual data object is a whole text protocol message or a whole text document, or a part of it, that is treated separately for purposes of external storage and retrieval. An implementation's internal representation of source text is not considered binary source text.
このセクションで使用されている用語の議論については、[RFC6365]を参照してください。ソーステキスト（[ECMA-262]のセクション「ソーステキスト」で定義されているように）は、バイナリソーステキストです。バイナリソーステキストは、文字エンコードスキームを使用してエンコードされたソーステキストを表すテキストデータオブジェクトです。テキストデータオブジェクトは、テキストプロトコルメッセージまたはテキストドキュメント全体、または外部ストレージと取得の目的で個別に扱われるものです。ソーステキストの実装の内部表現は、バイナリソーステキストとは見なされません。
Implementations need to determine a character encoding scheme in order to decode binary source text to 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.
実装は、バイナリソーステキストをソーステキストにデコードするために、文字エンコードスキームを決定する必要があります。このドキュメントで定義されているメディアタイプにより、オプションのcharsetパラメーターは、ソーステキストをエンコードするために使用される文字エンコードスキームを明示的に指定できます。
In order to ensure interoperability and align with widespread
implementation practices, the charset parameter is optional rather
than required, despite the recommendation in BCP 13 [RFC6838] for
text/* types.
How implementations determine the character encoding scheme can be subject to processing rules that are out of the scope of this document. For example, transport protocols can require that a 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 used in certain cases. Such requirements are not defined by this document.
実装が文字エンコードスキームを決定する方法は、このドキュメントの範囲外の処理ルールの対象となります。たとえば、輸送プロトコルでは、オプションのcharsetパラメーターが指定されていない場合、特定の文字エンコードスキームを想定する必要があります。または、特定の場合にcharsetパラメーターを使用することを要求できます。このような要件は、このドキュメントで定義されていません。
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. Source 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.
バイナリソーステキストをサポートする実装は、UTF-8 [RFC3629]文字エンコードスキームを使用してエンコードされたバイナリソーステキストをサポートする必要があります。モジュールの目標ソースは、UTF-8としてエンコードする必要があります。他のすべてのエンコーディングは失敗します。ソースの目標ソースは、UTF-8としてエンコードする必要があります。他のキャラクターエンコーディングスキームはサポートされる場合がありますが、落胆しています。u feffがバイトオーダーマーク（BOM）の署名として処理されているかどうかは、ホスト環境に依存し、このドキュメントで定義されていません。
The charset parameter provides a means to specify the character encoding scheme of binary source text. If present, the value of the charset parameter MUST be a registered charset [CHARSETS] and is considered valid if it matches the mime-charset production defined in Section 2.3 of [RFC2978].
Charsetパラメーターは、バイナリソーステキストの文字エンコードスキームを指定する手段を提供します。存在する場合、charsetパラメーターの値は登録されたcharset [charsets]でなければならず、[RFC2978]のセクション2.3で定義されているMime-Charsetの生成と一致する場合、有効と見なされます。
The charset parameter is only used when processing a Script goal source; Module goal sources MUST always be processed as UTF-8.
Charsetパラメーターは、スクリプトの目標ソースを処理するときにのみ使用されます。モジュールの目標ソースは、常にUTF-8として処理する必要があります。
It is possible that implementations cannot interoperably determine a single character encoding scheme simply by complying with all requirements of the applicable specifications. To foster interoperability in such cases, the following algorithm is defined. Implementations apply this algorithm until a single character encoding scheme is determined.
実装は、該当する仕様のすべての要件を順守するだけで、単一の文字エンコードスキームを相互に繰り返すことができない可能性があります。そのような場合に相互運用性を促進するために、次のアルゴリズムが定義されています。実装は、単一の文字エンコードスキームが決定されるまで、このアルゴリズムを適用します。
1. 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 determines the encoding. The following octet sequences, at the very beginning of the binary source text, are considered with their corresponding character encoding schemes:
1. バイナリソーステキストがモジュールの目標を使用しているとまだ決定されておらず、ユニコードエンコードフォームの署名から始まる場合、署名はエンコードを決定します。次のオクテットシーケンスは、バイナリソーステキストのまさに始まりに、対応する文字エンコードスキームで考慮されます。
+==================+==========+
| Leading sequence | Encoding |
+==================+==========+
| EF BB BF | UTF-8 |
+------------------+----------+
| FF FE | UTF-16LE |
+------------------+----------+
| FE FF | UTF-16BE |
+------------------+----------+
Table 1
表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.
このステップの実装は、これらのOctetシーケンスを使用して、決定されたスキームがサポートされていなくても、文字エンコードスキームを決定する必要があります。このステップが文字エンコードスキームを決定する場合、バイナリソーステキストをデコードするときに、ユニコードエンコードフォームの署名を表すオクテットシーケンスを無視する必要があります。
2. 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. それ以外の場合、charsetパラメーターが指定され、その値が実装によって有効でサポートされている場合、値は文字エンコードスキームを決定します。
3. Else, the character encoding scheme is assumed to be UTF-8.
3. それ以外の場合、文字エンコードスキームは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.
上記のようにステップ1以外の任意の手段を使用して文字エンコードスキームがUTF-8であると判断され、バイナリソーステキストがOctetシーケンスEF BB BFで始まる場合、バイナリソーステキストをデコードするときにOctetシーケンスは無視されます。
Binary source text that is not properly encoded for the determined character encoding can pose a security risk, as discussed in Section 5. That said, because of the varied and complex environments scripts are executed in, most of the error handling specifics are left to the processors. The following are broad guidelines that processors follow.
セクション5で説明したように、決定された文字エンコードに対して適切にエンコードされていないバイナリソーステキストは、セキュリティリスクを引き起こす可能性があります。プロセッサ。以下は、プロセッサが従う幅広いガイドラインです。
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.
バイナリソーステキストは、特定の文字エンコードスキームを使用してエンコードされたが、そのスキームに従って有効ではないオクテットシーケンスが含まれていると判断できます。実装は、これらの無効なシーケンスを置換文字u fffd（スキームに適切にエンコード）に置き換えるか、完全に処理を停止することができます。
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.
このセクションで使用されている用語の議論については、[RFC3552]を参照してください。このセクションの例と、ホスト環境と[ECMA-262]への拡張とのホスト環境との相互作用の議論は、網羅的ではなく純粋に説明的な性質として理解されるべきです。
The programming language defined in [ECMA-262] is not intended to be computationally self-sufficient; rather, it is expected that the computational environment provides facilities to programs to enable specific functionality. Such facilities constitute unknown factors and are thus not defined by this document.
[ECMA-262]で定義されているプログラミング言語は、計算的に自給自足することを意図していません。むしろ、計算環境が特定の機能を有効にするためのプログラムに設備を提供することが期待されています。このような施設は未知の要因を構成するため、このドキュメントでは定義されていません。
Derived programming languages are permitted to include additional functionality that is not described in [ECMA-262]; such functionality constitutes an unknown factor and is thus not defined by this document. In particular, extensions to [ECMA-262] defined for the JavaScript programming language are not discussed in this document.
派生したプログラミング言語は、[ECMA-262]で説明されていない追加の機能を含めることができます。このような機能は未知の要因を構成するため、このドキュメントで定義されていません。特に、JavaScriptプログラミング言語で定義された[ECMA-262]の拡張は、このドキュメントでは説明されていません。
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.
スクリプトの制御されていない実行は非常に危険です。スクリプトを実行する実装は、アプリケーションの脅威モデルと実装する個々の機能の実装を考慮する必要があります。特に、信頼されていないコンテンツが保護されていない環境で実行されないことを確認する必要があります。
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".
ECMAScriptのモジュールスクリプトは、追加のスクリプトの取得と処理を要求できます。これは「インポート」と呼ばれます。モジュールをサポートする実装は、スクリプトと同じ方法でインポートされたソースを処理する必要があります。詳細については、[ECMA-262]の[ECMAScript言語：スクリプトとモジュール]セクションを参照してください。さらに、元のスクリプトとそのインポートされたモジュールが取得される場所に応じて、追加のプライバシーとセキュリティの懸念がある場合があります。たとえば、「host-a.example」から取得したスクリプトは、「Host-b.example」からスクリプトをインポートすることを要求できます。"。
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.
たとえば、アプリケーション/XHTML XML [RFC3236]に埋め込まれたスクリプトは、ホスト環境を通じてドキュメントインスタンスを操作することができ、リモートリソースの検索を引き起こす可能性があります。この場合、埋め込み文書のリモートリソースの検索に関するセキュリティ上の考慮事項が適用されます。
This circumstance can further be used to make information that is normally only available to the script also available to a web server 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.
この状況はさらに、リソースのリソース識別子の情報をエンコードすることにより、通常、スクリプトでのみ利用可能な情報をWebサーバーでのみ利用できる情報を作成するために使用できます。このような施設の実装は、上記で説明したように、ホスト環境のセキュリティ上の考慮事項の対象となります。
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.
[ECMA-262]で定義されているプログラミング言語には、ループする施設、計算的に複雑な操作を引き起こす、または大量のメモリを消費する施設が含まれます。これには、動的に生成されたソーステキストを実行できる施設（例：eval（）関数）が含まれますが、これに限定されません。このような機能の制御されていない実行は、サービスの拒否を引き起こす可能性があり、その実装は保護する必要があります。
With the addition of SharedArrayBuffer objects in ECMAScript version 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., [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.
ECMAScriptバージョン8にSharedArrayBufferオブジェクトを追加すると、高解像度タイマーを実装することができ、特定のタイプのタイミングやサイドチャネル攻撃（[Specter]など）につながる可能性があります。実装は、SharedArrayBufferオブジェクトのサポートを無効にしたり削除したりするなど、この懸念を軽減するための措置を講じることができます。また、この共有メモリが相互信頼のある形の実行コンテキスト間でのみアクセスできるように追加の措置を講じることができます。
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.
ホスト環境は、外部入力にアクセスするための施設を提供できます。そのような入力をeval（）関数または同様の言語機能に渡すスクリプトは、コードインジェクション攻撃に対して脆弱です。スクリプトは、そのような攻撃から保護することが期待されています。
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.
UTF-8文字エンコードスキームをサポートするには、実装が必要です。[RFC3629]のセキュリティ上の考慮事項が適用されます。追加の文字エンコードスキームがサポートされる場合があります。このようなスキームのサポートは、これらのスキームのセキュリティ上の考慮事項の対象となります。
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].
ソーステキストは、Unicode Normalization Form Cを使用することが期待されています。スクリプトと実装は、非正規化されたソーステキストとデータのセキュリティへの影響を考慮する必要があります。このような意味の詳細な議論については、[RFC3629]のセキュリティ上の考慮事項を参照してください。
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.
スクリプトは、コードインジェクション攻撃に対して脆弱な環境で実行できます。たとえば、一般的なゲートウェイインターフェイス（CGI）スクリプト[RFC3875]をエコーユーザー入力により、信頼できる環境で実行できる信頼できないスクリプトを含めることができます。この脅威シナリオは、このドキュメントの範囲外であるセキュリティ上の考慮事項の対象となります。
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.
「データ」リソース識別子スキーム[RFC2397]は、このドキュメントで定義されているタイプと組み合わせて、信頼できるコンテンツに信頼できないリソース識別子を含めることにより、信頼されていないスクリプトの実行を引き起こすために使用できます。[RFC2397]のセキュリティ上の考慮事項が適用されます。
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; such failure constitutes an unknown factor and is thus not defined by this document.
実装は、おそらく危険な操作を防ぐための特定のセキュリティモデルまたはその他の手段を実装できない場合があります。このような障害は、システムまたは機密情報への不正アクセスを得るために悪用される可能性があります。このような障害は未知の要因を構成するため、このドキュメントで定義されていません。
The media type registrations herein are divided into two major categories: (1) the sole media type "text/javascript", which is now 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").
本書のメディアタイプの登録は、2つの主要なカテゴリに分割されます。（1）唯一のメディアタイプ「テキスト/JavaScript」。現在、一般的な使用法と（2）廃止されたすべてのメディアタイプ（つまり、 "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 "、および" text/x-ecmascript "）。
For both categories, the "Published specification" entry for the media types is updated to reference [ECMA-262]. In addition, 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; therefore, "text/javascript" intended usage has been moved from OBSOLETE to COMMON.
両方のカテゴリについて、メディアタイプの「公開された仕様」エントリが更新され、参照[ECMA-262]が更新されます。さらに、.MJSの新しいファイル拡張子がファイル拡張機能のリストに追加され、モジュールの目標を使用してコンテンツを解析することを制限しています。最後に、[HTML]仕様は、スクリプトタグを準備する際に、「テキスト/JavaScript」をデフォルトのメディアタイプのECMAScriptとして使用します。したがって、「Text/JavaScript」の意図的な使用法は、時代遅れから共通に移行されました。
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. 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.
これらの変更は、[RFC6838]に従って、IANAの「メディアタイプ」レジストリに反映されています。すべての登録は、このドキュメントを参照として指します。「Text/ JavaScript」メディアタイプが「アプリケーション/ JavaScriptを支持して廃止された」と述べている時代遅れのメモが削除されました。「テキスト/ECMAScript」メディアタイプが「アプリケーション/ECMAScriptを支持して廃止された」と述べている時代遅れのメモが削除されました。IANAは、「テキスト/javascript」を除くすべての登録に「テキスト/javascriptを有利に廃止した」メモを追加しました。つまり、このメモは「Text/EcMascript」、「Application/JavaScript」、および「Application/ECMAScript」登録に追加されました。
Four of the legacy media types in this document have a subtype starting with the "x-" prefix:
このドキュメントの4つのレガシーメディアタイプには、「X-」プレフィックスから始まるサブタイプがあります。
* application/x-ecmascript
* Application/X-ecmascript
* application/x-javascript
* アプリケーション/x-javascript
* text/x-ecmascript
* テキスト/x-mascript
* text/x-javascript
* テキスト/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.
これらは、[RFC6838]の付録Aに従って登録されている祖父メディアタイプであることに注意してください。これらの登録は、BCP 178 [RFC6648]より前の登録であり、違反しており、このドキュメントには後方互換性のためにのみ含まれています。
Type name: text
タイプ名：テキスト
Subtype name: javascript
サブタイプ名：JavaScript
Required parameters: N/A
必要なパラメーター：n/a
Optional parameters: charset. See Section 4.1 of RFC 9239.
オプションのパラメーター：charset。RFC 9239のセクション4.1を参照してください。
Encoding considerations: Binary
考慮事項のエンコード：バイナリ
Security considerations: See Section 5 of RFC 9239.
セキュリティ上の考慮事項：RFC 9239のセクション5を参照してください。
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.
相互運用性の考慮事項：この登録が[ECMA-262]の後期版に適用されるかのように実装が動作することが期待され、その公開された仕様参照は、それに応じて時々更新される場合があります。この期待はメディアタイプの登録では珍しいことですが、広範な業界の慣習と一致しています。RFC 9239のセクション2を参照してください。
Published specification: [ECMA-262]
公開された仕様：[ECMA-262]
Applications that use this media type: Script interpreters as discussed in RFC 9239.
このメディアタイプを使用するアプリケーション：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].
連絡先の個人およびメールアドレス詳細については、RFC 9239および[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].
使用法の制限：.mjsファイル拡張機能は、ファイルがJavaScriptモジュールを表すことを示しています。ファイル拡張機能に依存する実行環境[ECMA-262]のモジュール文法を使用して、入力を処理する方法を.mjsファイルを解析する方法を決定します。
Author: See the Authors' Addresses sections of RFC 9239 and [RFC4329].
著者：著者の住所を参照してください。RFC9239および[RFC4329]。
Change controller: IESG <iesg@ietf.org>
The following media types and legacy aliases are added or updated for historical purposes. All herein have an intended usage of OBSOLETE and are not expected to be in use with modern implementations.
以下のメディアタイプとレガシーエイリアスは、歴史的な目的で追加または更新されます。ここではすべて、時代遅れの使用を意図しており、最新の実装で使用されることは期待されていません。
Type name: text
タイプ名：テキスト
Subtype name: ecmascript
サブタイプ名：ECMAScript
Required parameters: N/A
必要なパラメーター：n/a
Optional parameters: charset. See Section 4.1 of RFC 9239.
オプションのパラメーター：charset。RFC 9239のセクション4.1を参照してください。
Encoding considerations: Binary
考慮事項のエンコード：バイナリ
Security considerations: See Section 5 of RFC 9239.
セキュリティ上の考慮事項：RFC 9239のセクション5を参照してください。
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.
相互運用性の考慮事項：この登録が[ECMA-262]の後期版に適用されるかのように実装が動作することが期待され、その公開された仕様参照は、それに応じて時々更新される場合があります。この期待はメディアタイプの登録では珍しいことですが、広範な業界の慣習と一致しています。RFC 9239のセクション2を参照してください。
Published specification: [ECMA-262]
公開された仕様：[ECMA-262]
Applications that use this media type: Script interpreters as discussed in RFC 9239.
このメディアタイプを使用するアプリケーション：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].
連絡先の個人およびメールアドレス詳細については、RFC 9239および[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].
使用に関する制限：このメディアタイプは時代遅れです。現在の実装では、Text/ JavaScriptを唯一のJavaScript/ ECMAScriptメディアタイプとして使用する必要があります。.mjsファイル拡張機能は、ファイルがJavaScriptモジュールを表すことを示しています。ファイル拡張機能に依存する実行環境[ECMA-262]のモジュール文法を使用して、入力を処理する方法を.mjsファイルを解析する方法を決定します。
Author: See the Authors' Addresses sections of RFC 9239 and [RFC4329].
著者：著者の住所を参照してください。RFC9239および[RFC4329]。
Change controller: IESG <iesg@ietf.org>
[CHARSETS] IANA, "Character Sets", <https://www.iana.org/assignments/character-sets>.
[charsets] iana、「キャラクターセット」、<https://www.iana.org/assignments/character-sets>。
[ECMA-262] Ecma International, "ECMA-262 12th Edition, June 2021. ECMAScript 2021 language specification", June 2021, <https://262.ecma-international.org/12.0/>.
[ECMA-262] ECMA International、「ECMA-262第12版、2021年6月。ECMAScript2021言語仕様」、2021年6月、<https://262.ecma-international.org/12.0/>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、DOI 10.17487/RFC2045、1996年11月、<https：//www.rfc-editor.org/info/rfc2045>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, <https://www.rfc-editor.org/info/rfc2397>.
[RFC2397] Masinter、L。、「データ」URLスキーム "、RFC 2397、DOI 10.17487/RFC2397、1998年8月、<https://www.rfc-editor.org/info/rfc2397>。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC2978] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、DOI 10.17487/RFC2978、2000年10月、<https://www.rfc-editor.org/info/rfc2978>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。and B. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487/RFC3552、2003年7月、<https：//www.rfc-editor.org/情報/RFC3552>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、DOI 10.17487/RFC3629、2003年11月、<https://www.rfc-editor.org/info/RFC3629>。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, December 2005, <https://www.rfc-editor.org/info/rfc4288>.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、RFC 4288、DOI 10.17487/RFC4288、2005年12月、<https://www.rfc-editor.org/info/RFC4288>
[RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006, <https://www.rfc-editor.org/info/rfc4329>.
[RFC4329] Hoehrmann、B。、「スクリプトメディアタイプ」、RFC 4329、DOI 10.17487/RFC4329、2006年4月、<https://www.rfc-editor.org/info/rfc4329>。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365]ホフマン、P。およびJ.クレンシン、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487/RFC6365、2011年9月、<https://www.rfc-editor.org/info/RFC6365>。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.
[RFC6648] Saint-Andre、P.、Crocker、D。、およびM. Nottingham、「アプリケーションプロトコルにおける「X」プレフィックスと同様のコンストラクトを非難する」、BCP 178、RFC 6648、DOI 10.17487/RFC6648、2012年6月、<https://www.rfc-editor.org/info/rfc6648>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487/RFC6838、2013年1月、<https：//www.rfc-editor.org/info/rfc6838>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[HTML] WHATWG, "HTML Living Standard", May 2022, <https://html.spec.whatwg.org/multipage/ scripting.html#prepare-a-script>.
[HTML] Whatwg、 "HTML Living Standard"、2022年5月、<https://html.spec.whatwg.org/multipage/ scripting.html＃prepare-a-script>。
[RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, DOI 10.17487/RFC3236, January 2002, <https://www.rfc-editor.org/info/rfc3236>.
[RFC3236] Baker、M。and P. Stark、「Application/xhtml 'Media Type」、RFC 3236、DOI 10.17487/RFC3236、2002年1月、<https://www.rfc-editor.org/info/RFC3236>。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875, October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC3875] Robinson、D。およびK. Coar、「Common Gateway Interface（CGI）バージョン1.1」、RFC 3875、DOI 10.17487/RFC3875、2004年10月、<https://www.rfc-editor.org/info/RFC3875>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC3987] Duerst、M。and M. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、DOI 10.17487/RFC3987、2005年1月、<https://www.rfc-editor.org/info/rfc3987>
[SPECTRE] Kocher, P., Genkin, D., Gruss, D., Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher, T., Schwarz, M., and Y. Yarom, "Spectre Attacks: Exploiting Speculative Execution", DOI 10.48550/arXiv.1801.01203, January 2018, <https://arxiv.org/abs/1801.01203>.
[スペクター] Kocher、P.、Genkin、D.、Gruss、D.、Haas、W.、Hamburg、M.、Lipp、M.、Mangard、S.、Prescher、T.、Schwarz、M。、Y Y。Yarom、「Spectre Attacks：Exploeding -Quationative Decution」、doi 10.48550/arxiv.1801.01203、2018年1月、<https://arxiv.org/abs/1801.01203>。
[TC39-MIME-ISSUE] TC39, "Add 'application/javascript+module' mime to remove ambiguity", Wayback Machine archive, August 2017, <https:/ /web.archive.org/web/20170814193912/https://github.com/ tc39/ecma262/issues/322>.
[TC39-MIME-ISSUE] TC39、「Add 'Application/JavaScript Module' Mime 'Mime' Mime 'Mime' Mime 'Mime' Mime "、Wayback Machine Archive、2017年8月、<https：//web.archive.org/web/20170814193912/https://githubububububub.com/tc39/ecma262/issues/322>。
* Added a section discussing ECMAScript modules and the impact on processing.
* ECMAScriptモジュールと処理への影響を議論するセクションを追加しました。
* Updated the Security Considerations section to discuss concerns associated with ECMAScript modules and SharedArrayBuffers.
* セキュリティに関する考慮事項セクションを更新して、ECMAScriptモジュールと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.
* メディアタイプの「Text/JavaScript」の意図した使用法を廃止から共通に変更しました。
* 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.
* ECMA-262への参照を更新して、出版時にバージョンと一致しました。
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.
この作品は、BjörnHöhrmannが作成した前件の文書に基づいています。著者は、Adam Roach、Alexey Melnikov、Allen Wirfs-Brock、Anne Van Kesteren、Ben Campbell、Benjamin Kaduk、Eric Vyncke、Francesca Palombini、James Snell、Kirsty Paine、Marra、およびこのプロセス全体のガイダンスとフィードバックについてのSuresh Krishnan。
Authors' Addresses
著者のアドレス
Matthew A. Miller Email: linuxwolf+ietf@outer-planes.net
Matthew A. Millerメール：Linuxwolf ietf@outer-planes.net
Myles Borins GitHub Email: mylesborins@github.com
Myles Borins Githubメール：mylesborins@github.com
Mathias Bynens Google Email: mths@google.com
Mathias Bynens Googleメール：mths@google.com
Bradley Farias Email: bradley.meck@gmail.com
Bradley Fariasメール：bradley.meck@gmail.com