WDIFF

draft-hoehrmann-script-types-00.txt --> draft-hoehrmann-script-types-01.txt

Network Working Group B. Hoehrmann
Internet-Draft September 21, 2001 February 5, 2005
Expires: March 22, 2002

JavaScript and ECMAScript August 9, 2005

Scripting Media Types
<draft-hoehrmann-script-types-00.txt>
draft-hoehrmann-script-types-01

Status of this Memo

This document is an Internet-Draft and is in full conformance with subject to all provisions
of Section 10 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of RFC2026.
which he or she become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 22, 2002. August 9, 2005.

Abstract

JavaScript and ECMAScript are Scripting Languages commonly used on
the World Wide Web for years, using various unregistered Media Types.

This memo seeks to regularize that position by formally registering
Media Types describes media types for these Scripting Languages. the ECMAScript and JavaScript
programming languages.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 1]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001 February 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 History and Standardization Background . . . . . . . . . . . . . . . . . 3
1.2 Implementations and Usage . . . . . . 3
1.2 Deployed Scripting Media Types . . . . . . . . . . . . . 3
1.3 Rationale Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
2. Conformance and Document Conventions used in this document . . . . . . . . . . . . . . 4 5
3. The text/javascript Media Type . . Character Encoding Scheme Handling . . . . . . . . . . . . . . 4 5
3.1 Notes on text/javascript Charset Parameter . . . . . . . . . . . . . . . . . . . 4 6
3.2 Registration of text/javascript . . . . . . . . . . . . . . . 4
4. The application/javascript Media Type . . Character Encoding Scheme Detection . . . . . . . . . . 5
4.1 Notes on application/javascript 6
3.3 Character Encoding Scheme Error Handling . . . . . . . . 7
4. Security Considerations . . . . . . . 5
4.2 Registration of application/javascript . . . . . . . . . . . . 6 8
5. The text/ecmascript Media Type . . . . . . . . . . . . . . . . 7
5.1 Notes on text/ecmascript . IANA Considerations . . . . . . . . . . . . . . . . . . 7
5.2 Registration of text/ecmascript . . . 10
6. JavaScript Media Types . . . . . . . . . . . . 7
6. Registration Details . . . . . . . . 10
6.1 text/javascript . . . . . . . . . . . . . 8
6.1 The charset parameter . . . . . . . 10
6.2 application/javascript . . . . . . . . . . . . . 8
6.2 The version parameter . . . . 11
7. ECMAScript Media Types . . . . . . . . . . . . . . . . 8
6.3 Encoding Considerations . . . . 12
7.1 text/ecmascript . . . . . . . . . . . . . . . 8
6.4 Security Considerations . . . . . 12
7.2 application/ecmascript . . . . . . . . . . . . . . 8
6.5 Interoperability Considerations . . . 13
8. References . . . . . . . . . . . . 10
6.6 Published JavaScript specifications . . . . . . . . . . . . . 10
6.7 Published ECMAScript Specifications . 14
8.1 Normative References . . . . . . . . . . . . 10
6.8 Accessibility Considerations . . . . . . 14
8.2 Informative References . . . . . . . . . . . 10
7. Notes on Microsoft's JScript language . . . . . . 14
Author's Address . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 16

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 2]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001 February 2005

1. Introduction

1.1 History and Standardization

JavaScript is a cross-platform, object-based scripting language
originally developed by Netscape Communications Corp. It is beeing
used since 1995 on web pages on Background

This memo describes media types for the World Wide Web and in various
other environments. In 1997 JavaScript was formally standardized by
TC 39 of the European Computer Manufacturers Association (ECMA) as
ECMA-262 [ECMA-262] ("ECMAScript") and adopted by the International
Standardization Organization (ISO) as ISO/IEC 16262:1998 [ISO16262]
in April 1998.

NOTE: JavaScript is a trademark of Sun Microsystems, Inc. It was
originally called LiveScript. It has nothing ECMAScript
programming languages. Refer to do with the Java
Language.

1.2 Implementations "Brief History" and Usage

Several web browsers support the ability to download programs with an
HTML document "Overview" in
[ECMA] for background information on these languages.

Programs written in these programming languages have historically
been interchanged using inapplicable, experimental, and execute them within unregistered
media types. This document defines four of the browser. These programs
are typically most commonly used
media types for such programs to interact with the browser user and adding
dynamic features to otherwise static content. The first
implementation of JavaScript was reflect this usage in the web browser Netscape Navigator
2.0 developed IANA media
type registry, foster interoperability by Netscape Communications Corporation. But ECMAScript defining underspecified
aspects, and JavaScript are by no means limited to browsers or client-side
applications in general. For example, SVG 1.0 [SVG10] (an XML-based
vector graphics format) requires Dynamic SVG Viewers to support
ECMAScript provide general security considerations.

1.2 Deployed Scripting Media Types

Media types used to allow animation of and interaction with exchange programs written in the graphic,
and beforementioned
programming languages or similar variants thereof include:

Of these types, this document defines the Netscape Enterprise Server provides a means to following:

* text/javascript
* text/ecmascript
* application/javascript
* application/ecmascript

Use of their experimental counterparts is discouraged per [RFC2048],
section 2.1.4. Use of other types for scripts that could use JavaScript
on the server-side. Available Open Source implementations like
SpiderMonkey (<http://www.mozilla.org/js/spidermonkey/>) and Rhino
(<http://www.mozilla.org/rhino/>) ease the usage one of these scripting
languages
the types defined in other domains.

1.3 Rationale

Many common Internet this document as well is discouraged.

The media types text/javascript and World Wide Web protocols require the use application/javascript are not
considered distinct in this document. Use of
properly registered Media Types to identify additional names for
the same media type of local or
remote resources. Unfortunately no Media Types for JavaScript is discouraged and
ECMAScript were officially registered. As a result of this omission,
private Media Types like application/x-javascript are used to
identify these scripting languages. This memo seeks to regularize
that position by formally registering Media Types for these Scripting
Languages. While it may be ok for some people to use these private
and/or unregistered Media Types, it isn't for others. Some
organizations have strict policies towards standards, is thus they may
be unable to use expected that an
update of this document deprecates one of these Scripting Languages at all. types.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 3]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001 February 2005

This memo does not introduce new Media Types, it just registers the
Media Types used document considers text/ecmascript and application/ecmascript
distinct in terms of processing rules; use of and support for several years now. It the
media type application/ecmascript is not acceptable to
break with common practice on million considerably less widespread
than of web sites, thus there has
been no chance to choose Media Types text/ecmascript; this document takes that would potentially be more
appropriate.

NOTE: The author of to its advantage
and defines stricter processing rules for this memo type to foster more
interoperable processing. It is not affiliated with any expected that an update of the
companies and organizations mentioned in this document.

2. Conventions used in this
document will deprecate the media type text/ecmascript.

1.3 Compatibility

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" types defined in this document are applicable to be interpreted as described scripts written
in [RFC2119] .

3. The text/javascript Media Type

3.1 Notes on text/javascript

The Media Type text/javascript is being used for internal [JS15] and [ECMA] respectively as well as to scripts written in
HTML documents a
compatible language and some external scripts. It should be used corresponding profiles such as [EcmaCompact].

This document does not address scripts written in favor other languages, in
particular, future versions of JavaScript, future editions of [ECMA],
and extensions to application/javascript where appropriate. ECMAScript scripts [ECMA] such as [E4X] are not directly addressed.
This document may be labeled with this Media Type if they are conforming updated to a given
version of JavaScript.

3.2 Registration of text/javascript

MIME media type name: text

MIME subtype name: javascript

Required parameters: none

Optional parameters:

charset

See Section 6.1 extend the definition of the types in
this document.

version

See Section 6.2 document to take other content into account.

Updates of this document.

Encoding considerations:
See Section 6.3 document may introduce new optional parameters,
implementations MUST consider the impact of such an update.

For the application/ecmascript media type this document.

Security considerations:
See Section 6.4 document reserves the
parameter "version" to allow updates of this document.

Hoehrmann Expires March 22, 2002 [Page 4]

Internet-Draft JavaScript and ECMAScript Media Types September 2001

Interoperability considerations:
See Section 6.5 document to extend the
media type for content that is not compatible to implementations of this document.

Published specification:
See Section 6.6
[ECMA].

Implementations of this document.

Applications which use this the application/ecmascript media type:
See Section 1.2 type MUST NOT
process content labeled with a version parameter as if no version
parameter had been specified. This requirement is generally
satisfied by treating such content as unsupported. Processing of
unsupported content is out of scope of this document.

Additional information:

Magic number(s): none
File extension(s): js
Macintosh File Type Code(s): TEXT

Person & email address to contact

This document does not define similar means for further information:

Bjoern Hoehrmann <bjoern@hoehrmann.de>

Intended usage: COMMON

Author/Change controller:

JavaScript is any other type as
deployed software typically ignores unknown parameters which renders
such a work product reserved parameter of Netscape Communications
Corporation. Netscape has change control over the JavaScript
specification.

4. The application/javascript Media Type

4.1 Notes on application/javascript

The private Media Type application/x-javascript has been used little use for
external scripts linked from HTML documents. those types.

The leading web server
software Apache (http://httpd.apache.org/) uses it as default programming languages defined in [JS15] and [ECMA] share a common
subset. Choice of a type for files with the file name extension ".js".

Some early implementations of JavaScript may require this Media Type scripts compatible to recognize JavaScript, but usage of text/javascript both languages is preferred
where compatibility
subject to these implementations isn't required, thus the
registration factors out of application/javascript in this memo lists "LIMITED
USE" as intended usage.

Applications SHOULD support the "x-"-prefixed Media Type
"application/x-javascript" as alias scope of application/javascript for
compatibility reasons.

ECMAScript scripts MAY be labeled with this Media Type if they are

Hoehrmann Expires March 22, 2002 [Page 5]

Internet-Draft JavaScript document and ECMAScript Media Types September 2001

conforming to a given version thus not
addressed.

This document does not define how fragment identifiers in resource
identifiers ([RFC3986], [RFC3987]) for documents of JavaScript.

4.2 Registration one of application/javascript

MIME the media type name: application

MIME subtype name: javascript

Required parameters: none

Optional parameters:

charset

See Section 6.1 of this document.

version

See Section 6.2 of this document.

Encoding considerations:
See Section 6.3 of this document.

Security considerations:
See Section 6.4 of this document.

Interoperability considerations:
See Section 6.5 of
types defined in this document.

Published specification:
See Section 6.6 document are resolved. An update of this document.

Applications which use this media type:
See Section 1.2
document may define processing of this document.

Additional information:

Magic number(s): none
File extension(s): js
Macintosh File Type Code(s): TEXT

Person & email address to contact for further information:

Bjoern Hoehrmann <bjoern@hoehrmann.de>

Intended usage: COMMON

Author/Change controller: fragment identifiers.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 6] 4]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001

JavaScript is a work product of Netscape Communications
Corporation. Netscape has change control over the JavaScript
specification.

5. February 2005

2. Conformance and Document Conventions

The text/ecmascript Media Type

5.1 Notes on text/ecmascript

By the best of the author's knowledge, this Media Type has been
introduced by the SVG [SVG10] specifications. It is beeing used
there key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and defined as the default value for the 'contentScriptType'
attribute of the 'svg' element.

JavaScript scripts may be labeled with "OPTIONAL" in this Media Type if they
document are
conforming 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 given revision of ECMA-262.

5.2 Registration software module that supports one of text/ecmascript

MIME the media type name: text

MIME subtype name: ecmascript

Required parameters: none

Optional parameters:

charset

See Section 6.1 of this document.

version

See Section 6.2 of
types defined in this document. Software modules may support
multiple media types but are considered multiple implementations.

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. Character Encoding considerations:
See Section 6.3 of this document.

Security considerations:
See Section 6.4 Scheme Handling

Refer to [RFC3536] for a discussion of terminology in this document.

Interoperability considerations:
See Section 6.5 section.

Source text ([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 this document.

Published specification:
See Section 6.7
it, that is treated separately for purposes of this document.

Applications which use this media type:

Hoehrmann Expires March 22, 2002 [Page 7]

Internet-Draft JavaScript external storage and ECMAScript Media Types September 2001

See Section 1.2
retrieval. An implementation's internal representation of this document.

Additional information:

Magic number(s): none
File extension(s): ecma, es
Macintosh File Type Code(s): TEXT

Person & email address source
text and source text are not considered binary source text.

Implementations need to contact for further information:

Bjoern Hoehrmann <bjoern@hoehrmann.de>

Intended usage: COMMON

Author/Change controller:

ECMAScript is determine a work product of Technical Committee 39 of the
European Computer Manufacturers Association (ECMA). ECMA has
change control over the ECMA-262 specification.

6. Registration Details

6.1 The charset parameter 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 "charset" refers to
explicitly specify the character encoding scheme used to represent encode the ECMAScript respectively
source text.

How implementations determine the JavaScript document
as a sequence of bytes. Any registered IANA charset may be used, but
UTF-8 is preferred. Although this parameter is optional, it is
strongly recommended that it always character encoding scheme can be present. This memo doesn't
define any default value for this parameter.

6.2 The version parameter

The optional parameter "version" refers
subject to the version processing rules out of JavaScript
respectively the revision scope of ECMA-262 the script is written in. This
memo doesn't define any default value for this parameter.

6.3 Encoding Considerations

For use with transports document, transport
protocols for example can require that are not 8-Bit clean, quoted-printable a specific character encoding
scheme is recommended since the majority of characters will to be
ECMAScript respectively JavaScript syntax and thus US-ASCII.

6.4 Security Considerations

Programs written in JavaScript assumed if the optional charset parameter is not
specified, or ECMAScript, just like programs
written they can require that the charset parameter is used in other languages, may contain malicious code. Since those
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.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 8] 5]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001

scripts are normally executed without further notice to the user,
care has to be taken by implementors in what those scripts are
allowed to do in February 2005

3.1 Charset Parameter

The charset parameter provides a given security context. In Web browsers, they are
executed in means to specify the security context character
encoding scheme of binary source text. Its value MUST match the page with which they were
downloaded, and they have restricted access to other resources within
the browser. Early
mime-charset production defined in [RFC2278], section 3.3. An
illegal value is a value that does not match that production.

3.2 Character Encoding Scheme Detection

It is possible that implementations of JavaScript had several
security flaws. The book "JavaScript - The Definitive Guide"
published cannot interoperably determine a
single character encoding scheme simply by O'Reilly and Associates [JSGUIDE] says in chapter 1.5
(quoted complying with permission):

"In Navigator 2, for example, it was possible to write JavaScript
code that could automatically steal the email address all
requirements of any
visitor to the page containing applicable specifications. To foster
interoperability in such cases, the code. More worrisome was 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
related capability to send email in value
determines the visitor's name, without character encoding scheme.

2. If the visitor's knowledge or approval. This was done by defining an
HTML form, binary source text starts with a mailto: URL as its ACTION attribute and using
POST as the submission method. With this Unicode encoding form defined, JavaScript
code could then call
signature, the form object's submit() method when signature determines the
page containing encoding. The following
octet sequences at the form was first loaded. This automatically
generated mail in very beginning of the visitor's name to any desired address. binary source text
are considered with their corresponding character encoding
schemes:

The
mail contained longest matching octet sequence determines the visitor's email address, which could be stolen
for encoding.
Implementations of this step MUST use in Internet marketing, for example. Furthermore, by
setting appropriate values within these octet sequences to
determine the character encoding scheme even if the form, determined
scheme is not supported. If this malicious
JavaScript code could send a message in step determines the user's name to any
email address."

CERT Advisory CA-1997-20 [CA-1997-20] gives information on further
security flaws in those early implementations:

"The CERT Coordination Center has received reports of a
vulnerability in JavaScript that enables remote attackers character
encoding scheme, the octet sequence representing the Unicode
encoding form signature MUST be ignored when decoding the binary
source text to
monitor a user's Web activities. The vulnerability affects
several Web browsers that support JavaScript. source text.

3. The vulnerability can be exploited even if character encoding scheme is determined as UTF-8.

If the browser character encoding scheme is behind a
firewall determined as UTF-8 through any
means but step 2 as defined above and even when users browse "secure" HTTPS-based
documents."

Fortunately, most known security issues within common implementations
have been fixed in recent versions.

However, these scripting languages are commonly used to manipulate
the document object model of given documents, thus they can be used
to hide information otherwise visible, for example by removing
elements from the document tree. This feature also enables scripts
to initiate transfers of arbitrary network resources, e.g. by
setting binary source text starts
with the 'src' attribute of octet sequence EF BB BF, the HTML element 'img' to a new URI.
Security considerations on these resources are subject to individual octet sequence is ignored when

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 9] 6]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001

registered types. This also enables scripts February 2005

decoding the binary source text to transfer information
on e.g. source text. (The sequence will
also be ignored if step 2 determines the browser or character encoding scheme
per the computing environment back to requirements in step 2).

Implementations of the server.
Consider a browser providing access to information on types text/javascript, text/ecmascript, and
application/javascript SHOULD and implementations of the browser
itself, type
application/ecmascript MUST implement the operating system, screen resolution, installed software,
etc. These information could be transferred to requirements defined in
this section in the server by
appending a string to cited case.

3.3 Character Encoding Scheme Error Handling

The following error processing behavior is RECOMMENDED for the new URI, e.g.
http://host/?os=Win95&browser=IE5. This affects users privacy media
types text/javascript, text/ecmascript, and
could be used to exploit vulnerabilities.

6.5 Interoperability Considerations

JavaScript is used on million of web sites today application/javascript,
and REQUIRED for the scripts are
running on different computer platforms and web browsers at least
most of media type application/ecmascript.

o If the time. The standardized sibling value of JavaScript,
ECMAScript, a charset parameter is meant to further improve interoperability and recently
deployed illegal, implementations claim to be conforming to [ECMA-262] .
Additionally,
MAY recover from the World Wide Web Consortium (http://www.w3.org)
standardized error by ignoring the Document Object Model (http://www.w3.org/DOM/) used
in various web browsers and recently deployed web browsers claim to
adhere to some Level of parameter or MAY
consider the Document Object Model.

6.6 Published JavaScript specifications

As of time of publication of this document, character encoding scheme unsupported.

o If binary source text is determined to be encoded using a certain
character encoding scheme the latest JavaScript
version implementation is 1.4, as formally specified in unable to process,
implementations MUST consider the Core JavaScript
Reference [JS14] .

6.7 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 be encoded using a certain
character encoding scheme but contain octet sequences that are not
legal according to that scheme. This is typically caused by lack
of proper character encoding scheme information; such errros can
pose a security risk as discussed in section 4.

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 to specify 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.

Hoehrmann Expires August 9, 2005 [Page 7]
Internet-Draft Scripting Media Types February 2005

4. Security Considerations

Refer to [RFC3552] for a discussion of terminology in this section.
Examples in this section, discussions of interactions of host
environments with scripts and extensions to [ECMA] are to be
understood as non-exhaustive and of purely illustrative nature.

The programming language defined in [ECMA] is not intended to be
computationally self-sufficient, it is rather expected that the
computational environment provides facilities to programs to enable
specific functionality. Such facilities constitute unknown factors
and are thus considered out of 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 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.

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.

Scripts embedded in application/xhtml+xml [RFC3236] documents for
example 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.

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

Hoehrmann Expires August 9, 2005 [Page 8]
Internet-Draft Scripting Media Types February 2005

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.

A host environment can provide facilities to access external input,
scripts that pass such input to the eval() function can be vulnerable
to code injection attacks; scripts must 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 see 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 which could be
executed in an otherwise trusted environment; this threat scenario is
subject to security considerations out of 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. The 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 scope of this document.

Hoehrmann Expires August 9, 2005 [Page 9]
Internet-Draft Scripting Media Types February 2005

5. IANA Considerations

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

6. JavaScript Media Types

6.1 text/javascript

Type name: text
Subtype name: javascript
Required parameters: none
Optional parameters: charset, see section 3.1.
Encoding considerations:
The same as the considerations in section 3.1 of [RFC3023].

Security considerations: See section 4.
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 IETF.

Hoehrmann Expires August 9, 2005 [Page 10]
Internet-Draft Scripting Media Types February 2005

6.2 application/javascript

Type name: application
Subtype name: javascript
Required parameters: none
Optional parameters: charset, see section 3.1.
Encoding considerations:
The same as the considerations in section 3.2 of [RFC3023].

Security considerations: See section 4.
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 IETF.

Hoehrmann Expires August 9, 2005 [Page 11]
Internet-Draft Scripting Media Types February 2005

7. ECMAScript Specifications Media Types

7.1 text/ecmascript

Type name: text
Subtype name: ecmascript
Required parameters: none
Optional parameters: charset, see section 3.1.
Encoding considerations:
The same as the considerations in section 3.1 of [RFC3023].

Security considerations: See section 4.
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 latest specification for ECMAScript IETF.

Hoehrmann Expires August 9, 2005 [Page 12]
Internet-Draft Scripting Media Types February 2005

7.2 application/ecmascript

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

An additional "version" parameter is ECMA-262, revision 3
[ECMA-262] published by the European Computer Manufacturers
Association reserved in December 1999. section 1.3;
implementations MUST support this parameter even though this
document does not define legal use for it.

Encoding considerations:
The former revision 2 has been adopted
by ISO same as ISO/IEC 16262:1998 [ISO16262] in April 1998.

6.8 Accessibility Considerations

Authors using scripts in combination with (X)HTML documents are
encouraged to follow the checkpoints and using the techniques
summarized considerations in the W3C Note "HTML Techniques for Web Content
Accessibility Guidelines 1.0" [WCAGTECHS] section 12 to insure proper
accessibility 3.2 of their web pages.

7. Notes on Microsoft's JScript language

This memo does not attempt to register a Media Type for Microsoft's
ECMA-262 implementation called "JScript". JScript is not commonly
identified by any MIME type, Microsoft rather uses a "language"
attribute [RFC3023].

Security considerations: See section 4.
Interoperability considerations:
None except as noted in host documents like the language attribute other sections of the 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 IETF.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 10] 13]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001

"script" element in HTML. Microsoft claims that JScript is with only
a few minor exceptions a full implementation of the ECMA-262
standard, thus scripts that don't rely on these exceptions MAY be
labeled with text/ecmascript. JScript scripts conforming to a given
level of JavaScript MAY be labeled as text/javascript or
application/javascript. For more information on Microsoft JScript,
refer to <http://msdn.microsoft.com/scripting/>. February 2005

8. Acknowledgments

Thanks to Marshall T. Rose for providing RFC 2629 and the xml2rfc
tool used to generate this memo. References

[CA-1997-20] CERT Coordination Center, "CERT Advisory CA-1997-20 -
"JavaScript Vulnerability"", July 1997,
<http://www.cert.org/advisories/CA-1997-20.html>.

[ECMA-262]

8.1 Normative References

[ECMA] European Computer Manufacturers Association, "ECMAScript
Language Specification 3rd Edition", December 1999, <http://www.ecma.ch/ecma1/stand/ecma-
262.htm>.

[ISO16262] International Organization for Standardization,
"ECMAScript language specification", April 1998,
<http://www.iso.ch/cate/d29696.html>.

[JS14] Netscape Communications Corporation, "JavaScript 1.4
Core Reference Manual", October 1998,
<http://developer.netscape.com/docs/manuals/js/core/
jsref14/contents.htm>.

[JSGUIDE] Flanagan, D., "JavaScript: The Definitive Guide, 3rd
Edition", ISBN 1-56592-392-8, Published by O'Reilly &
Associates, June 1998,
<http://www.oreilly.com/catalog/jscript3/>.
<http://www.ecma.ch/ecma1/stand/ecma-262.htm>.

[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.ietf.org/rfc/rfc2119.txt>.

[SVG10] Ferraiolo, J., "Scalable Vector Graphics (SVG) 1.0
Specification", September 1997.

[RFC2278] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2278, January 1998.

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

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

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.

8.2 Informative References

[E4X] European Computer Manufacturers Association, "ECMAScript
for XML (E4X)", June 2004,
<http://www.ecma.ch/ecma1/stand/ecma-357.htm>.

[EcmaCompact]
European Computer Manufacturers Association, "ECMAScript
3rd Edition Compact Profile", June 2001,
<http://www.w3.org/TR/2001/REC-SVG-20010904/>.
<http://www.ecma.ch/ecma1/stand/ecma-327.htm>.

[JS15] Netscape Communications Corp., "Core JavaScript Reference
1.5", September 2000,
<http://web.archive.org/*/http://devedge.netscape.com/libr
ary/manuals/2000/javascript/1.5/reference/>.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 11] 14]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001

[WCAGTECHS] Chisholm, W., Vanderheiden, G. and I. Jacobs, "HTML
Techniques for Web Content Accessibility Guidelines
1.0", November 2000, <http://www.w3.org/TR/WCAG10-HTML-
TECHS/>. February 2005

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

Author's Address

Bjoern Hoehrmann
am Bededeich 7
D-25899 Dagebuell
Weinheimer Strasse 22
D-68309 Mannheim
Germany

Phone: tel:+49-4667-981028
EMail: bjoern@hoehrmann.de

Email: mailto:bjoern@hoehrmann.de
URI: http://bjoern.hoehrmann.de

NOTE:

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.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 12] 15]
Internet-Draft JavaScript and ECMAScript Scripting Media Types September 2001

Intellectual Property Statement

This document and translations IETF takes no position regarding the validity or scope of it may any
Intellectual Property Rights or other rights that might be copied and furnished claimed to
others, and derivative works that comment on or otherwise explain it
or assist in its
pertain to the implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction use of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, technology described in
this document itself may or the extent to which any license under such rights
might or might not be modified in available; nor does it represent that it has
made any independent effort to identify any way, such as by removing rights. Information
on the copyright notice or references procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
assurances of licenses to be made available, or other
Internet organizations, except as needed for the purpose result of
developing Internet standards in which case the procedures an
attempt made to obtain a general license or permission for
copyrights defined in the Internet Standards process must be
followed, use of
such proprietary rights by implementers or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not users of this
specification can be
revoked by obtained from the Internet Society or IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its successors attention any
copyrights, patents or assigns. 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.

Disclaimer of Validity

This document and the information contained herein is 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 DISCLAIMS 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.

Acknowledgement

Copyright (C) The Internet Society (2005). 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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Hoehrmann Expires March 22, 2002 August 9, 2005 [Page 13] 16]
----