There is a more fundamental question here; when is text/NOTplain
acceptable and when should it be application/NOTplain? For example,
if text/html is ok, is text/sgml? Are we concerned with the exhange
of information or ascii characters?
These are fundamental questions for which I have no answers. Perhaps
there are none. The problem I see is that someone (or some group)
must make a value judgement about test/NOTplain. Is it readable or
not.
From the MIME RFC:
text -- textual information. The primary subtype, "plain",
indicates plain (unformatted) text. No special software is
required to get the full meaning of the text, aside from
support for the indicated character set. Subtypes are to be
used for enriched text in forms where applications software
may enhance the appearance fo the text, but such software must
not be required in order to get the general idea fo the
context. Possible subtypes thus include any _readable_ word
processort format.
On the surface, this suggests that text/html and text/sgml are
reasonable choices. No software is required since the content is in
ascii. One need not make a value judgement as to its readability.
Some will be, some won't; it's mostly a matter of the relative
density of information vs markup.
In the end we come to, "How to judge readability?", And that is
a value judgement. We are left then with constantly trying to find
the (non-existant?) line between text and application. An unsatisfying
endeavor filled with assertions but no facts.
Perhaps there need be only two text subtypes, plain and ascii. Label
everything else Application. Plain implies information that requires
no application to read and understand, ascii means readable text but
may not be understandable to the untrained, and if intended for a processor
is then it is application/WhatEver.
The problem is that the default behaviour does not display the data.
If you want to see application/html then you need an entryu in your
configuration (mailcap) file.
Best.../Ed