Roger,
I think you are right that the functionality of the new vs. old operations
is not yet spelled out sufficiently. I think we need more detailed
descriptions of what each operation can submit and what responses it can get.
By introducing the concept of level 1 (simple) and level 2 (full) IPP, we
also need some means for the client to quickly find out what the server
supports.
My suggestion is that if you start off with a Validate operation, it will
return either level 1 vs. level 2 supported, or alternatively give back a
more detailed list of which operations are supported. The latter approach
would allow us more flexibility in the future if we want to add new
operations. Would we allow an implementation to support say Print Job and
Get Attributes, but not Create Job and Send Document? (level 1.5)
The same information would be returned of you ask for Printer attributes
(hence we need a new attribute for this).
This leaves us with the case where the client starts off with a Create Job
operation, and the Printer only supports level 1, in which case the
response needs to contain an error stating either "level not supported" or
"opearation not supported".
Carl-Uno
At 07:18 AM 5/28/97 PDT, Roger K Debry wrote:
>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 we
>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 sequence
>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.
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com