-----------------------------
Application message id: 24630260202991/12621 X400
Grade of Delivery: Normal
-----------------------------
VMSmail To information: MUVAXA::MRGATE::"mci
_mta::*emsinternet::*mbx1ietf-822(a)dimacs.rutgers.edu::su=822-list"
Sender's personal name: John C Klensin
I don't know how strongly I believe this, but I'd like to
argue, in essence, against option #2 and/or making the change at
this time.
Most of the balance of MIME involves mail issues and complex
document issues. Some of it also involves character set issues,
but most of those have been pushed off into other places,
partially because there seemed to be a consensus (although over
many objections) that the WG as now constituted was not qualified
and ready to make the character set decisions at this point; that
more reflection and input from character set experts was needed.
I think richtext represents much the same situation. It has
not received a careful examination by more than a very small
number of people who could be considered experts in formatting
and presentation. The number of SGML experts who have examined
it closely seem, from comments on the list, to add up to about
1.5 (Erik and several tenths). Most of the rest of us are in a
good position to know what we like looking at, but not to assess
the long-term implications of a number of possible decisions.
Those issues don't have to do with whether or not it can be
implemented, or implemented efficiently. After all, SGML can be
implemented with moderate efficiency and, with all of its
options, it is a *lot* more complicated. They rather have to do
with interaction with, and leveraging off of, other tools and
facilities. They also have to do with the fact that we have two
successful classes of markup languages floating around--the
low-level ones that specify formatting (troff, TeX,...) and the
high-level ones that specify generic concepts (SGML,...).
Richtext is, right now, as Erik has pointed out, a mixture of
low-level and generic concepts: such languages have not been
successful and have tended to combine the worst features of both
extremes.
And richtext really isn't part of how one organizes a message
for transport, or lays out body parts and identifies and
maintains the relationships among them, it is a layout and
formatting language. As such, there are many arguments for
separating it independent of the fact that we are still
discussing ideas about its details. For me, one of the stronger
is Nathaniel's comment that he sees "richertext" following fairly
soon. The standards process, the RFC structure, etc., are messy
enough for an implementor to follow without deliberately setting
up "obsoletes sections N through M of RFCxxxx, but not the rest"
situations. Let's take it out and put it on its own track, even
if that track is just two weeks behind the structural and
integral part of MIME.
And, regardless of what particular features of MIME most
excite people (of course people are more excited about
presentation issues than they are about little technical details;
what would you expect), MIME is either strong enough to stand
without this being bound to it or we all need to ask what we have
been doing for the last year or so. Presumably, if we were just
building a mechanism for "wrapping" richtext, we could have
figured out easier ways. IMHO, IETF should avoid log-rolling
models in which semi-unrelated weak things are bound together to
get enough agreement to approve the combination. It is
especially inappropriate in this case, where we have, I think,
two very strong things, but ones that require a somewhat
different review process from somewhat different communities.
I don't expect much agreement on this, and won't raise it
again, but, since Nathaniel asked if anyone objected...
john klensin(_at_)infoods(_dot_)mit(_dot_)edu