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).

著作権(C)インターネット協会(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
        
1. Introduction
1. はじめに

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]で「歴史」と「概要」を参照してください。

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を定義します。

2. Conformance and Document Conventions
2.適合性およびドキュメントの表記規則

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.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.

実装は、この文書で定義されたメディアタイプのいずれかをサポートするソフトウェアモジュールです。ソフトウェア・モジュールは、複数のメディアタイプをサポートするかもしれませんが、適合は種類ごとに個別に考えられています。

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".

一つ以上を満たすことができない実装は、要件は非準拠とみなされ、「しなければなりません」。すべて満たす「MUST」要件が、1つ以上の「SHOULD」の要件を満たさない実装は、「条件付きで対応」であると言われています。他のすべての実装は、「無条件に対応」しています。

3. Deployed Scripting Media Types and Compatibility
3.展開スクリプティングメディアタイプとの互換性

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のとテキスト/ ECMAScriptのを定義しますが、「時代遅れ」としてそれらをマークします。実験及び未登録のメディアタイプの使用は、上記部分に記載されているように、推奨されています。メディアタイプ、

* application/javascript * application/ecmascript

*アプリケーション/ javascriptの*アプリケーション/ 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.

この文書では、タイプがtext / javascriptの、テキスト/ ECMAスクリプト、およびアプリケーション/ javascriptのための同等の処理要件を定義します。メディアタイプapplication / 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].

この文書で定義されたタイプは、それぞれ、ならびに[EcmaCompact]と互換性のある言語又はプロファイルに記述されたスクリプトに[JS15]及び[ECMA]で記述されたスクリプトに適用可能です。

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.

この文書は、他の言語で書かれたスクリプトに対応していません。具体的にはJavaScriptの、将来のバージョン、[ECMA]の将来版、及びそのような[E4X]として[ECMA]に拡張、直接対処されていません。この文書は、アカウントに他のコンテンツを取るために更新することができます。

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].

このドキュメントの更新は、新しいオプションのパラメータを導入することができます。実装は、そのような更新の影響を考慮しなければなりません。アプリケーション/ 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

このドキュメントは次のいずれかで標識された文書のためのリソース識別子でどのようにフラグメント識別子([RFC3986]、[RFC3987])を定義していません

the media types defined in this document are resolved. An update of this document may define processing of fragment identifiers.

この文書で定義されたメディアタイプが解決されます。この文書の更新は、フラグメント識別子の処理を定義することができます。

4. Character Encoding Scheme Handling
4.文字コード体系の処理

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の使用が奨励さが、必須ではありません。

4.1. Charset Parameter
4.1. 文字セットパラメータ

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-文字セット生産と一致しなければならない、と登録文字セット[CHARSETS]であるべきです。不正な値は、その生産と一致しない値です。

4.2. Character Encoding Scheme Detection
4.2. 文字コード体系の検出

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.バイナリソーステキストはUnicodeエンコード形式署名で始まる場合、署名は、符号化を決定します。次のオクテットのシーケンスは、バイナリソーステキストの先頭に、それに対応する文字符号化スキームとみなされます。

          +------------------+----------+
          | 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.

最長一致オクテットシーケンスが符号化を決定します。このステップの実装が決定したスキームがサポートされていない場合でも、文字符号化方式を決定するためにこれらのオクテットのシーケンスを使用しなければなりません。このステップは、文字符号化スキームを決定した場合、ソーステキストへバイナリソーステキストを復号する際に、Unicodeエンコード形式署名を表すオクテット配列を無視しなければなりません。

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であると判定され、バイナリソーステキストは、オクテット配列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.

引用された場合には、タイプがtext / javascriptの、テキスト/ ECMAスクリプト、およびアプリケーション/ジャバスクリプトの実装は、タイプアプリケーション/のECMAScriptの実装は、このセクションで定義された要件を実装しなければならないべきです。

4.3. Character Encoding Scheme Error Handling
4.3. 文字エンコーディングスキームのエラー処理

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.

次のエラー処理動作はメディアタイプがtext / javascriptの、テキスト/ ECMAスクリプト、およびアプリケーション/ javascriptのための推奨、およびメディアタイプ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.

charsetパラメータの値が不正な場合、O、実装はパラメータを無視することによって、エラーから回復したり、文字コード体系がサポートされていない考慮する必要があります。

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パラメータとUnicodeエンコーディング形式の署名:文字コード体系の情報のための2つのソースのみがあります。 charsetパラメータが指定されている場合は、バイナリソーステキストは、その文字コード体系のために定義されているように処理されます。

5. Security Considerations
5.セキュリティについての考慮事項

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]で定義されたプログラミング言語は、ループに施設を含め、計算上複雑な操作を引き起こす、または大量のメモリを消費しません。これは、動的に生成されたソーステキスト(例えば、評価()関数)を実行することを可能にする設備を含むが、これらに限定されません。そのような特徴の制御不能な実行は、実装がから保護しなければならない、サービス拒否を引き起こす可能性があります。

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正規化形式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.

実装は、おそらく危険な操作を防ぐために、特定のセキュリティモデルまたは他の手段を実装するために失敗する可能性があります。そのような障害は、おそらくシステムや機密情報への不正アクセスを得るために利用することができます。そのような障害は、未知の要因となるので、この文書の範囲外であると考えられます。

6. IANA Considerations
6. IANAの考慮事項

This document registers four new media types as defined in the following sections.

次のセクションで定義されたこの文書は4つの新しいメディアタイプを登録します。

7. JavaScript Media Types
7. JavaScriptのメディアタイプ
7.1. text/javascript (obsolete)
7.1. テキスト/ javascriptの(廃止)

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の必須パラメータ:なしオプションのパラメータ:文字セット、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

マジックナンバー(S):N /ファイルの拡張子(S):Macintoshのファイルタイプコード(S)の.js:TEXT

Person & email address to contact for further information: See Author's Address section.

人とEメールアドレスは、詳細のために連絡する:著者のアドレスのセクションを参照してください。

Intended usage: OBSOLETE Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.

意図している用法:用法上の廃止された制限事項:N /著者:著者のアドレスのセクションを参照してください。変更コントローラ:IESG。

7.2. application/javascript
7.2. アプリケーション/ javascriptの

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の必須パラメータ:なしオプションのパラメータ:文字セット、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

マジックナンバー(S):N /ファイルの拡張子(S):Macintoshのファイルタイプコード(S)の.js:TEXT

Person & email address to contact for further information: See Author's Address section.

人とEメールアドレスは、詳細のために連絡する:著者のアドレスのセクションを参照してください。

Intended usage: COMMON Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.

意図している用法:用法上のCOMMON制限事項:N /著者:著者のアドレスのセクションを参照してください。変更コントローラ:IESG。

8. ECMAScript Media Types
8. ECMAScriptのメディアタイプ
8.1. text/ecmascript (obsolete)
8.1. テキスト/ ECMAScriptの(廃止)

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の必須パラメータ:なしオプションのパラメータ:文字セット、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

マジックナンバー(S):N /ファイルの拡張子(複数可):TEXT:Macintoshのファイルタイプのコード(複数可).ES

Person & email address to contact for further information: See Author's Address section.

人とEメールアドレスは、詳細のために連絡する:著者のアドレスのセクションを参照してください。

Intended usage: OBSOLETE Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.

意図している用法:用法上の廃止された制限事項:N /著者:著者のアドレスのセクションを参照してください。変更コントローラ:IESG。

8.2. application/ecmascript
8.2. アプリケーション/ ECMAScriptの

Type name: application Subtype name: ecmascript Required parameters: none Optional parameters: charset, see section 4.1.

型名:アプリケーションのサブタイプ名:ECMAScriptの必須パラメータ:なしオプションのパラメータ:文字セット、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

マジックナンバー(S):N /ファイルの拡張子(複数可):TEXT:Macintoshのファイルタイプのコード(複数可).ES

Person & email address to contact for further information: See Author's Address section.

人とEメールアドレスは、詳細のために連絡する:著者のアドレスのセクションを参照してください。

Intended usage: COMMON Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.

意図している用法:用法上のCOMMON制限事項:N /著者:著者のアドレスのセクションを参照してください。変更コントローラ:IESG。

9. References
9.参考文献
9.1. Normative References
9.1. 引用規格

[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/出版/標準/ ECMA-262.htm>

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.

[RFC2978]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。

[RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003.

[RFC3536]ホフマン、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]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。

[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月。

9.2. Informative References
9.2. 参考文献

[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/出版/標準/ 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/出版/標準/ 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/>.
        

[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.

[RFC2397] Masinter、L.、 " "データ" URLスキーム"、RFC 2397、1998年8月。

[RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, January 2002.

[RFC3236]ベイカー、M.とP.スターク、 " 'アプリケーション/ XHTML + xmlの' メディアの種類"、RFC 3236、2002年1月。

[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004.

[RFC3875]ロビンソン、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]バーナーズ - リー、T.、フィールディング、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、 "国際化リソース識別Fiers(IRI)"、RFC 3987、2005年1月。

Author's Address

著者のアドレス

Bjoern Hoehrmann Weinheimer Strasse 22 Mannheim D-68309 Germany

ビョルンHöhrmannWeinheimerシュトラーセ22マンハイムD-68309ドイツ

EMail: bjoern@hoehrmann.de URI: http://bjoern.hoehrmann.de

電子メール:bjoern@hoehrmann.de URI:http://bjoern.hoehrmann.de

Note: Please write "Bjoern Hoehrmann" with o-umlaut (U+00F6) wherever possible, e.g., as "Bj&#246;rn H&#246;hrmann" in HTML and XML.

注意: "Bjの&#246; RN H&#246; hrmann" として、O-ウムラウト(U + 00F6)可能な限り、例えばと "ビョルンHoehrmann" を書いてくださいHTMLやXMLインチ

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2006).

著作権(C)インターネット協会(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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)によって提供されます。