At 6:41 PM 1/19/93 -0700, Ned Freed wrote:
First of all, there intention is not to "remove" richtext, at least not in the
sense of getting rid of it completely. The intention is simply to move it to
a separate document that can proceed at its own pace.
I suspect that the
revisions to richtext this time out will necessitate resetting it to proposed
standard. The rest of MIME will move to draft.
I am not terribly happy with this, precisely because this will be seen just as
you describe: as a betrayal of the installed base by removing a valuable and
However, I also feel we're caught between a rock and a hard place -- in order
to evolve richtext properly we have to change it in ways that necessitate
staying at proposed. Internet rules mandate this.
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
content types or variations on existing ones are possible. Approval of the
current richtext definition doesn't inhibit richtext's evolution.
Richtext may not be perfect in its current form, but moving it out of MIME
carries the implication that richtext is not an essential part of
multimedia mail. The passionate discussion about the definition of the
richtext language suggests this working group believes in the richtext
concept. In all of that discussion, I haven't heard anyone say this
definition is unusable.
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.
But I also feel very very
strongly that MIME must move to draft ASAP.
As do I.
That which has always been accepted by everyone, everwhere,
is almost certain to be false.
-- John Millington Synge "Tel Quel"