I have a couple of comments on the following scenarios in the document
posted on the server (ipp-scn-3.pdf). The solution may be to simply add
two more scenarios.
Here is the current scenario 3.2
Client submits a print job. The data to be printed comes from a
file on the client's hard drive. It is "pushed" to the Printer.
The Printer is not capable of spooling the output. The data to be
printed was encrypted using the Printer's public key. The user
wants to know where to pick up the finished print job, and what
it costs when it is done. The printer jams while receiving print
data and the job cannot be completed. The remaining data is
flushed.
Here is the current scenario 3.7
Client submits a print job. The data to be printed comes from a
file on the client's hard drive. It is "pushed" to the Printer.
The Printer is not capable of spooling the output. The data to be
printed was encrypted using the Printer's public key. The user
wants to know where to pick up the finished print job, and what
it costs when it is done. The printer jams while receiving print
data and the job cannot be completed. The remaining data is
flushed.
On each of these scenarios, a printer jam occurs and the data is
flushed. I suppose that a similar printer error condition could also
force these 2 scenarios (out of paper?).
I think that a lot of users will want his job to complete *after* the
error condition is corrected, 95 pages out of 100 could have been
printed prior to the jam. Obviously status information should be sent
back to the user, and maybe he should have the option of canceling the
job himself, but not automatically by the printer.
On long jobs sent to printers with small input bins, a paper out
condition could happen prior to the job ever completing.
Mabry.