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.