If we send RichText back to committee we'll effectively block
the implementation efforts that are the only possible source of us really
knowing what we're talking about.
What's to stop us from experimenting with better specs?
Time. I develop e-mail software (among other things). To this end, I will
experiment with and implement specifications that are directly essential to
e-mail. I have limited time, however, and I refrain from implementating
nonessentials unless they fall within an area of interest that I have, or
my company has.
RichText is not an essential feature of e-mail unless it is standards-track. It
is nice to have, but my end users cannot really make use of it until it is
demonstrably going places. I pay a lot of attention to my end-users. An
experimental RichText format that nobody else is going to implement is not
something they can use.
In addition, RichText falls outside any personal area of interest I have. I use
(and for the most part like) SGML-like languages, but I have little interest in
spending hundreds of hours implementing experimental text processing languages.
We were fortunate to have Nathaniel in this group, who had a direct interest in
doing all this work and furthering the goals of RichText. I certainly have no
intention of standing in his way. Far from it -- I think RichText is an
immensely valuable idea and I really want it in the specification _now_. But it
is isn't in there I'm going to ignore it. I have enough things to do already --
I don't need to fiddle with a specification that may evaporate completely on
me.
I suspect that many other e-mail developers feel the same way that I do about
this.
There is of course nothing to stop you from forming a group of experimenters
and trying out things among yourselves. (I fail to see why you didn't do this a
year ago, however.) I've been doing that with most of MIME for quite a while.
(I have the advantage that I have done two MIME implementations and not just
one.)
But there is a limit to how much you can learn from such tests. I believe that
we have reached that limit for most of MIME now. We need to stop dithering
around and release this stuff so that we can see how it fares in a wider world.
Frankly, I don't think any of the recent spate of comments about RichText (and
I reluctantly include Nathaniel's in this group) have been very interesting. I
don't think we collectively have the slightest idea what the real problems are
with RichText. I don't think we'll ever know until a bunch of neophyte users
and system managers are turned loose on various implementations of it and we
get some feedback on it. I think I know my end-user community pretty well,
and yet they manage to amaze me not less than once a week with something
they like, hate, want, or cannot tolerate.
We can continue to argue, and bicker, and drag this out forever. We can satisfy
SGML compatibility (which no user cares even slightly about -- I know this SGML
user sure doesn't). We can twiddle this, diddle that, and generally make the
format nicer (aka Mark Crispin's proposal) or uglier, or whatever. And these
may be good things. But it won't matter. The result of all this work is going
to be "the one we throw away", and continuing the work for another year won't
change that. In fact, the only thing it might insure is the eventual demise of
RichText entirely. And that would be a real loss.
I don't mind implementing "the one we throw away". I can justify that. What
I cannot justify is implementing "the fifty we may never use".
Ned