Scripting Media Types

[Bruce Lilly]

There are a few issues:

First, the proposed text subtypes are inappropriate; text subtypes
are reserved for human-readable text content, with or without
markup; see RFC 2046 section 4.  They are not to be used for
arbitrary content which happens to be textual, such as programming
and scripting languages; they are reserved for natural language.

Second, the draft mentions the proposed types as if they were
already registered, which they are not. E.g."use of and support for the
   media type application/ecmascript is considerably less widespread
   than of text/ecmascript"

Third, I see little point in registering a media type only to
subsequently deprecate its use: "It is expected that an update of this
   document will deprecate the media type text/ecmascript".  Media
may remain in archives indefinitely; if a currently-unregistered
type name is inappropriately being used, it should not be registered
and then promptly deprecated -- it should not be registered unless
there is a valid reason for registration (inappropriate use w/o
registration is not a valid reason).

Fourth, I see no compelling reason to register both "javascript"
and "ecmascript" variants; my understanding is that "ECMAscipt"
is the officially (de-jure) standardized name for the scripting
language sometimes (confusingly, because it has no relationship
to the language known as Java) referred to as "javascript".
However, if I am mistaken on that point, the distinction needs
to be made much clearer. [And I fail to see why the proposed
application/ecmascript (almost) has provision for an optional
"version" parameter, while the proposed application/javascript
has no corresponding half-provision.]

If the "javascript" variant is to be registered, its reference
should be normative rather than informative.

Change controller should be IESG, not IETF, as I understand it.