Scripting Media Types

[ned.freed at mrochek.com]

> On Sat February 12 2005 12:45, ned.freed at 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