At 6:01 PM 1/20/93 -0500, Edward Vielmetti wrote:
1341-richtext has not proven to be the useful, ubiquitous, generally
accepted standard that everyone was looking for in a "rich text"
environment. There are no commercial-off-the-shelf word processors
that generate text in 1341-richtext format, no overwhelming use
of 1341-richtext in other internet environments where markup might
be considered useful (eg RFCs), and only passing support for
it (view only) in most MIME software.
Ed, you conclusion is based on a short history. This definition of
richtext hasn't existed long enough for many developers to implement, yet.
If there are serious technical shortcomings making the definition
unworkable, that is a different matter.
Various implementors have observed there are some shortcomings. John
Klensin opined that too many ambiguities have arisen make richtext fixable
and adhere to a reaonable schedule to approve the RFC. Ned Freed has said
much the same. But I am unconvinced. Others have suggested improvements
which might serve.
Yes, it is important for people to send around boldface and underlines
in their texts. But let's face it here, IETF is not a place to
invent word processors, it's a place to work on communications
protocols. It is outside of the traditional scope of IETF activities
to go off inventing things and then hoping people would adhere to them -
the rallying cry if you remember is that is the ISO way!
ooo -- you cut deep :-). This is a fine point. Does higher quality
communication _require_ the use of stylistic marking? We included richtext
under this assumption.
I rankle at the description of the IETF as a body which has not invented
new modes of communication :-).
My recommendatino to the working group would be
- remove references to the details of 1341-richtext from the MIME RFC,
and replace them with pointers to another document
- in that other document provide an overview of ascii formats for
markup of text designed to be in what is roughly considered "rich
text" format, including
* a spec for and history of 1341-richtext
* a similar treatment of the Microsoft RTF format
* a similar treatment of another commercial available format (?)
* a note on SGML and how it might fit
This second document should provide the implementor with
Content-type:
registrations for these other rich formats, code or pointers to
code that strips the formatting out, and a spec or a pointer to
a spec so that someone could build a new minimally conformant system
from scratch.
This is a more detailed version of Ned's proposal. As Steve Summit
observed, Microsoft RTF suffers the same sort of deficiencies found in
richtext.
I fear the confusion resulting from multiple richtext formats: Your MIME
richtext interpreter which does RTF doesn't interoperate completely with
mine which does 1341-style richtext. A minimally conformant system must
have at least one richtext format which is required of *all* MIME
interpreters, or else richtext will never have any utility. This reason is
why I'm leery of removing the richtext specification from 1341.
john noerenberg
jwn2(_at_)qualcomm(_dot_)com
noerenberg.j (Applelink)
===========================================================
That which has always been accepted by everyone, everwhere,
is almost certain to be false.
-- John Millington Synge "Tel Quel" [1943]
===========================================================