
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