On 2/8/96 at 5:10 PM, Larry Masinter wrote:
If you're a vendor of MIME-capable software, support for text/enriched is a
must.
Sorry to ask a stupid question, but why not use text/html instead of
text/enriched?
There's two questions here: Why not generate text/html instead and why not
interpret text/html instead?
The answer to the first is easy:
1. Lots of mail packages now interpret text/enriched as a matter of course,
even though some simply unwrap the lines, remove the directives in '<>',
and get rid of the doubled '<' characters. In any event, that means that
you can pretty safely send text/enriched without too many users yelping as
loadly about text/enriched directives in the way they yelled about '=' in
QP. With text/html, most mail packages nowadays will just dump everything
to the screen since the only behavior for unknown text subtypes is to treat
it like text/plain. Users become pissy.
2. Text/enriched has some advantages over HTML, at insofar as RFC 1866 is
concerned. First, it also has no requirement for a <p> or <br> directive to
introduce a hard line break, which means that you can generate a nice plain
text message with no text/enriched markup at all and have it look fine on a
non-text/enriched viewer. Also, it has straight presentation markup, like
an <underline> directive and paragraph indentation, which e-mail users find
important; <blockquote> is not necessarily the markup you want when
something is indented. Newer HTML may address this, but that's not quite
here yet.
***HOWEVER***
Even *I* know that generating text/enriched is only a stop-gap. HTML is
coming at us like a fast moving train and we're going to have to deal with
it (and probably generate it) in the long run. So, the answer to the second
question is a rephrasing of Terry's original claim:
If you're a vendor of MIME-capable software, support for interpreting
text/html is must. Get started now. We certainly are.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated
Home: (217)337-1905 / Fax: (217)337-1980