No, but I think there's some stuff on gopher and WAIS servers that
you might be able to get at.
>(2) Is there a consensus on supporting MIME in HTML and vice versa?
There's a growing consensus.
The strategy isn't to shoehorn MIME inside HTML, though we are
shoehorning HTML inside MIME, i.e. there will soon be a text/html
MIME content type.
The strategy is to treat the current data format as a special case of
the more general MIME body part scheme. Currently, www clients expect
text/html or text/plain body parts, and it uses things like filename
suffixes to tell the difference. If you point www at
ftp://ftp.ora.com/pub/davenport/Xhelp/Xhelp_Sept_11.ps
It will gladly fill your screen with unintelligible postscript code.
The strategy is that WWW clients will be able to negotiate various
formats with servers, and the client will know what format the
data is in before it comes over the wire. The other MIME types
will be alternatives to text/html, not enclosures within it.
For protocols like FTP, we need to have type information in
the links, like:
<a HREF="ftp://info.cern.ch/pub/www/NextBrowser.tiff"
type="image/x-tiff">The NeXT browser in action</a>
the the client would know better than to try to display the
contents of the tiff file in a text window. The easiest thing
to do is to pass it off to
% metamail -b -c "image/x-tiff" /tmp/www_ftp.4322
and let metamail to the rest.
For WAIS, the type information is in the protocol. For gopher, it
mostly is. For HTTP, the client and the server are supposed to
negotiate the format based on compute resources required for the
conversion, network transmission time, distortion/loss of data,
etc.
That's my two cents, anyway.
Dan