Steve,
Responding to your points in order:
The most salient point, for me at least, is that charset= comes with
text/???.
A MIME message is an RFC 822 message body. I expect to have newline
canonicalization. Doesn't 822 require that?
Getting the user agent to blat it on the screen sounds like saying
a default is needed for application/{a b c ...]. Not tenable. But
using text/{a b c ...} forces the recipient to look at it, maybe we
shouldn't insist, it encourages you to blat all sorts of stuff on my
screen. Application/ give me the choice, abeit with additional
effort.
Kludge proposal: text/char-stream; application=hwatever. Gives
recipeint the choice and one can identify the application. Perhaps
MIME readers could be smart enough to shift between text/char-stream
and application/hwatever. So cute it's ugly ;-), but I couldn't
resist saying it.
I suggest we really want to have it both ways, and we can't.
Best.../Ed
On Mon, 14 Nov 1994 15:38:37 CST Steve Dorner wrote:
At 9:59 AM 11/14/94, Ed Levinson wrote:
There is a more fundamental question here; when is text/NOTplain
acceptable and when should it be application/NOTplain?
True enough. There are three issues that I see. ...
1. If you put it under text/, you get charset= 'for free'.
2. If you put it under text/, you *probably* get newline canonicalization
'for free'.
3. As you mention, if you put it under text/, you *probably* get the
recipient's mailer to blat it onto his screen 'for free'.
In all these cases, I use 'for free' to mean without having to write it
into the specification for the subtype, and without the recipient's mailer
having to have a definition for the subtype.
Depending on your data, any or all of these may be good or bad things.