Re: HTTP: T-T-T-Talking about MIME Generation

> > As I said earlier (while many of you were off at the IETF?), I'm
> > increasingly convinced that HTTP messages are (as the recent spec
> > suggests) MIME-like, not MIME conforming. With so many other
> > deviations from MIME, I suggest we should drop the (rather complex)
> > MIME multi-part structure based on boundaries, etc. and only allow
> > multi-part messages defined by a Content-Length byte count.
> 
> I think we went through this with HTML; one might have said (many did)
> that:
> 
> "... HTML files are (as the recent spec suggests) SGML-like, not SGML
> conforming. With so many other deviations from SGML...."
>   
> I think the original *intent* was to be MIME conforming, and that it
> isn't *hard* to be MIME-conforming, and that there are *benefits* to
> being MIME-conforming.
[...] 
> MIME is not basically a text-based protocol, any more than HTTP is.

I'd be the first to agree that MIME is a fine example of protocol
design. But it has different design objectives, the chief one of
which is to stuff all sorts of data types into (possibly broken)
implementations of RFC822 messages and SMTP transport. These are
clearly lines of text. The MIME standard does not really say much
about the "binary" content transfer encoding that we say we are
using, and says nothing about using it in the body of a message.

My view of "MIME-Conforming" is that "you can parse it with
the MIME RFC", not "redefine half the protocol and call it MIME".
I don't see how a message with a body containing a un-encoded GIF
can be represented with the MIME RFC.

We use a bunch of headers not in MIME or RFC822 and we redefine
some headers found in MIME.

This notion of tolerating different EOL representations
is a sticky one that can be pushed off on the HTTP or HTML specs.

I get the impression some people think that (in particular)
Unix HTTP servers are sending text with bare line feeds (and
not just text/html!) for reasons of efficency (which is
a design goal of HTTP) and not just because they are bad/non-
conforming servers.

We clearly want to use MIME/"Internet Media" types -- I'd suggest
this is our strongest affinity to MIME. HTTP-NG sounds like
it is becoming less RFC822-like.

I think having a multi-part structure that logically maps onto MIME
is a good idea, but we seem to have made and be making different
decisions about transport on a byte-by-byte level.

SGML conformance clearly has particular benifits. What do you all
think are the payoffs (or downsides) to sticking close to the
MIME spec?

-- 
    Albert Lunde                      Albert-Lunde@nwu.edu

Received on Friday, 16 December 1994 06:19:51 UTC