At 1998-11-02 08:54, Laurence Lundblade wrote:
To me the top level types are very rough groupings based on some common
default treatment we want applied to them. For example multipart/xxx
defaults to multipart/mixed, a rule that's widely implemented correctly.
Text/xxx was supposed to default to text/plain, but since the registration
of text/html (very unreadable to humans) most MUAs have stopped display
text/xxxx by default.
I disagree with you about the readability of text/html: I'd far rather
see a message in raw HTML than not see it all. I think that's the idea
behind text/*.
Now with the rise of HTTP browsers that can read HTML, but mail UAs that
cannot, the question 'can you interpret HTML' no longer has a trivial
answer, and saving HTML to a file (where it can be read by a browser)
becomes a reasonable action for a mail UA.
But I doubt it would make much difference. Much as we all might
disapprove, I'm sure Netscape et al. would still allow users to generate
HTML in mail messages no matter what its top-level type is.
I guess for text/* the rules these days amount to this:
1) Does it look OK when splatted directly to the screen of a VT100
2) Are you willing to let it occasionally be treated like an attachment by
mal-conforming MUAs.
and
3) If you don't like 2 and want to use a parameter, can you convince the
standards folks that your type is OK to be identified just by a parameter
to text/plain.
If you're willing to be liberal about 'OK' in 1, I'd agree with you. For
instance. I think the registrations of SGML and XML in both text and
application was appropriate, since some SGML/XML is sufficiently
'text-like' to be worth showing plain when there's no alternative, and
some is not.
--
Ashley Yakeley, Seattle WA