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/