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).
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. 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. 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".
the media types defined in this document are resolved. An update of this document may define processing of fragment identifiers. 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. 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. RFC2978], section 2.3, and SHOULD be a registered charset [CHARSETS]. An illegal value is a value that does not match that production.
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. 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. 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
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. 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]. 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. 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.
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. Published specification: [JS15] Applications which use this media type: Script interpreters as discussed in this document. 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.
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. Published specification: [JS15] Applications which use this media type: Script interpreters as discussed in this document. 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.
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. Published specification: [ECMA] Applications which use this media type: Script interpreters as discussed in this document. 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.
section 4.1. 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]. 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. 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.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998. [RFC3236] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, January 2002. [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. 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.
Full Copyright Statement 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. 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. 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. 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).