> I'm assuming IPP clients can query that the job was actually printed but in
> most cases the fact that "it got there" is enough. The IPP transaction
> model in many ways resembles the network fax server model where the fax may
> have hit the server on the LAN successfully but had not been routed to the
>In general, that's not a safe assumption. "At job processing time, since the Printer object has already responded with a successful status code in the response to the create request, if the Printer object detects an error, the Printer object is unable to inform the end user of the error with an operation status code. In this case, the Printer, depending on the error, can set the "job-state", "job-state-reasons", or "job-state-message" attributes to the appropriate value(s) so that later queries can report the correct job status... The final value for this attribute [job-state] MUST be one of: 'completed', 'canceled', or 'aborted' before the Printer removes the job altogether. The length of time that jobs remain in the 'canceled', 'aborted', and 'completed' states depends on implementation."
I think that some implementors have argued recently that it's best for a job to go away as soon as it's completed, aborted, or cancelled. So there's no guarantee that a client can query whether the job was actually printed.
See the original message at http://www.egroups.com/list/ipp/?start=4636
Free e-mail group hosting at http://www.eGroups.com/