IPP>PRO - http comments

IPP>PRO - http comments

IPP>PRO - http comments

Roger K Debry rdebry at us.ibm.com
Wed Apr 30 13:10:23 EDT 1997


Classification:


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.


RKD> I think some have claimed that we need to be mail-safe,
RKD> i.e. ship an application/ipp MIME via mail.
RKD> I don't personally share that opinion, and if we
RKD> intend to base IPP on HTTP 1.1, then I suggest we
RKD> stick with the MIME-like encodings of HTTP.


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


RKD> I agree with your understanding of how this works.
RKD> I have expressed concern with the use of multipart
RKD> in the past because of this use of the boundary string.



More information about the Ipp mailing list