IPP>MOD - Too Many IPP Operations?

IPP>MOD - Too Many IPP Operations?

IPP>MOD - Too Many IPP Operations?

don at lexmark.com don at lexmark.com
Wed May 28 11:13:45 EDT 1997


My understanding is as follows:


In the simple case of 1 job/1 document:

 PrintJob - Creates a job and send it to be printed.


Rather than overloading PrintJob we have added CreateJob
to support multiple documents per job.

CreateJob - Use to create a job on the server which
                           responds with some job identifier

SendDocument - Used multiple times to send the
                           multiple documents which make up the job
                           created with CreateJob

With a server that does not support multiple documents
per job, the CreateJob operation is rejected.  The client
can either split the multiple document job into multiple
jobs or go look for a server that supports multiple
documents per job.


ValidateJob is just as you describe.


Hope this helps!


To:       ipp%pwg.org @ interlock.lexmark.com
cc:        (bcc: Don Wright)
From:     rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA
Date:     05/28/97 10:18:34 AM AST
Subject:  IPP>MOD - Too Many IPP Operations?

You all must pardon me if I am covering ground that has been covered
before, but since I was not able to attend the IPP meetings last week my
thinking may be a bit behind where everyone else is at.
In reading through the minutes of the meeting and recent email on the
discussion list, it seems to me that we may have invented more
operations for IPP than we really need. It seems to me that we added
CreateJob to allow a client to validate job attributes prior to sending
all of the print data.  The original send operation (which I think we are
back to) simply transmits the print data. The deBry/Carter proposal
to use multiple send Documents was not accepted. We are
depending upon http chunking to allow the client to send the
print data in pieces and  upon tcp/ip to guarantee delivery.
We added Validate and PrintJob to provide for the simple print case
proposed by Microsoft.  As I read the minutes and email it also seems
that we generally agreed that well behaved clients would always know
printer characteristics, either because the Printer has been "installed"
on the desktop or the client has queried the capabilities of the printer.
So as I see it, we are left with the following:
CreateJob - used to validate the print job
Validate - used to validate the print job
SendDocument - its only value is to transmit the job data
PrintJob - transmits the job data and the job attributes
What am I missing?  In the spirit of simplification, it appears to me that
could get rid of CreateJob and SendDocument. I see little value to
these operations given the current set of proposals on the table.   The
only thing I see is that I save resending the job attributes in the
CreateJob, SendDocument over the sequence Validate, PrintJob.  Since
a well behaved client would know the capabilities of the Printer it would
normally not be necessary to validate job attributes and PrintJob
would almost always be the preferred method to use.

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080

More information about the Ipp mailing list