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