ietf-822
[Top] [All Lists]

Re: HTML in MIME mail

1994-11-14 17:01:01
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.

<Prev in Thread] Current Thread [Next in Thread>