If you want to send RTF that is not meant for interpreted display (in
order to get the new-line cononicalization and charset definition), why
not use text/rtf with "Content-Disposition: attachment"?
- dan
-----Original Message-----
From: Steve Dorner
Sent: Wednesday, March 11, 1998 1:17 PM
To: ietf-822(_at_)imc(_dot_)org
Subject: Re: overdefining text/plain?
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...