[要約] RFC 4329は、スクリプトメディアタイプの定義と使用方法に関する仕様です。このRFCの目的は、スクリプトの交換と実行を容易にするための標準化を提供することです。
Network Working Group B. Hoehrmann
Request for Comments: 4329 April 2006
Category: Informational
Scripting Media Types
スクリプトメディアタイプ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.
このドキュメントでは、ECMAScriptおよびJavaScriptプログラミング言語のメディアタイプの登録と、これらのタイプの実装に関する適合要件について説明します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conformance and Document Conventions ............................2
3. Deployed Scripting Media Types and Compatibility ................2
4. Character Encoding Scheme Handling ..............................4
4.1. Charset Parameter ..........................................4
4.2. Character Encoding Scheme Detection ........................4
4.3. Character Encoding Scheme Error Handling ...................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................8
7. JavaScript Media Types ..........................................9
7.1. text/javascript (obsolete) .................................9
7.2. application/javascript ....................................10
8. ECMAScript Media Types .........................................11
8.1. text/ecmascript (obsolete) ................................11
8.2. application/ecmascript ....................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
This memo describes media types for the JavaScript and ECMAScript programming languages. Refer to "Brief History" and "Overview" in [ECMA] for background information on these languages.
このメモは、JavaScriptおよびECMAScriptプログラミング言語のメディアタイプについて説明しています。これらの言語の背景情報については、[ECMA]の「Brief History」と「概要」を参照してください。
Programs written in these programming languages have historically been interchanged using inapplicable, experimental, and unregistered media types. This document defines four of the most commonly used media types for such programs to reflect this usage in the IANA media type registry, to foster interoperability by defining underspecified aspects, and to provide general security considerations.
これらのプログラミング言語で書かれたプログラムは、歴史的に、適用できない、実験的、未登録のメディアタイプを使用して交換されてきました。このドキュメントでは、IANAメディアタイプのレジストリでのこの使用を反映し、統一されていない側面を定義することで相互運用性を促進し、一般的なセキュリティ上の考慮事項を提供するために、このようなプログラムに最も一般的に使用される4つのメディアタイプを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119] and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、[RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。特に明記しない限り、要件はすべての実装に適用されます。
An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types but conformance is considered individually for each type.
実装は、このドキュメントで定義されているメディアタイプの1つをサポートするソフトウェアモジュールです。ソフトウェアモジュールは複数のメディアタイプをサポートする場合がありますが、各タイプの適合性は個別に考慮されます。
Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant".
1つまたは複数の「マスト」要件を満たさない実装は、非準拠と見なされます。すべての「必須」要件を満たすが、1つ以上の「要件は「要件がある」とは言われていない」という要件を満たしている実装は、「条件付きに準拠している」と言われています。他のすべての実装は「無条件に準拠」です。
Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include:
さまざまな未登録のメディアタイプが、ECMAScriptおよびJavaScriptで書かれたプログラムにラベル付けおよび交換するために、アドホックな方法で使用されています。これらには以下が含まれます：
+-----------------------------------------------------+
| text/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-javascript | text/x-ecmascript |
| application/x-javascript | application/x-ecmascript |
| application/javascript | application/ecmascript |
+-----------------------------------------------------+
Use of the "text" top-level type for this kind of content is known to be problematic. This document thus defines text/javascript and text/ ecmascript but marks them as "obsolete". Use of experimental and unregistered media types, as listed in part above, is discouraged. The media types,
この種のコンテンツに「テキスト」のトップレベルタイプを使用することは、問題があることが知られています。したがって、このドキュメントは、テキスト/ JavaScriptとText/ EcMascriptを定義しますが、それらを「時代遅れ」としてマークします。上記の部分にリストされているように、実験的および未登録のメディアタイプの使用は落胆します。メディアタイプ、
* application/javascript * application/ecmascript
* Application/JavaScript * Application/ECMascript
which are also defined in this document, are intended for common use and should be used instead.
このドキュメントでも定義されており、一般的な使用を目的としており、代わりに使用する必要があります。
This document defines equivalent processing requirements for the types text/javascript, text/ecmascript, and application/javascript. Use of and support for the media type application/ecmascript is considerably less widespread than for other media types defined in this document. Using that to its advantage, this document defines stricter processing rules for this type to foster more interoperable processing.
このドキュメントでは、Types Text/JavaScript、Text/ECMascript、およびApplication/JavaScriptの同等の処理要件を定義します。メディアタイプアプリケーション/ECMAScriptの使用とサポートは、このドキュメントで定義されている他のメディアタイプよりもかなり普及していません。これを有利に使用して、このドキュメントでは、このタイプのより厳格な処理ルールを定義して、より多くの相互運用処理を促進します。
The types defined in this document are applicable to scripts written in [JS15] and [ECMA], respectively, as well as to scripts written in a compatible language or profile such as [EcmaCompact].
このドキュメントで定義されているタイプは、それぞれ[JS15]と[ECMA]で書かれたスクリプトと、[Ecmacompact]などの互換性のある言語またはプロファイルで記述されたスクリプトに適用できます。
This document does not address scripts written in other languages. In particular, future versions of JavaScript, future editions of [ECMA], and extensions to [ECMA], such as [E4X], are not directly addressed. This document may be updated to take other content into account.
このドキュメントは、他の言語で記述されたスクリプトには対応していません。特に、[ECMA]の[ECMA]の将来のエディション、[ECMA]の拡張、[E4X]などの将来のバージョンは、直接対処されません。このドキュメントは、他のコンテンツを考慮に入れるために更新される場合があります。
Updates of this document may introduce new optional parameters; implementations MUST consider the impact of such an update. For the application/ecmascript media type, implementations MUST NOT process content labeled with a "version" parameter as if no such parameter had been specified; this is typically achieved by treating the content as unsupported. This error handling behavior allows extending the definition of the media type for content that cannot be processed by implementations of [ECMA].
このドキュメントの更新により、新しいオプションのパラメーターが導入される場合があります。実装は、このような更新の影響を考慮する必要があります。Application/ECMAScriptメディアタイプの場合、実装は、そのようなパラメーターが指定されていないかのように、「バージョン」パラメーターでラベル付けされたコンテンツを処理してはなりません。これは通常、コンテンツをサポートされていないものとして扱うことによって達成されます。このエラー処理動作により、[ECMA]の実装では処理できないコンテンツのメディアタイプの定義を拡張できます。
The programming languages defined in [JS15] and [ECMA] share a common subset. Choice of a type for scripts compatible with both languages is out of the scope of this document.
[JS15]および[ECMA]で定義されているプログラミング言語は、共通のサブセットを共有しています。両方の言語と互換性のあるスクリプトのタイプの選択は、このドキュメントの範囲外です。
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]）のフラグメント識別子がどのように解決されるかを定義しません。このドキュメントの更新では、フラグメント識別子の処理を定義する場合があります。
Refer to [RFC3536] for a discussion of terminology used in this section. Source text (as defined in [ECMA], section 6) 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 and source text are not considered binary source text.
このセクションで使用されている用語の議論については、[RFC3536]を参照してください。ソーステキスト（[ECMA]、セクション6で定義されている）は、バイナリソーステキストです。バイナリソーステキストは、文字エンコードスキームを使用してエンコードされたソーステキストを表すテキストデータオブジェクトです。テキストデータオブジェクトは、テキストプロトコルメッセージまたはテキストドキュメント全体、またはその一部であり、外部ストレージと検索の目的で個別に扱われます。ソーステキストとソーステキストの実装の内部表現は、バイナリソーステキストとは見なされません。
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パラメーターは、ソーステキストをエンコードするために使用される文字エンコードスキームを明示的に指定できます。
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 considered part of this document.
実装が文字エンコードスキームを決定する方法は、このドキュメントの範囲外の処理ルールの対象となります。たとえば、トランスポートプロトコルでは、オプションのcharsetパラメーターが指定されていない場合、特定の文字エンコードスキームを想定する必要があります。または、特定の場合にcharsetパラメーターを使用することを要求できます。このような要件は、このドキュメントの一部とは見なされません。
Implementations that support binary source text MUST support binary source text encoded using the UTF-8 [RFC3629] character encoding scheme. Other character encoding schemes MAY be supported. Use of UTF-8 to encode binary source text is encouraged but not required.
バイナリソーステキストをサポートする実装は、UTF-8 [RFC3629]文字エンコードスキームを使用してエンコードされたバイナリソーステキストをサポートする必要があります。他の文字エンコーディングスキームがサポートされる場合があります。UTF-8を使用してバイナリソーステキストをエンコードすることをお勧めしますが、必要ありません。
The charset parameter provides a means to specify the character encoding scheme of binary source text. Its value MUST match the mime-charset production defined in [RFC2978], section 2.3, and SHOULD be a registered charset [CHARSETS]. An illegal value is a value that does not match that production.
Charsetパラメーターは、バイナリソーステキストの文字エンコードスキームを指定する手段を提供します。その値は、[RFC2978]、セクション2.3で定義されているMime-Charsetの生産と一致する必要があり、登録されたチャーセット[charsets]でなければなりません。違法価値は、その生産と一致しない価値です。
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 a charset parameter with a legal value is specified, the value determines the character encoding scheme.
1. 法的値を持つcharsetパラメーターが指定されている場合、値は文字エンコードスキームを決定します。
2. If the binary source text 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:
2. バイナリソーステキストがユニコードエンコードフォームの署名から始まる場合、署名はエンコーディングを決定します。次のオクテットシーケンスは、バイナリソーステキストのまさに始まりに、対応する文字エンコードスキームで考慮されます。
+------------------+----------+
| Leading sequence | Encoding |
+------------------+----------+
| FF FE 00 00 | UTF-32LE |
| 00 00 FE FF | UTF-32BE |
| FF FE | UTF-16LE |
| FE FF | UTF-16BE |
| EF BB BF | UTF-8 |
+------------------+----------+
The longest matching octet sequence determines the encoding. 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 to source text.
最も長い一致するオクテットシーケンスは、エンコードを決定します。このステップの実装は、これらのOctetシーケンスを使用して、決定されたスキームがサポートされていなくても、文字エンコードスキームを決定する必要があります。このステップが文字エンコードスキームを決定する場合、バイナリソーステキストをソーステキストにデコードするときに、ユニコードエンコードフォームの署名を表すオクテットシーケンスを無視する必要があります。
3. The character encoding scheme is determined to be UTF-8.
3. 文字エンコードスキームは、UTF-8であると判断されます。
If the character encoding scheme is determined to be UTF-8 through any means other than step 2 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 to source text. (The sequence will also be ignored if step 2 determines the character encoding scheme per the requirements in step 2).
文字エンコードスキームが上記のようにステップ2以外の任意の手段を介してUTF-8であると判断され、バイナリソーステキストがOctetシーケンスEF BB BFで始まる場合、バイナリソーステキストをデコードするとソーステキストをデコードすると、オクテットシーケンスが無視されます。。（ステップ2がステップ2の要件ごとに文字エンコードスキームを決定する場合、シーケンスも無視されます）。
In the cited case, implementations of the types text/javascript, text/ecmascript, and application/javascript SHOULD and implementations of the type application/ecmascript MUST implement the requirements defined in this section.
引用されたケースでは、Types Text/JavaScript、Text/ECMAScript、およびApplication/JavaScriptの実装とType Application/ECMAScriptの実装は、このセクションで定義されている要件を実装する必要があります。
The following error processing behavior is RECOMMENDED for the media types text/javascript, text/ecmascript, and application/javascript, and REQUIRED for the media type application/ecmascript.
メディアタイプのテキスト/JavaScript、Text/ECMAScript、およびApplication/JavaScriptには、次のエラー処理動作が推奨され、Media Type Application/ECMAScriptに必要です。
o If the value of a charset parameter is illegal, implementations MUST either recover from the error by ignoring the parameter or consider the character encoding scheme unsupported.
o charsetパラメーターの値が違法である場合、実装はパラメーターを無視してエラーから回復するか、サポートされていない文字エンコードスキームを考慮する必要があります。
o If binary source text is determined to have been encoded using a certain character encoding scheme that the implementation is unable to process, implementations MUST consider the resource unsupported (i.e., they MUST NOT decode the binary source text using a different character encoding scheme).
o バイナリソーステキストが、実装が処理できない特定の文字エンコードスキームを使用してエンコードされたと判断された場合、実装はサポートされていないリソースを考慮する必要があります（つまり、異なる文字エンコードスキームを使用してバイナリソーステキストをデコードしてはなりません）。
o Binary source text can be determined to have been encoded using a certain character encoding scheme but contain octet sequences that are not legal according to that scheme. This is typically caused by a lack of proper character encoding scheme information; such errors can pose a security risk, as discussed in section 5.
o バイナリソーステキストは、特定の文字エンコードスキームを使用してエンコードされたが、そのスキームに従って合法ではないオクテットシーケンスを含むと判断できます。これは通常、適切な文字エンコードスキーム情報の欠如によって引き起こされます。セクション5で説明したように、このようなエラーはセキュリティリスクをもたらす可能性があります。
Implementations SHOULD detect such errors as early as possible; in particular, they SHOULD detect them before interpreting any of the source text. Implementations MUST detect such errors and MUST NOT interpret any source text after detecting such an error. Such errors MAY be reported, e.g., as syntax errors as defined in [ECMA], section 16.
実装では、できるだけ早くそのようなエラーを検出する必要があります。特に、ソーステキストを解釈する前にそれらを検出する必要があります。実装はそのようなエラーを検出する必要があり、そのようなエラーを検出した後、ソーステキストを解釈してはなりません。このようなエラーは、[ECMA]、セクション16で定義されている構文エラーとして報告される場合があります。
This document does not define facilities that allow specification of the character encoding scheme used to encode binary source text in a conflicting manner. There are only two sources for character encoding scheme information: the charset parameter and the Unicode encoding form signature. If a charset parameter is specified, binary source text is processed as defined for that character encoding scheme.
このドキュメントでは、バイナリソーステキストを競合する方法でエンコードするために使用される文字エンコードスキームの指定を可能にする機能を定義しません。文字エンコードスキーム情報には、charsetパラメーターとユニコードエンコードフォームの署名の2つのソースのみがあります。charsetパラメーターが指定されている場合、その文字エンコードスキームで定義されているようにバイナリソーステキストが処理されます。
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 and extensions to [ECMA] are to be understood as non-exhaustive and of a purely illustrative nature.
このセクションで使用されている用語の議論については、[RFC3552]を参照してください。このセクションの例と、ホスト環境と[ECMA]への拡張とのホスト環境との相互作用の議論は、網羅的ではなく純粋に実例のある性質として理解されるべきです。
The programming language defined in [ECMA] 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 considered out of the scope of this document.
[ECMA]で定義されているプログラミング言語は、計算的に自給自足であることを意図したものではなく、計算環境が特定の機能を有効にするためのプログラムに施設を提供することが期待されています。このような施設は未知の要因を構成するため、このドキュメントの範囲外であると見なされます。
Derived programming languages are permitted to include additional functionality that is not described in [ECMA]; such functionality constitutes an unknown factor and is thus considered out of the scope of this document. In particular, extensions to [ECMA] defined for the JavaScript programming language are not discussed in this document.
派生したプログラミング言語は、[ECMA]で説明されていない追加の機能を含めることができます。このような機能は未知の要因を構成するため、このドキュメントの範囲外であると見なされます。特に、JavaScriptプログラミング言語で定義された[ECMA]の拡張については、このドキュメントでは説明されていません。
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.
スクリプトの制御されていない実行は非常に危険です。スクリプトを実行する実装は、アプリケーションの脅威モデルと実装する個々の機能の実装を考慮する必要があります。特に、信頼されていないコンテンツが保護されていない環境で実行されないようにする必要があります。
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, 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 facilities defined in [ECMA] do not include provisions for input of external data, output of computed results, or modification of aspects of the host environment. An implementation of only the facilities defined in [ECMA] is not considered to support dangerous operations.
[ECMA]で定義されている施設には、外部データの入力、計算結果の出力、またはホスト環境の側面の変更に関する規定は含まれていません。[ECMA]で定義されている施設のみの実装は、危険な運用をサポートするとは見なされません。
The programming language defined in [ECMA] 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]で定義されているプログラミング言語には、ループする施設、計算上の複雑な操作の原因、または大量のメモリを消費する施設が含まれます。これには、動的に生成されたソーステキストを実行できるようにする機能が含まれますが、これらに限定されません（例：eval（）関数など）。このような機能の制御されていない実行は、サービスの拒否を引き起こす可能性があり、その実装は保護する必要があります。
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。C。スクリプトと実装が、非正規化されたソーステキストとデータのセキュリティへの影響を考慮する必要があります。このような意味の詳細な議論については、[RFC3629]のセキュリティ上の考慮事項を参照してください。
Scripts can be executed in an environment that is vulnerable to code injection attacks. For example, a 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 considered out of the scope of this document.
実装は、おそらく危険な操作を防ぐための特定のセキュリティモデルまたはその他の手段を実装できない場合があります。このような障害は、システムまたは機密情報への不正アクセスを得るために悪用される可能性があります。このような障害は未知の要因を構成するため、このドキュメントの範囲外であると見なされます。
This document registers four new media types as defined in the following sections.
このドキュメントは、次のセクションで定義されている4つの新しいメディアタイプを登録します。
Type name: text Subtype name: javascript Required parameters: none Optional parameters: charset, see section 4.1. Encoding considerations: The same as the considerations in section 3.1 of [RFC3023].
タイプ名：テキストサブタイプ名：JavaScript必要なパラメーター：なしオプションのパラメーター：charset、セクション4.1を参照してください。考慮事項のエンコード：[RFC3023]のセクション3.1の考慮事項と同じ。
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
セキュリティ上の考慮事項：セクション5を参照してください。このドキュメントの他のセクションで述べられている場合を除き、相互運用性の考慮事項：なし。
Published specification: [JS15] Applications which use this media type: Script interpreters as discussed in this document.
公開された仕様：[JS15]このメディアタイプを使用するアプリケーション：このドキュメントで説明したスクリプト通訳者。
Additional information:
追加情報：
Magic number(s): n/a
File extension(s): .js
Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: See Author's Address section.
詳細については、連絡先の個人とメールアドレス：著者のアドレスセクションを参照してください。
Intended usage: OBSOLETE Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
意図された使用法：使用に関する廃止された制限：n/a著者：著者のアドレスセクションを参照してください。Change Controller：IESG。
Type name: application Subtype name: javascript Required parameters: none Optional parameters: charset, see section 4.1. Encoding considerations: The same as the considerations in section 3.2 of [RFC3023].
タイプ名：アプリケーションサブタイプ名：JavaScript必要なパラメーター：なしオプションパラメーター：charset、セクション4.1を参照してください。考慮事項のエンコード：[RFC3023]のセクション3.2の考慮事項と同じ。
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
セキュリティ上の考慮事項：セクション5を参照してください。このドキュメントの他のセクションで述べられている場合を除き、相互運用性の考慮事項：なし。
Published specification: [JS15] Applications which use this media type: Script interpreters as discussed in this document.
公開された仕様：[JS15]このメディアタイプを使用するアプリケーション：このドキュメントで説明したスクリプト通訳者。
Additional information:
追加情報：
Magic number(s): n/a
File extension(s): .js
Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: See Author's Address section.
詳細については、連絡先の個人とメールアドレス：著者のアドレスセクションを参照してください。
Intended usage: COMMON Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
意図された使用法：使用に関する一般的な制限：n/a著者：著者のアドレスセクションを参照してください。Change Controller：IESG。
Type name: text Subtype name: ecmascript Required parameters: none Optional parameters: charset, see section 4.1. Encoding considerations: The same as the considerations in section 3.1 of [RFC3023].
タイプ名：テキストサブタイプ名：ecMascript要求パラメーター：なしオプションパラメーター：charset、セクション4.1を参照してください。考慮事項のエンコード：[RFC3023]のセクション3.1の考慮事項と同じ。
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
セキュリティ上の考慮事項：セクション5を参照してください。このドキュメントの他のセクションで述べられている場合を除き、相互運用性の考慮事項：なし。
Published specification: [ECMA] Applications which use this media type: Script interpreters as discussed in this document.
公開された仕様：[ECMA]このメディアタイプを使用するアプリケーション：このドキュメントで説明したスクリプト通訳者。
Additional information:
追加情報：
Magic number(s): n/a
File extension(s): .es
Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: See Author's Address section.
詳細については、連絡先の個人とメールアドレス：著者のアドレスセクションを参照してください。
Intended usage: OBSOLETE Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
意図された使用法：使用に関する廃止された制限：n/a著者：著者のアドレスセクションを参照してください。Change Controller：IESG。
Type name: application Subtype name: ecmascript Required parameters: none Optional parameters: charset, see section 4.1.
タイプ名：アプリケーションサブタイプ名：ecMascript要求パラメーター：なしオプションパラメーター：charset、セクション4.1を参照してください。
Note: Section 3 defines error handling behavior for content labeled with a "version" parameter.
注：セクション3では、「バージョン」パラメーターでラベル付けされたコンテンツのエラー処理動作を定義しています。
Encoding considerations: The same as the considerations in section 3.2 of [RFC3023].
考慮事項のエンコード：[RFC3023]のセクション3.2の考慮事項と同じ。
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
セキュリティ上の考慮事項：セクション5を参照してください。このドキュメントの他のセクションで述べられている場合を除き、相互運用性の考慮事項：なし。
Published specification: [ECMA] Applications which use this media type: Script interpreters as discussed in this document.
公開された仕様：[ECMA]このメディアタイプを使用するアプリケーション：このドキュメントで説明したスクリプト通訳者。
Additional information:
追加情報：
Magic number(s): n/a
File extension(s): .es
Macintosh File Type Code(s): TEXT
Person & email address to contact for further information: See Author's Address section.
詳細については、連絡先の個人とメールアドレス：著者のアドレスセクションを参照してください。
Intended usage: COMMON Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
意図された使用法：使用に関する一般的な制限：n/a著者：著者のアドレスセクションを参照してください。Change Controller：IESG。
[CHARSETS] IANA, "Assigned character sets", <http://www.iana.org/assignments/character-sets>.
[charsets] iana、「割り当てられた文字セット」、<http://www.iana.org/assignments/character-sets>。
[ECMA] European Computer Manufacturers Association, "ECMAScript Language Specification 3rd Edition", December 1999, <http://www.ecma-international.org/ publications/standards/Ecma-262.htm>
[ECMA]欧州コンピューターメーカー協会、「ECMAScript言語仕様第3版」、1999年12月、<http://www.ecma-international.org/ Publications/Standards/ECMA-262.htm>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003.
[RFC3536] Hoffman、P。、「IETFの国際化で使用される用語」、RFC 3536、2003年5月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[E4X] European Computer Manufacturers Association, "ECMAScript for XML (E4X)", June 2004, <http://www.ecma-international.org/ publications/standards/Ecma-357.htm>
[E4X]欧州コンピューターメーカー協会、「XML（E4X）のECMAScript」、2004年6月、<http://www.ecma-international.org/ Publications/Standards/ecma-357.htm>>>
[EcmaCompact] European Computer Manufacturers Association, "ECMAScript 3rd Edition Compact Profile", June 2001, <http://www.ecma-international.org/ publications/standards/Ecma-327.htm>
[ECMACOMPACT]欧州コンピューターメーカー協会、「ECMAScript第3版コンパクトプロファイル」、2001年6月、<http://www.ecma-international.org/ Publications/Standards/ecma-327.htm>>>
[JS15] Netscape Communications Corp., "Core JavaScript Reference 1.5", September 2000, <http://web.archive.org/*/http:// devedge.netscape.com/library/manuals/2000 /javascript/1.5/reference/>.
[JS15] Netscape Communications Corp.、「Core JavaScript Reference 1.5」、2000年9月、<http://web.archive.org/*/http:// devedge.netscape.com/library/manuals/2000 /javascript/1.5/参照/>。
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2397] Masinter、L。、 "The" Data "URL Scheme"、RFC 2397、1998年8月。
[RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, January 2002.
[RFC3236] Baker、M。and P. Stark、「Application/XHTML XML 'Media Type」、RFC 3236、2002年1月。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004.
[RFC3875] Robinson、D。およびK. Coar、「Common Gateway Interface（CGI）バージョン1.1」、RFC 3875、2004年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
Author's Address
著者の連絡先
Bjoern Hoehrmann Weinheimer Strasse 22 Mannheim D-68309 Germany
Bjoern Hoehrmann Weinheimer Strasse 22 Mannheim D-68309ドイツ
EMail: bjoern@hoehrmann.de
URI: http://bjoern.hoehrmann.de
Note: Please write "Bjoern Hoehrmann" with o-umlaut (U+00F6) wherever possible, e.g., as "Björn Höhrmann" in HTML and XML.
注：HTMLおよびXMLの「BJ＆＃246; rn h＆＃246; hrmann」など、可能な限りo-umlaut（u 00F6）で「Bjoern hoehrmann」を書いてください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。