At 12:07 PM -0400 8/20/98, Keith Moore wrote:
On Wed, 19 Aug 1998, Keith Moore wrote:
One certainly can't re-use the text/html label for such a profile as
there
are deployed clients which deliberately don't display text/html to
the user
because it's almost always unreadable (I'm using one such client).
Surely this is configurable?
Not only is it not configurable in my client, but it's quite clear that
any new text subtype will be treated as an attachment and not displayed by
a significant number of deployed clients. That means if we want a
chance at fixing the text/plain problem, the fix will also have to be
called text/plain. Quite unfortunate.
That's a bit of a surprise. Most of the MIME UAs I know of are
configurable on a per-content-type basis. I realize that there
are a lot of deployed clients that don't do the text/foo default
according to the specs, but I'm surprised if most of them can't
define specific handling for text/foo.
I don't think requiring configuration is an option here. Most people have
no idea how to configure handlers for different media types. Most rely on
the three letter file extension or the Macintosh type/creator.
I believe for this text format to fly is has to seemlessly work with
existing mailers.
LL
BTW, I think it was probably text/html that created this problem. It should
have been application/html. Then it would still be safe to display unknown
text subtypes.