To make it easier to generate text/enriched data that includes things,
e.g. C programs with lots of "<" characters.
If you wan't to include something that isn't text/enriched, don't use
text/enriched. Use multipart/mixed, with the surrounding text in
text/enriched and included thing in an apropriate content-type.
How about 5-10 lines of C code indented from the left margin? You can't
easily do that with multipart/mixed. Also, in a metamail-like system,
the reader loses continuity: the first text/enriched part is presented,
and then metamail stops for the C code before showing the following
text/enriched part. In a slightly smarter implementation of the metamail
text/enriched parser which used curses for scrolling rather than dumping
termcap sequences direct to the screen, there would be two calls on the
program, with very little visible connection between them, also making it
difficult for the user to "page up" to before the C code.
For larger pieces of code, I certainly agree that a separate part is better,
but that reflects the use that most people would make of small and large
pieces of code: a small piece is likely to be "inline" as an example or
whatever, whereas a large piece is likely to be an "attachment".
For example, compare:
Content-Type: text/enriched
Here is a recursive factorial function:
<indent><verbatim>
int fact (int n)
{
if (n <= 0)
return 1;
else
return (n * fact (n - 1));
}
</verbatim></indent>
From this, we see that ...
with:
Attached is the latest version of foobarapp.
[...]
Content-Type: application/octet-stream
Content-Disposition: attachment
[...]
Compare the respective size and complexity of the minimal
text/richtext and text/enriched parsers. The text/enriched parser has
at least 50% more code, most of which is for handling verbatim.
Keep in mind that the parser is meant to be the "minimum amount of effort
required". Any "real" text/enriched system is much bigger, and the code
to format the output, perform justification, font changes, etc totally
dwarfs the front-end parser for recognising verbatim in the input stream.
The text/simplemail type is similar: you can either have a small amount
of code for minimum effort, or quite a large amount of code to produce
pretty output on hardware which supports it.
Making a composer quote "<" characters and deal with the CRLF
conventions should take 10 lines of code at most. It's certainly no
more complex than having to deal with quoting "</verbatim>".
The negligible savings you get in the composer are completely
outweighed by the increased complexity of the parser.
On the other hand, making a parser deal with unquoted "<" characters within
a verbatim environment is just as easy ... Just because the parser will
be smaller won't make it better for the range of formatting tasks required,
or make it easier for the users who don't have trendy GUI composers.
If verbatim stays as is, the claim in Appendix B that text/enriched is
a "simplification" of text/richtext should be removed.
The "simplification" refers to the commands that were stripped out, either
because they were pretty useless for messaging (headers, footers, etc),
or because of the dichotomy between commands that required pairing and those
that didn't (there are no unpaired commands anymore). "verbatim" was a
fairly late addition.
I suspect you are making a mountain out of molehill.
Cheers,
Rhys.