Re: Line Wrapping Question

Ned Freed <NED@innosoft.com> Fri, 09 February 1996 17:50 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17861; 9 Feb 96 12:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17857; 9 Feb 96 12:50 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa10939; 9 Feb 96 12:50 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id MAB25815; Fri, 9 Feb 1996 12:21:41 -0500
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by list.cren.net (8.6.12/8.6.12) with ESMTP id MAA25760 for <ietf-822@list.cren.net>; Fri, 9 Feb 1996 12:20:41 -0500
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-6 #2001) id <01I105D73A7K9QUSS6@INNOSOFT.COM>; Fri, 09 Feb 1996 09:18:55 -0800 (PST)
Message-Id: <01I1060UUP809QUSS6@INNOSOFT.COM>
Date: Fri, 09 Feb 1996 09:05:36 -0800 (PST)
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@innosoft.com>
To: Terry Crowley <tcrowley@vermeer.com>
Cc: Larry Masinter <masinter@parc.xerox.com>, ietf-822@list.cren.net, NED@innosoft.com, sukvg@wspu.microsoft.com
Subject: Re: Line Wrapping Question
In-Reply-To: "Your message dated Fri, 09 Feb 1996 09:30:41 -0800" <BMSMTP82388578246tcrowley@vermeer>
References: <96Feb8.151107pst.2733@golden.parc.xerox.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN

> One other point: one of text/enriched's goals was to be an "acceptable" format,
> even for non MIME mail readers.  While text/enriched is readable, I think must
> vendors have found it is not "acceptable".  That is, if our customers are
> sending mail to recipients without MIME software, they don't want to send
> text/enriched, in the same way that they don't want to send QP - any oddities
> make the sender look bad.  That's too bad, because it means slowly growing the
> community to be distributing text/enriched rather than text/plain (when
> text/enriched is the appropriate form for the presentation and content) has
> proven difficult.  Not sure what to do about that, but if we keep on urging
> vendors, including gateways,  to support text/enriched, than eventually we'll
> get to a point where it is acceptable to send since few recipients will
> actually see any oddities.

Part of the problem has been that some of the original programs generating
text/richtext and subsequently text/enriched did not pay any attention to how
their results looked on non-MIME-capable agents. And the results these agents
produced were pretty grotty, to put it mildly -- they were loaded with totally
unnecessary formatting options, line breaks were awful (I remember one that put
each word on a separate line), and so on. This has created an impression in
some quarters that text/enriched cannot be readable in and of itself, and this
really isn't true.

In many cases this wasn't really something these agents could control, as most
of them were inserts into existing backend output frameworks that were never
designed to cater to presentation of raw material containing formatting
commands.

Newer agents are much more careful about this and produce much more readable
output. In fact it may almost be too good -- I've been tricked into thinking I
was editing text/plain when in fact I was editing text/enriched, and I've seen
others fall into the same trap as well. (I guess there's always a downside...)

This doesn't mean that there are absolutely no problems with presenting
text/enriched on non-MIME-capable agents. There are. People will always find
things to complain about, like the customer who complained that a random
MIME-boundary generator had managed to produce something that looked vaguely
like profanity. And text/enriched is still a lot friendlier than text/html in
this regard.

			Ned