Re: Line Wrapping Question

Terry Crowley <tcrowley@vermeer.com> Fri, 09 February 1996 20:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25494; 9 Feb 96 15:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25490; 9 Feb 96 15:57 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa13912; 9 Feb 96 15:57 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id PAA07312; Fri, 9 Feb 1996 15:23:23 -0500
Received: from vermeer.vermeer.com (vermeer.vermeer.com [204.252.75.5]) by list.cren.net (8.6.12/8.6.12) with ESMTP id PAA07261 for <ietf-822@list.cren.net>; Fri, 9 Feb 1996 15:21:55 -0500
Received: from localhost (uucp@localhost) by vermeer.vermeer.com (8.6.5/8.6.5) id PAA09176; Fri, 9 Feb 1996 15:19:47 -0500
Received: from thoreau.vermeer.com(198.69.149.76) by vermeer.vermeer.com via smap (V1.3) id sma009167; Fri Feb 9 15:19:25 1996
Message-Id: <BMSMTP82390751960tcrowley@vermeer>
Date: Fri, 9 Feb 1996 15:19:21 -0800
Reply-To: Terry Crowley <tcrowley@vermeer.com>
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Terry Crowley <tcrowley@vermeer.com>
To: Lennart Lovstrand <lennart@next.com>, Ned Freed <NED@innosoft.com>
Cc: "ietf-822@list.cren.net" <ietf-822@list.cren.net>, "Sukvinder Singh Gill\ (Exchange)" <sukvg@wspu.microsoft.com>
Subject: Re: Line Wrapping Question
In-Reply-To: <01I0ZGUIC7OQ9QUQZX@INNOSOFT.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7Bit
X-Mailer: BeyondMail for Windows/SMTP 2.2
X-BeyondMail-Priority: 1
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN

Just an historical point on text/richtext.  I think (perhaps incorrectly) that
I played a significant role in getting richtext dropped from the original MIME
spec.  While working on BBN/Slate, a multimedia mail system of CMU's Andrew's
ilk, I tried to implement text/richtext input/output converters.  I found that
1) it had many Andrew-based predjudices in its text model that did not jibe
with the model in either Slate or your typical Mac/Windows simple text
processor and 2) there was an amazing amount of implied semantics that came out
of Andrew's handling of formatting that was not in any way part of the spec.

In addition, it had "the kitchen sink" including
headers/footers/footnotes/floating figures/keep with next, etc. that was
entirely inappropriate for a common denominator rich text format.
text/enriched is much more tightly specified and much more constrained in the
kind of markup it is trying to provide.

Terry