* 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@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/

On Wednesday, February 9, 2005, 2:08:27 PM, Bjoern wrote: BH> * 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.

BH> That's probably true, but the alternative would be to continue using the BH> unregistered types for several years as the application/* types are much BH> less well-supported. For example, all SVG implementations I am aware of BH> that support relevant scripting,support text/ecmascript (as the relevant BH> specifications suggest) Yes BH> while none support application/ecmascript. because the spec doesn't say to. However, if the preferred and registered media type was application/ecmascript, then the SVG spec could require support for this type.

...

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"

BH> Could you elaborate on this point? I am not quite sure how the draft BH> suggests that these types are registered, in fact, it says that they BH> are not. Maybe you can make a suggestion to rephrase the passages you BH> had in mind? Yes, it doesn't say they are registered. It says which ones are in active use currently.

...

Fourth, I see no compelling reason to register both "javascript" and "ecmascript" variants;

I do - they are related but different languages. One is defined by an international standards group and one ( a superset) by browser vendor. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group

* Bruce Lilly wrote:

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.

I would like to hear what other ietf-types participants think about this. I do not think there is real consensus in the IETF on how to do versioning on the media type level, as the draft notes, implementers have attempted to deal with this by appending version numbers to the subtype name as in text/javascript1.1, some types use parameters to indicate the "version" (or codec, etc) and other types, as you point out, did not really consider this issue, for example, for the XML media types it is not clear whether those can be used for XML 1.1, RFC 3023 only refers to XML 1.0. An update to RFC 3023 might allow using e.g. application/xml for XML 1.1 but that would yield in a situation similar to that of the media type for PowerPoint content. I do not know how the formats relevant to the draft evolve, so I do not know at the moment whether updating the document to consider new formats at a later point is the best way forward, or whether such a new format should use a new media type. In response to the first draft in 2001, ECMA TC 39 (the technical committee responsible for the ECMAScript specification) suggested a application/ecmascript4 media type for ECMA-262 Edition 4; my understanding is that Edition 4 is still not final so it lacks a public specification and such a media type can thus not be registered in the standards tree at the moment. I do not want to ignore this issue, hence the reserved version para- meter. It's not meant to be an optional parameter, it is rather meant as an anchor for error handling requirements, implementations unaware of the parameter must not consider content that uses the parameter supported. This would enable use of the media type for content that would not interoperate with older implementations that do not support the new format. There seem to be two alternate approaches to the problem, either require implementations to consider all parameters (but charset) as indicating unsupported content or list the parameter as optional parameter; the former would hinder introduction of other parameters with different semantics and implementations to implement common error recovery behavior (i.e., ignore unknown parameters). The latter does not make significantly more sense to me than the current approach; as I do not know how the formats evolve, it would be difficult to specify the lexical space of the parameter value; I could say it must be empty or can be anything that is allowed for parameter values, and regardless of the value, the content must be considered unsupported. I anticipate objections to that approach. If I specify something else, it could conflict with yet unknown versioning policies of the format specifications. OTOH, updates of the document could change the lexical space of the parameter value... At least in the context of HTTP, use of such parameters where media types provide them is not common in my experience, using them would typically require access to the server configuration and users that know about the parameters and how to configure the server accordingly; RFC 2854 notes that this did not work in practise. The situation might be different when this would be relevant for the proposed types, but that seems unlikely... Could you make a suggestion for the draft that would address your concern? Would it be sufficient to refer to the version parameter as optional parameter with an unconstrained lexical space for its value and with the semantics that implementations must consider any use of the parameter to indicate that the content is unsupported? -- Björn Höhrmann · mailto:bjoern@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/

On Thu February 10 2005 15:31, Larry Masinter wrote:

My opinion is that content negotiation for versioning capability using MIME type parameters is unworkable.

Negotiation isn't always possible; sometimes it's a one-way street.

The use of the MIME type is to describe the payload sufficiently so that you know HOW to process it, but the content-type label cannot (and thus should not) be extended in an attempt to use it to determine WHETHER a given processor knows enough to be able to process it.

We're in agreement that the media type/subtype tag should not be used for versioning (that would result in an unnecessary proliferation of tags).

So whether version information should or should not be in a media type parameter depends pretty much on whether there is an embedded, easy-to-find version indicator in the data itself; if there isn't, and processors need to know the version to choose between different processing methods, then the version parameter should be mandatory. There is no strong use case for an optional version parameter, or in general for duplicating, in MIME parameters, information that is readily obtained from the content itself.

Maybe; if transfer encoding is applied, that would entail decoding and opening the media content to determine version information. If the media type is specified via message/external-body or a similar mechanism, additional steps are necessary to obtain the media in order to determine version information. If a particular instance of content is large, that may result in a substantial waste of resources if it turns out to have an incompatible version.

If you want to do content negotiation, then consider using media features and media feature negotiation; with media features you can negotiate not only version information, but other parameters that might also be necessary to know in order to determine interpretability, e.g., availability of compression modes, codecs, fonts, color capabilities, buffer size limitations, etc.

That's fine for protocols that support negotiation, but not all protocols do so (HTTP does, RFC 3297 layered on top of messaging can, but FTP does not). Summary: o media content might contain version information, but reliance on that can result in wasted resources o negotiation via content-features may be a viable mechanism where negotiation is possible, but it is not always possible (and some means of indicating version must be available to the content negotiation mechanism) o proliferation of type/subtypes tags for the sole purpose of versioning is undesirable that leaves parameters associated with the media type as an efficient mechanism for indicating version information.

Re declarative rather than negotiation situations: You could still use RFC 2912 "content-features" to indicate information other than what is in the baseline. The idea is that rather than loading up content-type with information that is unnecessary for the purpose of content-type, add it to a separate expression which can contain not only version information, but other resource constraints. I don't think anyone's defined a 'version' feature, but that would be a good thing to work out and add to http://www.iana.org/assignments/media-feature-tags Larry

* Bruce Lilly wrote:

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

Would such a statement address your concerns in this regard, or do you mean wording such as "support" as you've mentioned, "the media type application/ecmascript", etc. should still be replaced even if I adopt this proposal?

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.

But why does that require the reference to be normative rather than informative?

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.

True, but then it makes little sense for the other cited RFCs to refer to the IETF as change controller; I will seek the IESG's advice on this matter, I don't have strong feelings either way as long as new RFCs may update the registration. -- Björn Höhrmann · mailto:bjoern@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/

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

First, the criteria is "meaningful to present directly to a human", not "is composed of natural language text". Second, some of these registrations are widely thought to be mistakes - they never should have been registered under text. As such, they don't justify additional, similar registrations.

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.

The fact that these subtypes of text are in widespread use leads me to suggest an alternate approach: Why not register them, but mark them as obsolete with a pointer to the type that should be used instead? The registration will then serve two purposes: To make it clear what the types contain when they are used and to also make it clear they should no longer be used.

Thus, without arguing about whether text/* is the best place for these types (and the draft admits that it is probably not),

Hinting isn't sufficient IMO. We're trying to provide usage guidance here, so the problematic nature of calling this sort of material text should discussed. Ned

* ned.freed@mrochek.com wrote:

...

The fact that these subtypes of text are in widespread use leads me to suggest an alternate approach: Why not register them, but mark them as obsolete with a pointer to the type that should be used instead? The registration will then serve two purposes: To make it clear what the types contain when they are used and to also make it clear they should no longer be used.

The draft states that text/ecmascript is expected to be deprecated in a future version of the document.

There is no defined process for deprecation of a media type. The closest thing we have is marking the type as being obsolete, and the media types registration procedure specifically calls for this to be done "when use of the type is no longer appropriate". This IMO matches the present case exactly.

This basically means text/ecmascript should not be used in a context where application/ecmascript could be used as well. Marking text/ecmascript as obsolete does not allow making such a distinction as far as I can tell,

Actually, it makes exactly this distinction, one that deprecation does not make.

and I think the registration should acknowledge that users of the types do not have much of a choice at the moment.

That's exactly what registering the types as obsolete does. Ned

On Sat February 12 2005 16:02, Bjoern Hoehrmann wrote:

Well, my concern is that it would be misleading to suggest people use application/ecmascript instead of text/ecmascript if the overwhelming majority can't do that at the moment

Why do you say that it would be misleading to suggest use of a type registered in an appropriate part of the tree rather than to use an unregistered tag which impinges on part of the IANA tree namespace which is inappropriate for the content; isn't that exactly the point of a registration -- to provide an appropriate standardized tag?

, so my preferred approach is to register these types now as COMMON (or LIMITED USE) and update the registration later to consider them OBSOLETE when support for the alternate types is more widespread.

I suspect that if an inappropriate registry is made, regardless of type, that usage patterns will change little, even if an appropriate registration is made at the same time. Once a registration is made, applications will need to support it, if only for backwards compatibility with archived content. What the is the incentive for migration to the appropriate type? There is a tendency (inertia) against change; change usually doesn't happen unless there is some sort of penalty associated with not changing; if both appropriate and inappropriate types are registered and therefore supported, where is that motivating penalty?

But I guess pointing out in the document that marking those types as obsolete does not mean there is much wrong if these types are used/implemented for reasons of backwards-compatibility would avoid confusion.

It would remove incentive to change to an appropriate tag.

Bruce, would registering these types as OBSOLETE be acceptable to you?

I'm not the arbiter of type registrations, but it seems to me that such a registration would entail unnecessary work for IANA and for implementers, would further dilute the distinction between text and other types, and would be counterproductive in terms of moving already non-conforming applications to an appropriate media type tag usage. Given those three types of harm that would likely be caused, I would only support such registration as a last resort, and I am not convinced that there is any need to resort to such a measure. What is wrong with simply registering appropriate types and encouraging implementers to migrate to those types?

On Sat February 12 2005 15:16, ned.freed@mrochek.com wrote:

...

There is no defined process for deprecation of a media type. The closest thing we have is marking the type as being obsolete, and the media types registration procedure specifically calls for this to be done "when use of the type is no longer appropriate". This IMO matches the present case exactly.

Ned, you're the expert on the registration procedure, but isn't the current discussion about a non-type whose use was never appropriate rather than a registered type whose use has become inappropriate?

Actually, there was a time when this particular registration would have sailed right on through.

I believe that's an important pair of distinctions;

I disagree. I find neither distinction to be in any way important.

we've seen in this case an argument along the lines of "well, text/blah doesn't meet the requirements for a text type but was registered as one anyway" -- I suspect that yet another inappropriate registration would make that sort of argument more likely in the future.

Ah yes, the slippery slope argument. I absolutely reject this, for two reasons: (1) Registering a type as obsolete and with a strong admonition that it not be used for anything new and for any existing use to convert to the correct type ASAP doesn't exactly create a climate that engourages inappropriate registrations. If anything, it does the exact opposite by making it clear that the text top level type shouldn't be abused in this way. There's a lot to be said for examples, even (or especially) negative ones. (2) Been there, done that. The reason media type usage got to be such a mess is because the initial go at registration procedures was overly restrictive. This led to everyone just using all sorts of types willy-nilly. I hasten to add that this is not anyone's fault - at the time the registry was first designed we really had no idea how things would play out, and the concern that led to the ovverly restrictive design was reasonable. But now we know better, and we know that registering things both good and bad is a much more effetive way of dealing with them than pushing them away in hopes they'll vanish. Ned

On Sat February 12 2005 12:45, ned.freed@mrochek.com wrote:

...

The fact that these subtypes of text are in widespread use leads me to suggest an alternate approach: Why not register them, but mark them as obsolete with a pointer to the type that should be used instead? The registration will then serve two purposes: To make it clear what the types contain when they are used and to also make it clear they should no longer be used.

If one looks at the IANA-maintained registry (http://www.iana.org/assignments/media-types/text/ for the text types) one sees only a list of subtype tag names with references to documents. It's not clear, therefore, how one would go about marking a subtype as obsolete in a way that would be clear and obvious to implementers.

I think if someone gets as far as looking at the IANA registry they probably are going to take the next step and look at the actual registration for the type they decide on. But even if this isn't the case, this is simply a matter of presenting the information differently.

Nor is it clear how one would provide a pointer to a different type in a way that would be clear etc. to implementers.

There are any number of places in the registration where it could go. Finally, it should be noted that content may be

archived for a considerable time; how is one to determine whether or not a type specified in an archived document was valid at the time that content was created; I see no mechanism for provision of a timestamp on changes in status of a type or subtype registration?

This begs the question of whether or not it is actually useful to be able to make such determinations. I don't think it is.

...

Hinting isn't sufficient IMO. We're trying to provide usage guidance here, so the problematic nature of calling this sort of material text should discussed.

Right. And I'm not sure how something as much as mere hinting can be achieved w.r.t. "obsolete" types with the current registry (lack of) structure [compared, e.g. to the structure of the charset registry]. Much less something that provides clear guidance regarding usage.

The alternative, however, is to say nothing. And we have ample experience with this approach and know where it leads: People will continue to use the unregistered types.

About the only thing an implementer can do for non-private-use tags without extensive manual effort for each type and subtype is to determine whether something which appears where a media type is supposed to appear is in fact a registered type -- that's the case because that's all that can be mechanically determined from the registry. Thus a validating parser of Content-Type fields (for example) can easily indicate that a type is registered -- a table of registered types can be consulted (though such a table can get out-of-date quickly) -- but it's much more difficult to be able to indicate nuances such as whether/when a type has become obsolete, what other types are related and in what ways, etc.

This is true only in theory. What happens in practice is that lack of registration is absolutely no impediment to continued, and even increased, use of the types. We have little if any experience with whether or not marking something obsolete will help get it out of circulation. But I have seen cases where spelling out security considerations has led to folks reconsidering the use of some media types. So there is some hope. But without a registration, there is none. Ned

On Sat February 12 2005 16:43, ned.freed@mrochek.com wrote:

...

I think if someone gets as far as looking at the IANA registry they probably are going to take the next step and look at the actual registration for the type they decide on.

One might do that for a specific type of interest on some sort of regular basis. One might do so for the entire tree, one time, to set up a table, then add types and subtypes as they are added to the registries. But I do not think it is reasonable to expect that implementers will sift through the entire tree of registrations regularly in order to catch any change in registration status.

...

...

...

Hinting isn't sufficient IMO. We're trying to provide usage guidance here, so the problematic nature of calling this sort of material text should discussed.

...

Right. And I'm not sure how something as much as mere hinting can be achieved w.r.t. "obsolete" types with the current registry (lack of) structure [compared, e.g. to the structure of the charset registry]. Much less something that provides clear guidance regarding usage.

The alternative, however, is to say nothing.

I'm not convinced that that's the only alternative.

I was talking about what to do with the text/* types we're discussing. And its a binary choice: Either we register them or we don't. Given that

there is work under way to improve the charset registry, it seems feasible in principle to do something similar for the type and subtype registries.

I certainly have no objection to improving the format of the registry. But I don't think registering obsolete types should be contingent on that happening.

...

And we have ample experience with this approach and know where it leads: People will continue to use the unregistered types.

I believe that given a registration in an appropriate part of the tree, use will migrate in that direction. Those who make the migration will benefit from improved prospects for interoperability. Those who do not will be where they are now, i.e. operating in uncharted waters.

Well, all I can say is that I disagree. I don't think a registration of the right thing is nearly as powerful as registering the right and warning against the wrong. And past experience in this exact space tends to support my position, not yours. Ned

On Sat February 12 2005 22:09, ned.freed@mrochek.com wrote:

...

...

...

The alternative, however, is to say nothing.

...

I'm not convinced that that's the only alternative.

I was talking about what to do with the text/* types we're discussing. And its a binary choice: Either we register them or we don't.

Registration is a binary choice, but that does not preclude mentioning inappropriate use of unregistered type names in an RFC which also registers appropriate types.

...

Well, all I can say is that I disagree. I don't think a registration of the right thing is nearly as powerful as registering the right and warning against the wrong.

I have no qualms about either "registering the right" or "warning against the wrong". Registering the wrong is another matter.

You have previously claimed that people will only look at the list of registrations and not bother to look at the actual registrations. By this logic a discussion of unregistered types buried in the text for some other type isn't going to be seen. You can't have it both ways. And please don't bother claiming that the lack of a registration for these text types will serve as a warning not to use them - everything we know about media type registrations says otherwise. Ned

On Sun February 13 2005 14:10, ned.freed@mrochek.com wrote:

...

You have previously claimed that people will only look at the list of registrations and not bother to look at the actual registrations. By this logic a discussion of unregistered types buried in the text for some other type isn't going to be seen.

Yes.

...

You can't have it both ways. And please don't bother claiming that the lack of a registration for these text types will serve as a warning not to use them

By itself, it won't serve as a warning. The problem is that there is no visible, clear place to provide a warning.

Then let's fix that problem independently of doing the right thing for these media types.

If somebody (typically a developer) is looking for an appropriate type and sees application/ecmascript and application/javascript, he is likely to use one of those. If text/javascript etc. are also registered and he sees one of those first, that's what he's likely to use. The latter is what we would like to avoid.

I still don't buy the argument, but even if I did the right thing to do is to address the clarity problem, not fall down in providing useful advice. Ned