This is a good question, and one I've thought about. In fact, it is the
main reason why my idea of an absolutely minimal rich text format
includes the "invisible" environment -- it provides a rock under which
you can hide things.
Imagine, for example, that you have a system like Andrew. (Gee, why did
I pick that one?) Currently, it sends rich text in an idiosyncratic
format that is certainly a superset of what "richmail" can do. Now,
assuming that anyone is interested in promoting the spread of Andrew,
look at it from that person's perspective. One of the biggest
inhibitions currently present for Andrew users is the lack of certainty
that their rich text will be intelligible to its recipients. So, those
with an interest in promoting the use of Andrew for rich text have a
built-in incentive to provide tools that will convert Andrew format to
richmail -- or, better still, to convert Andrew to using richmail for
its rich text format.
Now imagine, as is certainly the case, that there are things you can do
in Andrew but not in richmail. No problem. You include any necessary
formatting information in "invisible" regions. The following example
doesn't use Andrew syntax, but uses a syntax that I hope will make the
intention clear. It represents something richer than richmail in a
completely richmail-compatible way:
%invisible(*MAGIC-COOKIE* -- THIS IS A RICHMAIL ENCODING OF FOOBAR FORMAT.
FOOBAR-EQUIVALENCE: ITALIC+INDENT = QUOTATION)
Hello there %bold(Bob),
%invisible(@set[interlinespace 1.45 angstroms])
I was %italic(really) glad to see you the other day.
Now, someone whose mail reader handles richmail by translating it to
text will just see:
Hello there Bob,
I was really glad to see you the other day.
Software that handles richmail format, but is not from the FOOBAR
company, will show the same thing, with "Bob" in bold and "really" in
italics. But software from the FOOBAR company will also handle the
interline spacing properly, and will recognize that the combination of
italics and indenting implies a specialized "quotation" environment, to
be handled somewhat differently, perhaps. (I'm not sure that the
latter is the right way to do it -- it might be better to just use
%foobar-quotation and let most people treat it as %no-op, but that's up
to the FOOBAR people.)
Stepping back a bit: So far, there are two proposals on the table for
richmail. My original makes at least minimal support required for
RFC-XXXX compliance. Others have proposed moving it to a separate RFC.
An obvious compromise would be to keep the definition in the RFC, but
not make it required. Obviously I'm not as happy with this, but I'm
used to compromising by now. From my perspective, requiring it is best,
but it is at least more likely to be implemented if it is DEFINED in the
RFC than if its definition is in a separate RFC. Would making it
optional make it easier for people to live with?