-----------------------------
Application message id: 21458170202991/12809 X400
Grade of Delivery: Normal
-----------------------------
VMSmail To information: MUVAXA::MUVAXA::MRGATE::"MCI
_MTA::1=US::2=MCI::*EMSINTERNET::*MBX1nsb(a)thumper.bellcore.com::6=N
athaniel Borenstein"
VMSmail CC information: MUVAXA::MRGATE::"mci
_mta::*emsinternet::*mbx1ietf-822(a)dimacs.rutgers.edu::su=822-LIST",
KLENSINJ
Sender's personal name: John C Klensin
Nathaniel,
I don't question whether richtext can be, or has been,
implemented, and implemented elegantly and efficiently. Clearly
those requirements have been met, and can be met for other
environments.
Nor do I question whether it will "do the job"; I think that
there are many kinds of things that will "do the job", and have
every reason to believe that richtext, plus or minus the minor
alterations that have been proposed, is a member of the set.
I question only the following things about what has gone on
here:
(1) As someone recently pointed out, there should be an active
null hypothesis about something that is much more simple, that
builds on the notations that many of us have been using for
years, and that makes no pretenses (or appearances) of being a
formatting language.
(2) If the thing is going to be nearly-SGML, then I have a
very strong preference for going all the way, so that richtext
mail messages can be fed into pre-existing (that makes them
easier than implementing anything, no matter how simple) SGML
processors. This is especially important when one wishes to
route messages to printers because, at least in the environments
I'm used to lately, it has become a lot easier (and more
standard ways exist) to display something enhanced on a screen
than it is to route it to a printer. There are more varieties
of the latter, with different sets of fonts and constraints.
If I have SGML processors around, then I have way of dealing
with those problems; if I have only a "display richtext on the
screen" capability, I may have lots of problems with my cheap
printers. On the other hand, if middle-class-text (as above in
#1) were provided, I might not care.
(3) I want to see MIME evolve into the kind of solid,
use-it-for-a-very-long-time standard such as 821/822 have turned
out to be. I don't think the extended mail-Internet can afford
frequent changes or evolution in its base mail protocols, and I
want to see MIME be part of the base. That, to me, argues very
strenuously for the separation of *anything* that we are already
talking about evolving into improved versions in a relatively
short time from the base MIME document.
(4) As a procedural issue, things have been pulled out of
MIME that, in terms of practice and existing (or claimed)
community commitment, are arguably much more solidly established
than richtext or more in the critical path of some user/usage
community (I'm thinking of mnemonic, the material covered in
RFC-HDR, and ISO-2022-jp, but there have been others). I think
all of those decisions have been correct ones, largely because,
as above, I favor having a very solid base document that
contains only things we are as close to absolutely sure about as
we can get, supplemented by add-ons that taper off toward the
less understood, less precisely documented, or more
experimental/evolutionary.
Nothing has been said so far that is persuasive about richtext
being different from these other examples. You (and others) say
it is vital to have it integrated or closely coupled; Keld (and
others) say it is vital to have mnemonic integrated or closely
coupled. In both cases, there are at least a few people who
want to see a bit more study or careful consideration for any of
several reasons. Yes, it would be possible to revise or
separate when going from Proposed to Draft, but it is likely to
be disruptive, and exactly the same argument could be made for
some of the things we have dropped.
I think I, and the others who are raising this more
comprehensive argument at this late date, probably owe you and
the WG an apology for not identifying the sources of our
discomfort and raising them earlier. In my personal case, it
has been extremely difficult to follow things from here, much
less to make timely responses and I'm sorry about that. You and
Ned also have, as you must know, produced a very long and
complex document (and an excellent one), and concentrating on
the sections that each of us deem most critical, rather than
reviewing each paragraph with equal care, is inevitable. And I,
possibly along with others, have been trapped by the ease of
asking "will this work", rather than "is it the right thing to
do". It is that latter question that is being raised now,
mostly by people who feel a need to have a longer look by a
wider audience and who find enough specifics to make them very
nervous, rather than by people who in any way oppose the general
concept. It is very late in the game, granted, but I think
better now than some months in the future.
--john