IPP>PRO - http comments

IPP>PRO - http comments

IPP>PRO - http comments

Scott Lawrence lawrence at agranat.com
Wed Apr 30 14:50:25 EDT 1997


SL> Content-Transfer-Encoding is not supported by HTTP because it isn't
SL> 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.


  That is a different problem - HTTP is not mail-safe; you would have
  to send your objects using conventional MIME encoding (that is, as
  text so spotting the boundary marker is easier, if no less silly
  [IMHO] a way to solve the problem).


  The working group should probably be carefull in this area; as was
  pointed out in Memphis, defining IPP as working over multiple
  transports (Binary IPP, MIME, and HTTP, or any X and Y and Z) is an
  invitation to criticism unless exactly one is required and all
  others are optional.  Defining exactly one (even minimal) required
  way to address any one need is historically much more likely to
  produce the desired situation: that any two conforming
  implementations are interoperable.


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.


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


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.


  My original reply seems to have started an interesting thread on the
  subject on the http-wg list; I'll let you know how it comes out, but
  the opinion that the HTTP Content-Length header may be used for each
  part of a multipart/* seems to be well supported.



--
Scott Lawrence           EmWeb Embedded Server       <lawrence at agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/




More information about the Ipp mailing list