Your Andrew example is a good one. It illustrates a probable evolution
given a product sensitive to the Internet community's needs.
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.
But for the same reasons, there is compelling reasons for Andrew to
support any such format introduced. Further, isn't there already
a compelling reason for Andrew to support the likes of Microsoft RTF
to facilitate document exchange?
My concern are those products that are not sensitive to the needs of
the Internet community. When, if ever, would Microsoft (my favorite
example) adopt this format? Assuming that others implement a conversion
tool, what have we gained? There would still be extensive programming
effort devoted to support RICHMAIL. This may not be within the mail
community directly, but will certainly be required in the conversion arena.
Why not adopt an existing, albeit busy & rich, specification? For large
numbers of users, they already have the tools to read and write the
format. For others, most or all of the format can be ignored (implicitly
invisible). This is easy to implement because the syntax is consistent.
A few common formats could be recognized, such as bolding and italics.
I caution against any attempt to enter into the document format game.
There is already enough confusion in this area. It is better to rely on
the communities involved and define integration with the available
technology. Perhaps push for a definition of Basic or Simple RTF.
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?
My answer to your question is to make it optional. The advantage of
these text formats is they are simply ASCII. Not supporting the format
will not cause death of a UA. It will simply result in some people
receiving messages with lots of superfluous text.