The weakness with the MIME way is that it's either unsafe or slow -- ei=
ther you
arbitrarily pick a boundary string and hope that it doesn't appear in t=
he
binary data, or you prescan the data to make sure. Content-length avoi=
ds those
problems.
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/19/98=
10:37 AM
---------------------------
ipp-owner at pwg.org on 01/19/98 03:25:14 AM
Please respond to walker at dazel.com @ internet
To: masinter at parc.xerox.com @ internet
cc: lstein at fapo.com @ internet, paulmo at microsoft.com @ internet, ipp at pw=
g.org @
internet, cmanros at cp10.es.xerox.com @ internet
Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011
Larry Masinter wrote:
>> If you use XML for the protocol mapping and yet want to get
> file data in, you might consider a protocol mapping which separates
> the print data stream from the print protocol using MIME
> multipart, e.g., "multipart/related" where the print protocol
> elements are in an XML data structure, and the binary data streams
> are encoded appropriately just with their MIME media designations
> (application/postscript, etc.).
This seemed like a nice approach to me as well. In fact, I so much
as raised it as a suggestion at the last IPP conference call (only
I being a MIME neophyte suggested "multipart/mixed"; your suggestion
sounds a lot better to me). However, my suggestion was immediately
shouted down, as "this issue had already been discussed in the past,
and a decision made".
Well, as we are re-visiting the protocol encoding at this point, I
would like to have this decision re-considered as well. It seems
like a multipart MIME message, with the protocol and data in separate
parts would be a natural solution.
...walker
--
Jim Walker <walker at dazel.com>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX
=