RFC4329 日本語訳
4329 Scripting Media Types. B. Hoehrmann. April 2006. (Format: TXT=30230 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Hoehrmann Request for Comments: 4329 April 2006 Category: Informational
Network Working Group B. Hoehrmann Request for Comments: 4329 April 2006 Category: Informational
Scripting Media Types
Scripting Media Types
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
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 describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types.
Table of Contents
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 ....................................................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
Hoehrmann Informational [Page 1] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 1] RFC 4329 Scripting Media Types April 2006
1. Introduction
1. Introduction
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.
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.
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.
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.
2. Conformance and Document Conventions
2. Conformance and Document Conventions
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.
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.
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.
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".
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".
3. Deployed Scripting Media Types and Compatibility
3. Deployed Scripting Media Types and Compatibility
Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include:
Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include:
+-----------------------------------------------------+
| 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 |
+-----------------------------------------------------+
+-----------------------------------------------------+ | 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 | +-----------------------------------------------------+
Hoehrmann Informational [Page 2] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 2] RFC 4329 Scripting Media Types April 2006
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,
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,
* 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.
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.
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.
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].
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].
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.
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.
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].
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].
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.
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.
This document does not define how fragment identifiers in resource identifiers ([RFC3986], [RFC3987]) for documents labeled with one of
This document does not define how fragment identifiers in resource identifiers ([RFC3986], [RFC3987]) for documents labeled with one of
Hoehrmann Informational [Page 3] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 3] RFC 4329 Scripting Media Types April 2006
the media types defined in this document are resolved. An update of this document may define processing of fragment identifiers.
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. Character Encoding Scheme Handling
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.
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.
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.
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.
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.
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.
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.
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.
4.1. Charset Parameter
4.1. Charset Parameter
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.
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.
4.2. Character Encoding Scheme Detection
4.2. Character Encoding Scheme Detection
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.
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.
Hoehrmann Informational [Page 4] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 4] RFC 4329 Scripting Media Types April 2006
Implementations apply this algorithm until a single character encoding scheme is determined.
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. If a charset parameter with a legal value is specified, the value determines the character encoding scheme.
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. 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:
+------------------+----------+
| 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 |
+------------------+----------+
+------------------+----------+ | 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.
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.
3. The character encoding scheme is determined to be UTF-8.
3. The character encoding scheme is determined to be 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).
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).
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.
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.
Hoehrmann Informational [Page 5] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 5] RFC 4329 Scripting Media Types April 2006
4.3. Character Encoding Scheme Error Handling
4.3. Character Encoding Scheme Error Handling
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.
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.
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 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 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 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 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 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.
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.
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.
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.
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.
5. Security Considerations
5. Security Considerations
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.
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.
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
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
Hoehrmann Informational [Page 6] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 6] RFC 4329 Scripting Media Types April 2006
specific functionality. Such facilities constitute unknown factors and are thus considered out of the scope of this document.
specific functionality. Such facilities constitute unknown factors and are thus considered out of the scope of this document.
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.
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.
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.
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.
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.
For example, scripts embedded in application/xhtml+xml [RFC3236] documents could be enabled through the host environment to manipulate the document instance, which could cause the retrieval of remote resources; security considerations regarding retrieval of remote resources of the embedding document would apply in this case.
This circumstance can further be used to make information, that is normally only available to the script, 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.
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.
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.
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.
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.
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.
Hoehrmann Informational [Page 7] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 7] RFC 4329 Scripting Media Types April 2006
A host environment can provide facilities to access external input. Scripts that pass such input to the eval() function or similar language features can be vulnerable to code injection attacks. Scripts are expected to protect against such attacks.
A host environment can provide facilities to access external input. Scripts that pass such input to the eval() function or similar language features can be vulnerable to code injection attacks. Scripts are expected to protect against such attacks.
A host environment can provide facilities to output computed results in a user-visible manner. For example, host environments supporting a graphical user interface can provide facilities that enable scripts to present certain messages to the user. Implementations MUST take steps to avoid confusion of the origin of such messages. In general, the security considerations for the host environment apply in such a case as discussed above.
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.
Implementations are required to support the UTF-8 character encoding scheme; the security considerations of [RFC3629] apply. Additional character encoding schemes may be supported; support for such schemes is subject to the security considerations of those schemes.
Source text is expected to be in Unicode Normalization Form C. Scripts and implementations MUST consider security implications of unnormalized source text and data. For a detailed discussion of such implications refer to the security considerations in [RFC3629].
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].
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.
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.
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.
The "data" resource identifier scheme [RFC2397], in combination with the types defined in this document, could be used to cause execution of untrusted scripts through the inclusion of untrusted resource identifiers in otherwise trusted content. Security considerations of [RFC2397] apply.
Implementations can fail to implement a specific security model or other means to prevent possibly dangerous operations. Such failure could possibly be exploited to gain unauthorized access to a system or sensitive information; such failure constitutes an unknown factor and is thus considered out of the scope of this document.
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 Considerations
This document registers four new media types as defined in the following sections.
This document registers four new media types as defined in the following sections.
Hoehrmann Informational [Page 8] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 8] RFC 4329 Scripting Media Types April 2006
7. JavaScript Media Types
7. JavaScript Media Types
7.1. text/javascript (obsolete)
7.1. text/javascript (obsolete)
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].
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].
Security considerations: See section 5.
Interoperability considerations:
None, except as noted in other sections of this document.
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
Published specification: [JS15]
Applications which use this media type:
Script interpreters as discussed in this document.
Published specification: [JS15] Applications which use this media type: Script interpreters as discussed in this document.
Additional information:
Additional information:
Magic number(s): n/a
File extension(s): .js
Macintosh File Type Code(s): TEXT
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.
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.
Intended usage: OBSOLETE Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
Hoehrmann Informational [Page 9] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 9] RFC 4329 Scripting Media Types April 2006
7.2. application/javascript
7.2. application/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].
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].
Security considerations: See section 5.
Interoperability considerations:
None, except as noted in other sections of this document.
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
Published specification: [JS15]
Applications which use this media type:
Script interpreters as discussed in this document.
Published specification: [JS15] Applications which use this media type: Script interpreters as discussed in this document.
Additional information:
Additional information:
Magic number(s): n/a
File extension(s): .js
Macintosh File Type Code(s): TEXT
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.
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.
Intended usage: COMMON Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
Hoehrmann Informational [Page 10] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 10] RFC 4329 Scripting Media Types April 2006
8. ECMAScript Media Types
8. ECMAScript Media Types
8.1. text/ecmascript (obsolete)
8.1. text/ecmascript (obsolete)
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].
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].
Security considerations: See section 5.
Interoperability considerations:
None, except as noted in other sections of this document.
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
Published specification: [ECMA]
Applications which use this media type:
Script interpreters as discussed in this document.
Published specification: [ECMA] Applications which use this media type: Script interpreters as discussed in this document.
Additional information:
Additional information:
Magic number(s): n/a
File extension(s): .es
Macintosh File Type Code(s): TEXT
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.
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.
Intended usage: OBSOLETE Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
Hoehrmann Informational [Page 11] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 11] RFC 4329 Scripting Media Types April 2006
8.2. application/ecmascript
8.2. application/ecmascript
Type name: application Subtype name: ecmascript Required parameters: none Optional parameters: charset, see section 4.1.
Type name: application Subtype name: ecmascript Required parameters: none Optional parameters: charset, see section 4.1.
Note: Section 3 defines error handling behavior for content
labeled with a "version" parameter.
Note: Section 3 defines error handling behavior for content labeled with a "version" parameter.
Encoding considerations:
The same as the considerations in section 3.2 of [RFC3023].
Encoding considerations: The same as the considerations in section 3.2 of [RFC3023].
Security considerations: See section 5.
Interoperability considerations:
None, except as noted in other sections of this document.
Security considerations: See section 5. Interoperability considerations: None, except as noted in other sections of this document.
Published specification: [ECMA]
Applications which use this media type:
Script interpreters as discussed in this document.
Published specification: [ECMA] Applications which use this media type: Script interpreters as discussed in this document.
Additional information:
Additional information:
Magic number(s): n/a
File extension(s): .es
Macintosh File Type Code(s): TEXT
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.
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.
Intended usage: COMMON Restrictions on usage: n/a Author: See Author's Address section. Change controller: The IESG.
Hoehrmann Informational [Page 12] RFC 4329 Scripting Media Types April 2006
Hoehrmann Informational [Page 12] RFC 4329 Scripting Media Types April 2006
9. References
9. References
9.1. Normative References
9.1. 引用規格
[CHARSETS] IANA, "Assigned character sets",
<http://www.iana.org/assignments/character-sets>.
[CHARSETS]IANA、「割り当てられた文字の組」、<http://www.iana.org/課題/文字の組>。
[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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[RFC2978]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3023] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization
in the IETF", RFC 3536, May 2003.
[RFC3536]ホフマン(P.、「IETFでの国際化に使用される用語」、RFC3536)は2003がそうするかもしれません。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing
RFC Text on Security Considerations", BCP 72, RFC
3552, July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
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/>.
[JS15]ネットスケープ・コミュニケーションズ、「コアJavaScript参照1.5インチ、2000年9月、<http://web.archive.org/*/http://devedge.netscape.com/library/manuals/2000 /javascript/1.5/reference/>。」
Hoehrmann Informational [Page 13] RFC 4329 Scripting Media Types April 2006
2006年4月にメディアタイプに原稿を書くHoehrmannの情報[13ページ]のRFC4329
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC2397] Masinter、L.、「「データ」URL計画」、RFC2397、1998年8月。
[RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml'
Media Type", RFC 3236, January 2002.
[RFC3236]ベイカーとM.とP.スターク、xmlアプリケーション/xhtml+'メディアタイプ」、RFC3236、2002年1月。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway
Interface (CGI) Version 1.1", RFC 3875, October 2004.
[RFC3875] ロビンソンとD.とK.Coar、「共通ゲートウェイインターフェイス(CGI)バージョン1.1インチ、RFC3875、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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized
Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
Author's Address
作者のアドレス
Bjoern Hoehrmann Weinheimer Strasse 22 Mannheim D-68309 Germany
ビョルンHoehrmann Weinheimerストラッセ22マンハイムD-68309ドイツ
EMail: bjoern@hoehrmann.de URI: http://bjoern.hoehrmann.de
メール: bjoern@hoehrmann.de ユリ: 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.
以下に注意してください。 どこでも、例えば、「BjöRn Höhrmann」としてHTMLとXMLで可能であるところにo-ウムラウト符号(U+00F6)で「ビョルンHoehrmann」を書いてください。
Hoehrmann Informational [Page 14] RFC 4329 Scripting Media Types April 2006
2006年4月にメディアタイプに原稿を書くHoehrmannの情報[14ページ]のRFC4329
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Hoehrmann Informational [Page 15]
Hoehrmann情報です。[15ページ]
一覧
スポンサーリンク
