27912 - MIME type for JavaScript needs to be registered

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect, P3)

Description

[Braden]

A MIME type for JavaScript needs to be registered with ICANN. These newsgroup
threads can provide some background:

  <URL:news://news.mozilla.org/383D6D48.1D6A7BB7%40endoframe.com>
  <URL:news://news.mozilla.org/38A88957.6070B585%40netscape.com>

I think the current best bet is "application/vnd.moz.javascript" (in accordance
with Erik van der Poel's suggestion for the XUL type).

Comment 1

[cbegle]

updating component so that the javascript guys can think about what the right 
thing to do is and cc'ing erik.

Comment 2

[Mike McCabe]

Reassigning to 'javascript' to see what happens.

Comment 3

[Braden]

mccabe: Does the reassignment mean you're in a position to provide authoritative
answers to some of the questions on the registration form (for example, security
and encoding isses)?

Answering these questions to get the registration application in a submitable
state is the primary roadblock here.

Also of importance is the name of the subtree under the "vendor" subtree. I
don't have strong feelings on this issue beyond my general agreement with David
Matiskella that having such a subtree is appropriate. Shall we forge ahead with
"moz", as suggested by Erik van der Poel? Should this particular issue be raised
on its own in some forum?

Comment 4

[ekrock's old account (dead)]

Marking Future and helpwanted and reassigning to [e-mail] for now. 
Braden's correct that the MIME type for JS needs to be registered. However, that 
can be done after FCS with no harm. (The MIME type for JS definitely won't 
change, given the fact that it's already in use worldwide, so this is just a 
question of taking care of the registration paperwork if I'm not mistaken.) 
Between now and FCS, it's crucial that Netscape staff focus their work on 
bugfixing, etc., that *has* to be done before FCS, otherwise the quality of the 
first release will be jeopardized. However, this doesn't stop independent 
contributors from taking responsibility for this bug, reassigning it to 
themselves, and moving forward if they wish. Braden, if you're interested, I'd 
encourage you to go for it!

Comment 5

[Braden]

Actually, Eric, it's reasonably likely that a registered type for
JavaScript/ECMAScript would be different from anything Mozilla currently
recognizes. "application/x-javascript" is not an option for registration because
it's in the experimental namespace. "text/javascript" is a possibility, but I've
also seen "text/ecmascript" in an ECMA document--which might the IETF prefer? I
don't know, but a further kink is that existing RFCs suggest "application" is
the appropriate primary type for a scripting language. So,
"application/ecmascript"?

Maybe, but who knows? In any event, registering types in the IETF namespace is
not the province of mozilla.org. I nolonger think it's wise to register a type
in the vendor namespace for JavaScript. Though, obviously, when/if a type for
[ECMA|Java]Script is registered in the IETF namespace, Mozilla ought to support
it. That will be a different bug, though.

Since I think I was the only champion of a vendor type, resolving WONTFIX.

Comment 6

[Chris Hubick]

I don't know if this is the right place to bring this up... :-)

I can't believe there isn't a standardized method for invoking ECMA Scripts!  I 
think it would be nice for someone from Netscape/Mozilla to get the ball 
rolling on this, as I can't think of who else is going to, or be more capable 
of, doing it.

The first problem, what media type...

It seems obvious to me from http://www.ietf.org/rfc/rfc2046.txt that 
the /technically correct/ one would be "application/ecmascript", with an 
optional "version" parameter.

I certainly don't think it should be "text" rather than "application"...

From RFC 2046:

Section 3:
---
   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  
---

Section 4.5. - Application Media Type
---
   The "application" media type is to be used for discrete data which do
   not fit in any of the other categories, and particularly for data to
   be processed by some type of application program.  This is
   information which must be processed by an application before it is
   viewable or usable by a user.  Expected uses for the "application"
   media type include file transfer, spreadsheets, data for mail-based
   scheduling systems, and languages for "active" (computational)
   material.  (The latter, in particular, can pose security problems
   which must be understood by implementors, and are considered in
   detail in the discussion of the "application/PostScript" media type.)

[snip...]

   More generally, there have been several "active" messaging
   languages developed in which programs in a suitably specialized
   language are transported to a remote location and automatically run
   in the recipient's environment.

   Such applications may be defined as subtypes of the "application"
   media type.

---

We can already get scripts running on a platform/browser specific basis (using 
language="javascript1.2" or whatever), so a vendor specific "moz*" 
or "javascript" type does nothing to promote what is really needed, which is 
cross-vendor/browser/impl interoperability.  This is also why I don't really 
care about "javascript" at all, compared to "ecmascript".

The second question "language" vs. "type" attribute, which recently went 
basically unanswered in jseng is a non-question.  The HTML DTD answers that, in 
that I can't validate my page without using "type".

Now, I would really like to see the media type registered, but independant of 
that, can we at least /start/ getting 
type="application/ecmascript" /implemented/ in a few places?  Implementation 
drives standardization.

Thanks.

Comment 7

[Braden]

In this case, RFCs drive standardization. Unless the ECMAScript standardization
effort can produce someone with the time and experience to write one for
application/ecmascript, writing code that depends on that type would just
confuse the issue further. If a Mozilla contributor is interested in pursuing
this, perhaps an ECMA-involved person at Netscape could put them in touch with
the correct channels.