Subject: Re: IPP> ADM - Minutes from PWG IPP Phone Conference - 98011

From: Carl Kugler <[email-masked]>
Date: Mon, 19 Jan 1998 19:07:33 -0500

The weakness with the MIME way is that it's either unsafe or slow -- either you
arbitrarily pick a boundary string and hope that it doesn't appear in the
binary data, or you prescan the data to make sure.  Content-length avoids those
problems.

---------------------- Forwarded by Carl Kugler/Boulder/IBM on 01/19/98 10:37 AM
 ---------------------------

[email-masked] on 01/19/98 03:25:14 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet, [email-masked] @
internet, [email-masked] @ 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 <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX

---

From: Ned Freed <[email-masked]>
Date: Tue, 20 Jan 1998 02:34:12 -0800 (PST)

> binary data, or you prescan the data to make sure.  Content-length avoids those

Actually, the fact of the matter is that it doesn't have to be either -- it is
quite easy to generate boundaries which in practice are so statistically
unlikely to ever appear in the message text that the chances of, say message
corruption as a result of undetected network errors are many orders of
magnitude greater.

				Ned

---

From: Larry Masinter <[email-masked]>
Date: Mon, 19 Jan 1998 22:25:14 PST

> binary data, or you prescan the data to make sure.  Content-length avoids those
This is the standard argument, but:

In practice, content-length is less safe than multipart boundaries,
and usually slower: you have no way of guaranteeing that the content
won't change even if you *think* it is static, and if the content
is dynamically generated, you have to buffer the entire content
before issuing the content-length. 

Of course, there are alternatives, e.g., a well known termination
string and a content encoding that guarantees the content doesn't
contain the termination string, or chunked encoding. 

Larry
-- 
http://www.parc.xerox.com/masinter