MIME and binary transport

Marc VanHeyningen <mvanheyn@cs.indiana.edu> (and others) write:
> > > 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?

It does not say how to embed binary objects on the same TCP connection
as the headers without applying an encoding. This is where HTTP seems
to have made an innovation, using Content-Length: (The spec refers
to Content-Length: as an optional header in MIME external bodies
but I haven't found this is in RFC 1521 or 1341.)

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

Well, that's true, but a lot of that is localized in particular parts of MIME.

If we can both transport the same types of body parts and we can logically
map our multi-part structure onto theirs we ought to pick up most of the
extensions.

Larry Masinter <masinter@parc.xerox.com> writes:
>You don't need content-length to search for the boundary. You can go
>ahead and scan the binary data for <CR><LF>--boundary--<CR><LF>. Doing
>so either using a simple scan or using a more elaborate boyer-moore
>algorithm should be computationally not significantly more expensive
>than merely counting bytes.

Yes, you can do this, but to make it work for arbitrary binary files, you
have to choose a boundary that is not in the file, either using a random
string and hoping, or scanning the whole file (which generally costs more
than just determining the size.)

The MIME boundary mechanism is a complex device that we don't need on an
8-bit clean transport, and if implemented, could be sensitive to the EOL
treatment issues, which we are more sloppy about than MIME.

I think we either need to move closer to MIME conformance or a bit farther
away (and I'm leaning toward the latter).

Received on Friday, 16 December 1994 11:41:02 UTC