Ned, perhaps you could comment on whether you feel text/rtf and
text/vnd.in3d.3dml are (1) actual valid registered subtypes of "text"
Well, I'm not Ned, but I have an opinion.
Is it possible to write rtf that can be read by ordinary humans without
harm? Then text/rtf is ok. It does NOT follow that all rtf should go as
text/rtf; "hairy" rtf should probably go as application/rtf or something.
I doubt there's a chance in hell of that happening, though.
I believe one problem is that there is no clear way to get character sets
and newline canonicalization for types other than text/*. So people tend
to try to put things under text in order to get these semantics. I've
argued in the past for specific parameters for text-y things, and been told
that was wrong. Instead, people are supposed to note in their
registrations of non-text types if they want any text-y semantics. I think
this is not widely understood. Whether my parameter would be convenient
enough for people to specify that they wouldn't try to "cheat" by using
text/* is debatable, of course.
Anyway, I think it was probably an error to register those types under
text. Doesn't mean we should throw out the rule, just means we should
unregister the types (which I believe is procedurally difficult, but...).
The actual semantics in
use, however, seems to be that any data which is represented in a
textual format, regardless of whether that representation was meant for
humans or machines, is a subtype of "text".
There are also textual representations registered under other top-level
types (eg, application/mac-binhex40). So some people got it right. Maybe
it can be fixed. Or maybe it's as useless as the number after
Mime-Version...