Subject: IPP> MIME multipart/* vs HTTP

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 30 Apr 1997 11:03:25 -0400

On the Internet Printing Protocol list the following issues were
  raised in the context of a discussion of whether or not IPP should
  use HTTP/1.1 as a 'transport' protocol, defining IPP operations as
  usage conventions and extentions.

  I will attempt to respond based on my understanding; if anyone else
  on http-wg disagrees, please correct or amplify.

IPP> We discussed how MIME differs from the HTTP MIME-like
IPP> protocol. There was a concern that the HTTP version of MIME
IPP> doesn't support Content-Transfer-Encoding, though we think that
IPP> we probably could add such an entity-header as an extension and
IPP> support it through a CGI script if necessary (though we aren't
IPP> sure about this).

  Content-Transfer-Encoding is not supported by HTTP because it isn't
  needed; the HTTP transport is 8 bit clean.

IPP> There was also a question about how to send binary data in a
IPP> multipart/mixed, especially in the chunked case because there is
IPP> no way to know if a CRLF in the midst of binary data is really a
IPP> CRLF. Thus it is hard to find the boundary string.

  CRLF is what it is - if it is in the binary data and is followed by
  the specified boundary string and another CRLF then you are at the
  end of the body part.  What is the question?

  As I understand it, the selection of a boundary string in MIME is
  already 'probabilistic'; the sender is responsible for choosing a
  string that 'probably' won't appear in the body (I do not claim to
  be an authority on MIME).

IPP> We believe that chunked applies to the entire multipart/mixed
IPP> entity and cannot be used for one of the sub-entities alone.
IPP> Thus there is no length to mark the boundary of a sub-entity.

  Correct; the 'Transfer-Encoding: chunked' applies to all of the HTTP
  message body.  For completeness, my companys' server implementation
  does support chunked encoding of the entire multipart/* body part,
  but we think it doesn't make much sense (because it is redundant) so
  that support may be compiled out to save code.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

---

From: Dave Kristol <[email-masked]>
Date: Wed, 30 Apr 1997 11:55:51 -0400

Scott Lawrence wrote:
> [...]

In my ignorance of MIME, I've been puzzled about this boundary
business.  Assuming each multipart contains a Content-Length header,
does it matter what the boundary is?  Can't the recipient just eat the
number of content bytes before looking for the next boundary?  If so,
the boundary strings don't have to be particularly clever, do they?

Dave Kristol

---

From: Larry Masinter <[email-masked]>
Date: Wed, 30 Apr 1997 17:11:19 PDT

> IPP> CRLF. Thus it is hard to find the boundary string.

It isn't hard to find the boundary string in binary data. Look
for CRLF followed by the boundary string followed by CRLF. It
doesn't matter whether a CRLF in the midst of binary data might
actually be binary data, the robustness of multipart/* is based
on the fact that the boundary doesn't appear, not on the parsing
of CRLFs.

> Besides searching for the boundary marker was very expensive computationally, every byte had to be examnined.

I think 'very' is pretty subjective, and using string matching
algorithms like boyer-moore mean that the number of comparisons
is reduced for longer boundary strings.

>   be an authority on MIME).

The standard says only that the boundary string DOES NOT appear
in the body. It happens that if you know nothing about the body
at all, then you can implement this in a probabalistic way, e.g.,
the likelihood that a randomly generated boundary string would
appear in arbitrary data could be made arbitrarily small ("less
than the probability that the computer would spontaneously explode").

In any case, I don't think we're going to change HTTP to suddenly
require content-length on multipart boundaries; there may be some
clarification needed to identify what's necessary for an interoperable
implementation.

> I was keen to keep the HTTP spec clean ...

We've lost this particular battle a long time ago. I just want
to keep the HTTP spec ambiguous and functional.

I think we could do chunked multipart if we need to, but I don't think
we're going to be able to require senders to generate it, so it
may be that this whole discussion is just 'wishful thinking', or,
to put it another way, part of the requirements setting for
HTTP-NG.