Bill Janssen writes:
As the only format specified in the MIME document, mail implementors
will be forced to spend money and resources implementing it that might
be better spent implementing TeX or troff or SGML or
your-favorite-standard.
This is not true. To quote from the "MIME-Conformance" section:
Text:
...
-- For unrecognized subtypes, show or offer to show the user the "raw"
version of the data. An ability at least to convert "text/richtext" to
plain text, as shown in Appendix D, is encouraged, but not required
for conformance.
The conformance section is the only one that really matters, since it
is this section that determines the "lowest common denominator" among
MIME implementations, and therefore this section defines the set of
features for which interoperability among MIME implementations is
assured.
I didn't make comments about richtext until now because
(a) I'm much more interested in character encoding issues.
(b) Since richtext isn't mandated, it doesn't matter if it's
suboptimal.
(c) I have other work to do, and don't have time to comment on
everything.
In my view, a standard should have a good "signal-to-noise ratio". The
signal in this case is the mandatory part, while the noise is the
optional part. The current MIME document has quite a good signal, but
it is accompanied by a non-trivial amount of noise.
Also, the fact that the authors could not mandate richtext in the
current MIME document implies that the level of acceptance is not very
high.
I agree with John Klensin that MIME should become one of the "base"
standards, much like RFCs 821 and 822 have become. I would argue for a
bare-bones, works-for-sure, lasts-long, framework-but-no-details type
of document for MIME.
Erik