Scripting Media Types

[Bruce Lilly]

On Tue February 8 2005 22:08, Bjoern Hoehrmann wrote:
> * 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).

One cannot meaningfully speak of "support" in MIME terms for something
which is neither a registered MIME type nor in the category of types
and subtypes reserved for experimental and private-agreement use (i.e.
beginning with "x-").  Any treatment of unrecognized (i.e. unregistered,
or registered after an application's support was coded, or unrecognized
private-use) types or subtypes MUST be as documented in RFCs 2046 and 2049
for any MIME-compliant application.  In most cases, that means treating
such types as an opaque blob, i.e. as application/octet-stream.

Any application doing otherwise with unregistered type such as the ones
mentioned in your draft is clearly not MIME-compliant (a.k.a. "broken").
And that is independent of the number of instances of that non-compliant
application in the wild, or the number of inappropriately-labeled
files that those applications produce.

In short, there is a principle at work, and that principle is that text
is for humans, and is in a natural language (see RFC 2277, a.k.a. BCP
18).

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

First, we're discussing a specific proposal (yours); any errors (or
lack thereof) in other registrations or proposals are a separate matter.

Second, text/sgml (for example) is perfectly valid; the type refers
to textual, natural language content (with associated markup); the
media type can be presented to a user such that a user can make some
sense of the natural language content by ignoring the markup, or
markup can be applied by rendering the content for the user.  That
of course also applies to application profiles of SGML (e.g. HTML and
XML).  That does not, however, mean that any arbitrary content using
XML markup is suitable as a text subtype; see RFC 2046 sections 1 and 4.

> There are even people who would prefer to just stick with the most
> commonly used types (which would be text/javascript, etc)

Again, "commonly-used" makes little sense in terms of compliant
applications and compliance requirements, and I do not think it is
advisable to cater to broken applications by inappropriately
registering types under the text category which are not in fact
suitable text types.  The developers of the broken applications
should fix their products.

A primary goal of standardization is interoperability; developers
who do not bother to conform to registration procedures and
compliance requirements produce inherently non-interoperable products.
Registering media types inappropriately to cater to such developers
impairs interoperability by muddling the clear distinction between
media type categories; it drives the level of the whole down to
that of the (inherently non-interoperable) lowest level.

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

"the media type application/ecmascript" etc. clearly implies that
there is a registered media type of that name; there is not.

> in fact, it says that they 
> are not. Maybe you can make a suggestion to rephrase the passages you
> had in mind?

You might say something like "there exist some non-MIME-compliant
applications that generate unregistered, non-private-use labels
such as 'text/javascript'  ...  such use is clearly not interoperable".

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

Then that's a good indication that that reference should be normative
(w.r.t. to another question below), since in order to determine
which features are (in)compatible, one must consult that reference.

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

There are no "reserved parameters"; there are required parameters and
optional parameters.  If you believe that version information may be
useful in one or more of the types that you seek to register, you
might define an optional version parameter (and specify how content
is to be handled when lacking that parameter), or if it is critical
to interoperability, make the parameter mandatory.  Past experience
has shown that ignoring (or skirting) the issue is likely to lead
to interoperability problems.  Consider application/vnd/ms-powerpoint,
which lacks any provision for version indication.  It is well-known
that some versions of MS "PowerPoint" are unable to read the
incompatible and proprietary formats generated by other versions of
that application.  Five years from now, do you want people to make
the same sort of statement about application/ecmascript etc.?

Given that there is a "JavaScript 1.5", there presumably were and
will be other versions.
 
> >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?

A scripting or programming language implies an interpreter or
compiler.  Implementers need a specification in order to
implement interpreters and/or compilers (validating parsers,
etc.).  Now in some cases, a specification is not publicly
available (e.g. for proprietary formats such as application/msword),
but that doesn't appear to apply in this case.
 
> >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?

I believe the registration procedure notes that IESG (not IETF) may
assign change control under some circumstances.  Also, IETF is a
large, vaguely-defined body consisting of many individuals, numerous
working groups, etc.  The IESG, on the other hand, is a clearly-defined
group which makes decisions based on parliamentary procedures, directs
IANA and the RFC Editor, etc., with a public record of their meetings
and decisions. See RFCs 3160, 2026, 2418.