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.