Scripting Media Types

[Bjoern Hoehrmann]

* Bruce Lilly wrote:
>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.

That's probably true, but the alternative would be to continue using the
unregistered types for several years as the application/* types are much
less well-supported. For example, all SVG implementations I am aware of
that support relevant scripting,support text/ecmascript (as the relevant
specifications suggest) while none support application/ecmascript. There
are about a million hits for type="text/*" but only a few hundred hits
for type="application/*" using Google (where * are the relevant subtypes
from the draft).

There are also several other registered media types that are not meant
to be used for natural language, for example, text/css, text/uri-list,
text/vnd.wap.wmlscript, text/sgml, and text/xml do not fit into this
category (either by their very nature as for text/css or by their use
in common practise as for text/xml, though I admit that one can greatly
argue about each type), I thus do not think that it is generally not
possible to register such types under the text top-level type. If you
consider the content to be "source code" rather than "executable code"
it is for many people in fact difficult to find much difference between
types such as text/html and text/ecmascript.

There are even people who would prefer to just stick with the most
commonly used types (which would be text/javascript, etc) simply because
that's what's implemented, what authors use, what you can find in speci-
fications, documentation, books, etc.pp.

The types are currently unregistered and pretty much undefined, the
draft defines underdefined aspects, provides security considerations
for the types, and would register those types if the draft is approved.
I think this is more valuable than to keep using the types as-is. In
particular, I think it would actually help the IANA registry to gain
relevance if it is less out of touch with reality. On several occasions
I've contacted organizations to encourage them to register the types
they use and/or define and I've generally been told that people don't
bother as the registry is of too little relevance to them. The more it
reflects reality, the more I would expect people to care, which would
encourage more review of new types which would consequently encourage
a more well-defined infrastructure.

Thus, without arguing about whether text/* is the best place for these
types (and the draft admits that it is probably not), I do not think
that this should hinder the registration of these types. If the IESG
disagrees, I might well revise the draft dropping the text/* types, but
I think a registration of these types is valuable and thus think I
should leave that decision to the IESG.

>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"

Could you elaborate on this point? I am not quite sure how the draft
suggests that these types are registered, in fact, it says that they
are not. Maybe you can make a suggestion to rephrase the passages you
had in mind?

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

See above.

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

The JavaScript Core Guide 1.5 notes "JavaScript will always include
features that are not part of the ECMA specification; JavaScript is
compatible with ECMA, while providing additional features." which is
also true for JavaScript 1.5; The specification the draft references
states which features are compatible with ECMA-262 and which aren't.
http://www.mozilla.org/js/js15.html lists some of these features. I
thus would not say that the only difference is the name. Maybe you
can propose wording for the draft to make this distinction clearer?

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

The draft notes

  This document does not define similar means for any other type as
  deployed software typically ignores unknown parameters which renders
  such a reserved parameter of little use for those types.

and notes the rationale for application/ecmascript beeing a little bit
different from the other types in section 1.2. I am not sure how this
is not sufficiently clear, maybe you can elaborate on this point? I am
happy to add additional or change existing text to make this point
clearer, but at the moment I am not sure how, so I would appreciate a
suggestion.

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

Per RFC 3160 "A normative reference is a reference to a document that
must be followed in order to implement the standard." This is true for
ECMA-262 as the draft depends on terms defined in that document, but
an implementation of the javascript media types does not depend on the
JavaScript specification (in my opinion), for example, a generic text
editor may support the application/javascript type only to the extend
of properly detecting the character encoding scheme but other than that
beeing unaware of JavaScript. So it is not obvious to me that the re-
ference should be normative, could you elaborate on why you think so?

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

RFC 3880, RFC 3910, RFC 3680, and RFC 3858, lists the IETF, and RFC
3367, RFC 3080, RFC 3288, RFC 3983, and RFC 3529 the IESG as change
controller for the types these documents register; I could not find
precise rules which I should use; I think the IESG knows best, so I
would expect them to provide clarification when reviewing the document.
Maybe I've missed a resource that provides some clarification on this
matter?

Thanks for your comments!
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/