IPP> MIME multipart/* vs HTTP

IPP> MIME multipart/* vs HTTP

IPP> MIME multipart/* vs HTTP

Scott Lawrence lawrence at agranat.com
Wed Apr 30 11:03:25 EDT 1997

  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       <lawrence at agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

More information about the Ipp mailing list