This was posted in comp.human-factors in response to a message
referencing RFC-XXXX that I posted. Quoted material is mine, the rest
is by Bob Kerns. Folks, what's your opinion regarding Bob's
pessimistic world view? Should we be more optimistic now? What is
our answer to Bob's non-rhetorical question?
Well, both of you: multimedia e-mail may be here faster than you
think. At this very moment a group of clever (*) people are cooking
up an official Internet standard (dubbed RFC-XXXX for now) for the
transfer of various new types of e-mail. Part of the standard
("richtext") will be a standard way to indicate font changes and the
like in a document. This means that the constraints of the medium as
perceived by Erik will change. Being an Internet standard may mean
that both reasons mentioned by Bob Kerns will fade away, at least to
some extent, within the Internet.
[This is not a rhetorical question.]
Why do you believe yet another standard will do the job?
There's a long history of standards in this area, which have
NOT done it, which leads me to believe the inertia is very high.
Sorry, this is untrue. There is NO such "long history" of other standards, at
least none that I'm familiar with. And since I consider myself reasonly
well-informed in this area, other standards, if they do exist, have not been
well-communicated to the world.
As far as I know there is precisely ONE other multimedia mail standard, and
that is X.400. Has X.400 been successful? I would claim that it has not, since
it is over 6 years old at this point and yet there are relatively few
implementations and little use out there (usage is growing, however). There are
a number of reasons for this:
(1) X.400 does not go far enough. Until recently (the 1988 standard) there
was no provision in X.400 for exchanging the types of things people really
want to send. Take a look at the available bodyparts in X.400-1984 and
you'll see what I mean. And the use of OIDs in the 1988 standard has a
number of problems of its own (not the least of which is the assignment and
use of unique OIDs).
(2) X.400 is technically very hard to implement. It also depends in fairly
nontrivial ways on the OSI transport stack, and as such requires some
form of OSI infrastructure to use. All this increases the cost of
implementation tremendously.
(3) X.400 is largely incompatible with previous e-mail standards and conversion
between them is fairly nontrivial. (Yes, I know all about RFC987 and
RFC1148. Take a look at their length as well as the fact that the they
only deal with header conversion before dismissing this point.)
(1) decreases the benefits of X.400, (2) increases the cost, and (3) makes it
difficult to switch things over gradually. These factors as well as others
have contributed to X.400 being only gradually accepted.
Will X.400 ever succeed? Despite the fact that I'm coauthor of RFC-XXXX, I
still think there's a place for X.400 in the world. I'm working on an
X.400 implementation (my RFC-XXXX implementation is mostly done) now. I don't
want to get into a long discussion of which approach is appropriate where, but
I think there is real value to having these two different approaches to the
multimedia mail problem.
We have certainly tried to avoid the problems X.400 has had in our RFC-XXXX
work. RFC-XXXX does not depend on an OSI transport stack. It is, in fact,
highly independent of the stack used, and takes into account that future
transports may not have the limitations that present-day SMTP has. RFC-XXXX is
nevertheless backwards compatible with RFC822 (in fact, it is orthogonal to
RFC822).
Enough on X.400 for now. Back to the "long history" point. There are certainly
a number of private-arrangement facilities for sending and receiving multimedia
mail that are presently in use in the industry today -- Andrew has one, as does
NeXt, and Sun, and BBN Slate, and so forth. None of these are anything close to
a standard, however. These are proprietary solutions to the multimedia mail
problem. As such, they cater to the needs of the communities they were
developed for, and do not meet the needs of the larger e-mail community.
Some of these approaches have been quite successful within their communities.
It is not appropriate to judge them failures simply because they did not
achieve wide acceptance. This was not their goal (at least I hope it wasn't).
Times ARE changing, so I don't reject the concept that another
standard will do the job, but I don't automatically accept it,
either.
I don't accept it either. That's why the standards process is so important. We
need to make sure we come up with something that is well-defined and usable
by the entire community.
Admittedly, the Internet community has a pretty good track record
for actually getting things done, as these things go. But in terms
of mail, a lot of the time the Internet mail standards have been
held back because N flavors of Unix with NY local varients screwed up
if you used feature X in your headers, and so various parts of the
standard never came into play, because people who otherwise followed
the standard didn't dare to use them.
Again, I don't know of any standards that have been held back for such reasons.
There is definitely a history of problems with certain implementations of
Internet mail and their support of some of the more or less arcane areas of the
various standards. We have gone to great lengths in RFC-XXXX to avoid
"stressing" any of these problem areas that we know of.
It seems to me that the same social factors apply even more
strongly to multi-media mail, both at the implementor's level
and the user's level.
To illustrate the problem at the user's level:
If you use Symbolics Zmail, you've had the ability to use multiple
fonts, languages, even diagrams in your mail. But after being flamed
by crippled readers who couldn't handle it, I avoid all use of multiple
fonts in mail.
You were not flamed for using emphasis or for the fact that the unextended
reader could not handle it, you were flamed because Zmail chose not to address
the issue that the stuff it emits looks really ugly on an unextended reader. We
have paid careful attention to this issue in RFC-XXXX. We have three solutions:
(1) The markings used to indicate various font changes and whatnot are not
especially offensive, especially not when used in moderation. The difference
between reading *LOUD* and <emphasis>(LOUD) is not a major problem (to me at
least). (2) The markings can be stripped from message quite easily, so nobody
can claim it is hard to support this stuff on dumb terminals. (3) Alternate
versions of the same material can be included in the same message, making
it possible to select the one that makes sense to a given reader.
By the way, I can think of another reason why mm mail has caught on so
slowly: sheer equipment price and availability. While the happy few
may be used to color RISC workstations for years, I would guess that
by far the majority of e-mail and netnews articles are composed and
read on equipment capable of little more than a single size monospaced
font with 2 or 3 variations.
Has anyone tried to quantify this? Frankly, I know of fewer operating
character-cell terminals than I do typewriters. ... One terminal, and
two typewriters. The character-cell terminal operates our soda machine
here. The typewriters fill out multi-part shipping forms and the like
occasionally.
I'm using a dumb terminal right now to compose this response. I am, however,
using an extended UA on it that won't dump things onto the interface that
it cannot handle.
Most of the use of e-mail I see daily (and I support a community of something
like 3000 active e-mail users) is done on dumb terminals. This is, however,
not a precise cause-effect relationship. People use dumb termnals because
that's all they need. They then tend to send messages that only require
a dumb terminal to view. In order to break out of this circle we have to
provide mechanisms for extending e-mail usefully without jeopardizing existing
use. We have tried very hard to do just this in RFC-XXXX.
I do have the option of converting most of the various image formats and
whatnot into something I can print. So do all other users here. I can also
drive in to work and use my workstation there to view multimedia directly. For
me at least this is a perfectly reasonable setup at present -- I may change
my mind once I start receiving a significant amount of material that forces me
to drive somewhere on a weekend.
I don't claim I'm typical, which is, of course, why I have to ask.
I suspect that the use I see (mostly dumb terminals and/or smart equipment
being used as dumb terminals) is prevalent. I have no numbers to prove it,
however.
RFC-XXXX has a nice provision for
phase-in (at least in theory): a message may be sent as a list of
alternate forms of the message, where a mail reader program should
pick the first (or last, that's still subject to debate :-) form that
it's able to handle.
[I take this as a small piece of the answer to my non-rhetorical
question above, btw; namely that you're trying to solve the problems
which have held back implementation of prior standards].
This is only one of several mechansisms in RFC-XXXX that are there to ease
transitional pain. I strongly recommend that you get a copy of RFC-XXXX and
read it. I still disagree with your assumption that "prior standards" exist
apart from X.400, however.
I hope this isn't your only mechanism for dynamic adaptability.
It is not the only one, and in fact it is not the most important one. See
above.
I know of people doing active work in the area of automatic
transliteration of foreign scripts, and also there are a number
of people working on machine translation. The issue of whether
a reader can handle a particular type of message is really multi-
dimensional. I would hate to have to revert to an ascii message
with the pictures stripped out, just because my machine can't
handle Arabic, just Japanese, and the .signature included an
Arabic quotation
I think this is pretty much a non-issue as far as we're concerned. You're
ignoring the "multipart" portion of the equation here. If you receive a
multipart message that contains pictures and text you'll be able to
read the parts that make sense to your reader. We also have a strategy for
viewing text in character sets that your hardware cannot display. This
functionality may be fairly worthless when dealing with Japanese, but it
works quite well with some languages. Again, see the companion RFCs that
describe mnemonic encoding for additional information on this.
It does sound suitable for phasing in the standard as a whole,
however; it should be easy for old-fashioned readers to just
read the first ascii part, and punt when they come to the
unreadable version. (Which argues for it being better to pick
the *LAST* version you can handle, so the dummest reader can
just show the user the bare ascii version up front).
We had something of an argument over this. On the one side, it is best for the
totally stupid viewer to get the plainest version first. On the other hand,
implementation of the logic to "view the last one you can understand" is tricky
and precludes the use of simple pipe constructs. We have decided for now that
the needs of the old viewers outweigh the constraints this places on new
viewers.
Ned