Subject: IPP>PRO - http comments

From: Roger K Debry <[email-masked]>
Date: Wed, 30 Apr 1997 13:10:23 -0400

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.

---

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

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

  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.

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?

  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       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/