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.

It is true that multi-part structures in MIME are designed around constraints
that don't apply here, and changing or dropping them may be a reasonable
thing to do.  Allowing specification by either content-length or by
existing boundaries may be a reasonable thing to do; since existing software
doesn't understand either method, there isn't really an "installed base" issue.
I really would like to think that other, higher level constructs like HTTP-NG
or something like it can make multiparts unneeded anyway.

> > 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.

I certainly would agree that the original versions of the spec were quite
clear about being MIME-conforming, and this was how server implementations
decided they needed to throw in things like "Mime-Version" headers.

> > 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.

It says that "binary" can contain any sequence of octets.  What more does it
need to say?

> 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.

CTE: binary does it.  Of course, few if any ordinary MTAs can actually
transport such an object successfully, but HTTP can.

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

It has to be in HTTP, since it applies to all textual types, not just HTML.

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

It means that, as new things are defined for MIME (like how to represent
Unicode, or how to transport objects with PGP signatures, or how to handle
X.400 stuff) HTTP gets it "for free."  There does seem to be some effort to
re-do some of that kind of work in HTTP and do it differently from MIME, in
some cases because of differences in design goals.

I'm reminded of news, which borrowed a lot from mail.  News, therefore, gets
"for free" the extensions of MIME rather than needing to re-invent them in
a fashion appropriate to its own domain.

It means that a WWW browser already has most of a functional MIME mail user
agent "for free" (or vice-versa, if you prefer.)  The more seamless the
integration of mail, news, and HTTP the better.  It helps improve consistency
and reduces the degree to which implementors must waste time on two separate
bodies of code that do much the same thing with subtle differences.

Received on Friday, 16 December 1994 09:30:59 UTC