Re: MIME and the Web

On Sun, May 30, 2010 at 5:56 AM, Larry Masinter <LMM@acm.org> wrote:
> This is a draft  (for TAG ACTION-425) for discussion at an upcoming W3C TAG
> meeting.  In its current form, I think it may be more suitable as a ‘note’,
> but I’d like to get TAG (and community, including W3C and IETF) agreement on
> its contents, before going on to update various Findings, BCPs and
> specifications.

Nice writeup. One tiny editorial comment, and also in case useful,
some historical links from www-talk archives. BTW the w3.org search
there is broken for pre-1995 posts; the content doesn't seem to be
indexed. I found an interesting collection of architectural
discussions from 1992, nothing earlier (but I only skimmed the
archive).

Editorial:
"HTTP 0.9 assumed that what was transferred could be"
- could be what? could be transferred? rendered/displayed?

I also had a quick look into the old HTTP-NG docs as I remembered
there was some detailed critique of MIME in there somewhere, but
didn't find anything useful to cite.

Perhaps also worth citing Apache's mime.types file
http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/conf/mime.types
as one major de-facto database of file type to file name mappings?

Some archive excerpts follow. The fact that both those archives and
www-tag are all public is worth celebrating, I think. (But whether
these links are worth including in your document, I have no
opinion...).

cheers,

Dan





http://lists.w3.org/Archives/Public/www-talk/


http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0038.html
MIME, SGML, UDIs, HTML and W3
Tim Berners-Lee (timbl@zippy.lcs.mit.edu)
Thu, 11 Jun 92 12:22:56 -0400

"1. MIME classification of data formats
	First of all, the MIME job of classifying data formats
	is a useful job which is ideally done by just one
	bunch of people. Ther has been some suggestion that
	the MIME classifications are not well enough defined,
	but they seem to be the best effort yet and one can only
	assume they will eveolve in the right direction. So I'd
	back the use of these for W3."


http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0020.html
MIME as a hypertext architecture
Dan Connolly (connolly@pixel.convex.com)
Sat, 06 Jun 92 00:53:20 CDT

"The WWW project needs an architecture for interchange of structured
multimedia hypertext documents. The original architecture, HTML,
introduced some structuring conventions and a way of specifying
hypertext links.

The HTML format is under stress from several issues:
	* We need an SGML DTD so that we can parse HTML using
	something besides the public implementation of WWW, and so that
	we can verify documents converted from other authoring
	systems such as GNU info, Andew's EZ, or FrameMaker.

	* We need to be able to distribute documents and document
	elements in other formats, including raw 8 bit data streams.
	The SGML NOTATION feature falls short of providing and
	adequate mechanism.

	* The UDI syntax doesn't match the SGML attribute syntax.
	There are problems with quoting out-of-band characters, and
	the length of complex UDI's may exceed SGML limits and/or
	line-length limits of transport mechanisms. Also, the
	terse syntax of UDI's conflicts with the goal that they
	be human-readable.

This is a proposed architecture for global hypertext, addressing
the issues raised by the WWW project, but using the MIME architecture."



http://lists.w3.org/Archives/Public/www-talk/1992SepOct/0024.html
misconceptions about MIME [long]
Dan Connolly (connolly@pixel.convex.com)
Wed, 21 Oct 92 20:09:36 CDT

..."FROM GLOBAL HYPERTEXT TO GLOBAL HYPERMEDIA

The Internet currently serves as the backbone for a global hypertext.
FTP and email provided a good start, and the gopher, WWW, or WAIS
clients and servers make wide area information browsing simple. These
systems even interoperate, with email servers talking to FTP servers,
WWW clients talking to gopher servers, on and on.

This currently works quite well for text.  But what should WWW clients
do as Gopher and WAIS servers begin to serve up pictures, sounds,
movies, spreadsheet templates, postscript files, etc.? It would be a
shame for each to adopt its own multimedia typing system.

If they all adopt the MIME typing system (and as many other features
from MIME as are appropriate), we can step from global hypertext to
global hypermedia that much easier."



http://lists.w3.org/Archives/Public/www-talk/1992SepOct/0035.html
Re: misconceptions about MIME [long]
Larry Masinter (masinter@parc.xerox.com)
Tue, 27 Oct 1992 14:38:18 PST

""If I wish to retrieve the document, say to view it, I might want to
choose the available representation that is most appropriate for my
purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
from an anonymous FTP archive, only to discover that it is in the
newly announced Postscript level 4 format, or to try to edit it only
to discover that it is in the (upwardly compatible but not parsable by
my client) version 44 of Rich Text. In each case, the appropriateness
of alternate sources and representations of a document would depend on
information that is currently only available in-band.

I believe that MIME was developed in the context of electronic mail,
but that the usage patterns in space and time of archives, database
services and the like require more careful attention (a) to
out-of-band information about format versions, so that you might know,
before you retrieve a representation, whether you have the capability
of coping with it, and (b) some restriction on those formats which
might otherwise be uncontrollable.
""

http://lists.w3.org/Archives/Public/www-talk/1992SepOct/0056.html
Re: misconceptions about MIME [long]
Larry Masinter (masinter@parc.xerox.com)
Fri, 30 Oct 1992 15:54:56 PST

"I propose (once again) that instead of saying 'application/postscript'
it say, at a minimum, 'application/postscript 1985' vs
'application/postscript 1994' or whatever you would like to designate
as a way to uniquely identify which edition of the Postscript
reference manual you are talking about; instead of being identified as
'image/tiff' the files be identified as 'image/tiff 5.0 Class F' vs
'image/tiff 7.0 class QXB'."

Received on Sunday, 30 May 2010 08:30:15 UTC