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.

Now, we have to be careful to define what we mean by MIME-conforming,
and, in particular, we may well want to register some new MIME-types
or content-transfer-encodings. 

The EOL convention issue is not a 'HTTP' issue but centers around
whether "text/html" is allowed to be more flexible about EOL
convention when transport in binary form than other text forms.

MIME is not basically a text-based protocol, any more than HTTP is.