RE: MIME Transfer Format

Fisher Mark <FisherM@is3.indy.tce.com>
Errors-To: secret@www0.cern.ch
Date: Wed, 9 Feb 1994 09:58:33 --100
Message-id: <2D583D27@MSMAIL.INDY.TCE.COM>
Errors-To: secret@www0.cern.ch
Reply-To: www-talk@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Fisher Mark <FisherM@is3.indy.tce.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: RE: MIME Transfer Format
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3092


(Sorry this is late...  Strangely enough, the listserver requestor wouldn't 
forward my message to the group :))
 ------------------------------------
In <199402030142.AA04574@rock.west.ora.com>, Christopher McRae wrote:

>  This is the right way to do it, I believe.  We've kicked this idea around
>before (see background messages included below), and it's clear that using
>multipart messages is a big win in other ways, too.  For instance, one 
could
>use multipart messages to deliver pages containing sections which would be
>displayed only if certain conditions were met.  The rules specifying how 
and
>when the various sections should be expanded/collapsed would be delivered
>along with the other parts, perhaps as the first part of the multipart. 
 Note
>that this technique is also useful for delivering encrypted information, 
and
>for including the DTD along with a document instance (when we abandon HTML 
for
>arbitrary DTD's :-)
>  In fact, I have been thinking about how one would go about defining 
standard
>ways of putting together such multipart packages.  To use the techniques
>mentioned above, we would need to define a control scripting language for
>describing the relationships between the different message parts and for
>orchestrating their interaction.  In my thinking, this control language 
shares
>some characteristics of the 'Universal network graphics language' which Tim
>brought up on this list last week.  Although I think 'Universal network
>graphics
>language' is a misnomer for the kind of thing we wrote about - graphical
>objects
>are just one of the object types we're all interested in squirting around 
the
>net.

I think that we have two interlocking needs here.  One is the ability to 
send multimedia non-interactive objects, which MIME was developed to handle. 
 What I got from Tim's message (which may not be what he meant :( ) was the 
ability to dynamically and interactively send multimedia around, so that you 
could have events like SIGWEB #4002, "The First On-Line SIGWEB!", or more 
prosaically, videoconference your company's East and West Coast engineering 
staffs in a brainstorming meeting with shared whiteboards (rather than 
erase, just spawn an additional whiteboard...).  Some kind of scripting 
language seems appropriate, as defining the primitives needed for such a 
language is probably at least an order of magnitude easier than anticipating 
every potential use of these capabilities.  Although we may not need to 
bound by the same constraints as MIME (most notably, handling mailers with 
broken line-length and character-set handlers), the MIME nested multipart 
structure looks like a big win to me also.  Any language designers care to 
respond?
======================================================================
Mark Fisher                            Thomson Consumer Electronics
fisherm@tcemail.indy.tce.com           Indianapolis, IN

"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."