Since I had some strong arguments against the original richtext, I'll
address some of your issues. Also, those arguments came from experience
writing a parser into a word-processing format (BBN/Slate).
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.
Sorry, you coded to a draft standard. Things change.
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).
Maybe so.
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.
It was broken.
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.
That's not a proof. Richtext was rife with ambiguity and unnecessary
functionality. Longterm success will be dependent on how straight-
forward it is for real parsers and generators to be written, not minimal
ones.
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).
The original linebreaking mechanisms in richtext were ambiguous and
under-specified. There were multiple ways of separating paragraphs
with no clear understanding of what (if any) differences in semantics
these implied. The mechanism in text/enriched is much clearer.
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.
The original spec was ambiguous. What did centering a single word, etc
mean? Andrew always generated the commands with newlines, but the
spec didn't require it. The enriched version is much clearer.