At 3:10 PM -0800 11/2/98, Ashley Yakeley wrote:
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.
Yes, it would seem the good to see the raw HTML in place of nothing, but
there are still a few problems:
Your average user will still hate it and complain to the MUA vendor. For
them it seems that the MUA is broken. I think we should be designing MUAs
for folks that are totally non-technical these days and showing HTML to
them is really quite bad. A more suitable option would be have a dialog box
explaining the situation and then offering to display the raw HTML. Or
better yet, strip the HTML down to plain text, or provide a hand-off to the
browser (easier said than done because of imbedded images and such). In
practice I think any modern MUA that doesn't at least make a modest attempt
displaying HTML is a bit out of date.
I think the user complaints and plain ugliness of HTML is what has caused
MUAs to not default text/xxxx to text/plain correctly. We can argue about
the readability of HTML all we want, but we're not going to change the
behavior of these extent MUAs. The result for standards folks and
implementors is that we can't count on this rule anymore.
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.
Personally I'm not that liberal about it, because I don't think anything
but very very basic stuff will "play in Peoria". If users see formatting
that was clearly not intended for humans they will be unhappy and complain.
We've seen this with quoted-printable encoding, text/enriched and text/html
and this complaining has been going on for about ten years (when QP was
introduced).
But as I said before, enough MUA vendors have voted with their
implementations and we're now at the point where it doesn't really matter.
You can't count on any particular defaulting behavior for text/xxxx.
I do think it would be nice to have a top level type that meant: this is
probably text you can look at and make sense of if you don't have an
application that is willing to display it for you. The MUA implementations
would then present the entity as an attachment or similar, but offer to
display it if the user wants.
LL