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.