I would like to strongly object to the introduction of text/enriched.
Here are my reasons:
1) I have already written a text/richtext parser. It was easy to
write and I have the funtionality I need. Adding another new
formatting type to my parser would double or triple the complexity
with no gain.
2) Here at CMU there are a number of richtext generating clients, as
well as a few non-MIME compliant readers. I've read large
text/richtext documents untranslated without problems. In particular,
the <nl> didn't bother me as much as the double-spacing effect would
in text/enriched (I can say this for a fact, since ATK textversion 12
uses the same line break algorithm as text/enriched, and I've read
lots of unprocessed ATK files).
3) The <verbatim> command is awful. It creates an entirely different
document format nested within the enriched format -- something the
MIME multipart was designed to avoid. If you want "verbatim" text,
use a multipart with a text/plain part. Since the primary use of
"verbatim" would be including code samples, it would be desirable to
have those samples easily extractable -- which is an automatic bonus
with MIME multipart.
4) Creating yet-another-richtext-format will just force smart clients
to be larger. If it isn't broken, don't "fix" it.
5) text/enriched does a poorer job of meeting it's first and primary
goal (that of simplicity) than text/richtext does. This is proven by
the fact that the text/enriched minimal parser is significantly longer
than the text/richtext one.
6) The <nl> in text/richtext is an obviously unambiguous linebreak.
The double-newline convension in text/enriched is more confusing and
harder to implement on a line-based parser. (I know this from
experience having written a minimal ATK parser and a text/richtext
parser).
7) The automatic linebreak caused by the formatting commands (e.g.
<center>) is unnecessary. The parser has to keep a "formatting state"
anyway because the formatting commands can be turned off at any time.
This only forces the minimal parser to recognize those commands, which
it might otherwise be able to ignore, and implement the appropriate
line break formula. I think this is a worse error than the minor
problem that "/paragraph" causes for text/richtext.
My apologies if any of these issues have been addressed before (I try
to avoid reading too many lists so that I can get my work done, so I
wasn't following earlier discussions).
- Chris Newman
Carnegie Mellon University Computing Services