This isn't necessarily so. There is no reason a new RFC can't propose a
different richtext subtype which addresses the problems of the current
specification. This idea goes to the heart of MIME's extensibility -- new
...
This is the heart of our disagreement. Certainly, changing the current
spec would require a step back. A proposal for a different richtext
subtype would not.
The problem is that we have the equivalent of a conformance clause in
1341 that says that some support for richtext is highly desirable for
implementations to be considered as supporting MIME. If we are going to
retain that, then it better point to a "richtext" that we are happy with
and intend to implement and stick with. Standardizing 1341-richtext
and then immediately moving toward a new subtype which is what everyone
really intends to use is a terrible idea unless that new subtype were,
e.g., a strict superset of set of extensions.
Another important issue, which has been raised by several people in
several different forms and contexts, is the argument that 1341-richtext
is insufficiently specified to be appropriate for standardization: that
there are two many ambiguities of interpretation. Presumably, if we
did nothing but clear up those ambiguities and create a solid
specification, it wouldn't force MIME back to another "proposed" cycle.
But that assumes that (i) we would discover that we had an appropriate
number of interoperable implementations of the tightened specification
and (ii) that we could do (and agree upon) the tightening job without an
unacceptable delay in how long it took to produce 1341-bis.
I doubt this is feasible without an unacceptable delay arising
somewhere.
--john