Subject: IPP> PRO & MOD - Need to synchronize thought on operations

From: [email-masked]
Date: Wed, 12 Feb 1997 17:35:18 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

Carl-Uno wrote:

Some of the discussion lately has been about the possibility to split up
the Print operation into several steps (inspired by the MS approach
presented last week).

I just want us to be clear that if we want to do this, it has consequences
on the operations that the Model group will define (we will need more
operations). As a sideline, it will probably make the solution less
workable over SMTP (for those of you who still think that that is a good
idea).

It will also influence any further discussion on the use of MIME types (we
will need separate MIME types for what goes into each of the "smaller"
operations).

Therefore, I think that this decision is urgent, as it will influence a
number of other text parts in other documents, and we should aim to get
closure on this pretty soon.

<RKD> I've never been much a fan of MIME types or using SMTP, so I don't have
any problems
<RKD> with this change. I think it can be done with minimal impact to the
proposal presented
<RKD> last week in San Jose, and will not require any additional operations.

---

From: Robert Chansler <[email-masked]>
Date: Wed, 12 Feb 1997 16:26:40 -0800

It is easy to understand how the Windows printing API lead to an
implementation like that informatively presented by Babak last week. But
even within the Windows environment, I do not understand how the extra
protocol complexity is either necessary for the implementation or
substantially advantageous for the implementation.

My own prejudice would favor a protocol based upon a single client request
and server response, without requiring either the server or client to
maintain persistent state about an ongoing transaction. Not only would such
a protocol facilitate embedding in alternate transport methods (such as
mail, as mentioned previously), a simple protocol would facilitate
implementations where servers dispatched client requests to peers or other
surrogates for processing. Also I might suppose that the simpler protocol
would be more robust in practice.

Before moving in the direction of a more complex transaction-oriented
protocol, some champion needs to assume the responsibility for making the
convincing argument for inclusion in the protocol rationale.

--------------------------
Robert J. Chansler
[email-masked]
Adobe Systems Incorporated
Mailstop P 8
303 Almaden Blvd.
San Jose, CA 95110-2702

408 536.2295
Fax 408 537.8037