MIME has many facets [Was: Statelessness ]

"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 18 May 1994 19:01:14 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405181656.AA09343@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: MIME has many facets [Was: Statelessness ]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/x-setext
Content-Type: text/x-setext
Mime-Version: 1.0
Mime-Version: 1.0
In message <9405180138.AA20717@tipper.oit.unc.edu>, Simon E Spero writes:
>>>>>> "Jon" == Jon P Knight <J.P.Knight@lut.ac.uk> writes:
>
>Using MIME is 
>not a very good solution in this case, as the vast bulk of all secondary 
>transactions are binary files, and having to scan through byte by byte
>for the end marker is a major  lose.

  Please write "Using MIME multipart/* syntax is not a very good
  solution..."

  MIME multipart/* syntax is designed for use in Internet Mail and
  USENET news, where a reliable bytestream is not guaranteed.

  In the context of HTTP, something like application/tar (or
  application/bento) would be more appropriate. Consider:

  User selects the following anchor:

	<p>For complete details, see
	<cite><A HREF="http://host.com/reports/r100.tar#top.html">
	Report 100
	</A></cite>


  Client connects to host.com and tells the server it prefers
  text/html, image/gif, and application/tar, but it will take
  postscript, tiff, and multipart/mixed:

	GET /reports/r100.tar HTTP/1.0
	Accept: text/plain; q=0.7, text/html; q=1.0
	Accept: image/gif; q=1.0, image/x-tiff; q=0.7
	Accept: application/postscript; q=0.8
	Accept: application/tar; q=1.0, multipart/mixed; q=0.9


  Server looks for /reports/r100.tar in its filesystem, but doesn't
  find it. It does, however, find a directory called /reports/r100,
  and it knows how to convert a directory to a tar file. It may write
  the tar file to disk and cache it (and hence be able to tell the
  client the Content-Length before hand), or it may just pipe the tar
  output right over the wire. (NOTE: the server must check that all
  the constituents are Accept:able to the client)

	200 document follows
	Content-Type: application/tar
	Content-Length: 81920

	...tar file...

  Client receives the tar file, and either stores it in memory or
  writes it to local disk (probably broken into constituent files). It
  knows that fragment identifiers in application/tar entities refer to
  the contituent files.  So it resolves #top.html and displays
  top.html. _AND_ it can resolve relative links from top.html to the
  other parts of the tar archive. So all the <image SRC="xxx.gif">
  files get displayed without any more HTTP transactions.


  The only part of the architecture that needs to change is that this
  strategy requires that the decision of whether to send just the
  .html node or to send the whole collection of files is made by the
  author of the link when s/he writes:

	HREF=http://host.com/reports/r100.tar#top.html"

  ... and that decision should probably be negociated between the
  client and the server based on file sizes, user preferences such as
  "delay image loading", etc.

  I would argue that the long-term solution is richer linking markup.
  But I don't have the whole argument put together just yet...


  MIME, Mosaic, and WWWLibrary
------------------------------

  Does anybody else think it's funky that Mosaic treats message/rfc822
  body parts three different ways?

* If you give a file: reference to a file ending in .mime, it launches
  metamail

* If you give a news: reference, it formats the headers as HTML,
  and displays the body as plain text (no matter what the content-type
  is)

* If the message is an HTTP response, it hides the headers (even the
  interesting ones like Last-Modified:) and displays the body
  according to the content-type.

  Why are these three cases not handled the same way? (or very nearly
  the same... message/http should probably have slightly different
  semantics from message/rfc822)

  And what the heck is "www/mime"? The name refers to the same thing
  that is called message/rfc822 in MIME parlance.

  Dan