MIME Transfer Format (is Re: Protocol Benchmarking...)

• Mail folder: WWW Talk Jan 94-present
• Next message: Ari Luotonen: "Re: Protocol Benchmarking (with Accept examples - long)"
• Previous message: Jon P. Knight: "Re: Protocol Benchmarking (with Accept examples - long)"

From: koblas@netcom.com (David Koblas)
Message-id: <199402030938.BAA17954@mail.netcom.com>
Subject: MIME Transfer Format (is Re: Protocol Benchmarking...)
To: www-talk@www0.cern.ch
Date: Thu, 3 Feb 1994 01:38:20 -0800 (PST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 2411      

Christopher McRae writes:
>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 objectsare just one of
>the object types we're all interested in squirting around the net.
>
>Example:
>
>    MIME-Version: 1.0
>    Content-Type: multipart/related;
>    boundary=unique-boundary-1
>
>    --unique-boundary-1
>    Content-Type: application/html-control
>
>    [
>      here is where one would put a simple control script instructing
>      the browser which part to show first, second, etc.
>    ]

This is a nifty idea, though it could be simplified...

Instead of "Content-Type: application/html-control", it might be better
to make it "applicaton/url-index" and then instead of scripting commands
it could be just a list of URL's for the message.  Thus boundry-2 would
refer to the first URL (the one requested), boundry-3 the second URL (an
inlined image), etc.  This way a browser would load a short-term-cache of
URL's that it already had just been sent.  There is ONE problem, which is
that still a server might say 'Accept: image/gif' but, is really a text
based browser and thus can't do inlined images... thus the images shouldn't
be sent.  [if somebody has a solution to this (inlined images), I might be
tempted to generate an example server...]

However this still stuffer from one problem, it means that the server
has to parse every document (or have a document dependancy list built).
Part of the "advantage" of having persistant HTTP connections where
mulitple gets could be issued, is that the inlined icon problem isn't
such a problem.  Also, for URL's that refere to connection orieted
services (aka FTP) then the connection wouldn't be torn down every time.

--koblas@netcom.com

ps.  You still could have the second boundry message be
     'applicaton/www-control', which could do all of the complicated
     things you would like.