🚀 go-pugleaf

Excerpts from internet.mmm-people: 14-Aug-90 Re: Multi-media mail
standa.. Larry Masinter@cs.ucla.e (1070)

> I caught the tail end of an argument (well, flame exchange) about
> whether it is important that the mail be viewable on 'dumb' terminals. 
> Are there other issues?

Oh, lots.  Otherwise it wouldn't be any fun.  (Personally, I think the
idea of making a multimedia standard look good on a dumb terminal is
pretty hopeless.  I find it hard to imagine coming any closer than
Andrew does on this score, and that isn't very close, especially for
things like bitmaps...)

Two of the issues that I find most intriguing (possibly because I come
down on a different side than my friend, colleage, and collaborator
Jonathan Rosenberg) are the issues of processability and
programmability.  Here's a brief summary of the issues:

Processability:  A processable document representation is one that can
not only be displayed to the end-user, but also edited in terms of
high-level structures.  For example, think of a multi-font document. 
You could transmit this as a bitmap, and it would be readable, but
scarcely editable at all.  You could transmit it as text along with
indicators of the font (e.g. "@timesroman14bold(Hello)") and that would
be largely editable/processable.  Best of all, you could transmit it
with structural indicators that might not be translated into fonts until
the last minute, when the output capabilities are really known, e.g.
"@majorheading(Hello)".  You can think of these three cases as being on
a scale of increasing processability.

Programmability:  A programmable document is simply one that includes
code, either instead of or in addition to  data.  If I can send you code
through the mail and have it run automatically when you read it, I can
build all sorts of mail-based services.  (This sounds like a
mind-bending security hole, but it doesn't need to be.  My current
research has produced a powerful language for safely sending programs
through the mail.)

What's really interesting is that the two goals of processability and
programmability are in some measure incompatible.  (Can programs be
processed?  Think about the halting problem.)  My current belief is that
the ultimate mail standard should include both processable and
programmable components, but I'm not terribly happy with that.

Another open issue is extensibility of the multimedia standard to new
media types.  Andrew really broke new ground on this one -- it is
amazingly easy to add new media types (animation, video, annotated
hypertext, whatever) to an installed Andrew base.  Yet multimedia
messaging only works if EVERY site makes such installation, because the
new media types are  defined at the level of C code rather than at the
level of Andrew representation.   (Alternately, Andrew permits you to
make many such extensions, nearly to the level of new media types, using
the embedded Ness programming language.  However, this can open up real
security problems if generalized and used.)  Contrast all this to ODA,
which is fine for a few media types (rich text, rasters) but which
requires a multi-year stnadardization process in order to add new media
types.  The "right" answer is far from obvious.

Those are just three issues that particularly interest me.  If you want
a more exhaustive list of issues in multimedia mail, you could do a lot
worse than ask some of the thousands of Andrew users what they dislike
about the system...  :-)

 ----------------------------------------------------------------------
  [An Andrew ToolKit view (a raster image) was included here, but could
not be displayed.] [An Andrew ToolKit view (a raster image) was included
                   here, but could not be displayed.]

           Nathaniel S. Borenstein <nsb@thumper.bellcore.com>
        Member of Technical Staff,  Bell Communications Research
Office: Bellcore Room MRE 2A-274, 445 South Street, Morristown, NJ 07962-1910
        Work phone:  (201) 829-4270     Work FAX:  (201) 829-7019
     Home: 25 Washington Ave., Morristown, NJ 07960, (201) 993-8586