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

David Koblas ([email protected])
Thu, 3 Feb 1994 01:38:20 -0800 (PST)

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.

[email protected]

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