While I agree that it is not a "safe assumption", the FAX market place has
proven that it is good enough. Perhaps the reason that successful receipt
of the bits is safe enough for FAX, is because FAX is only bits. The chance
for errors, such as font not found, or unsupported PDL operator can't occur.
>"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.
What were these arguments?
I think that the best answer is to finish reviewing and approving our
notification proposal in which the notificaiton that the job had completed
successfully (or otherwise) would get to the sender or whom ever the sender
indicates in the subscription.
>
> -Carl
>
>-----
>See the original message at http://www.egroups.com/list/ipp/?start=4636
>--
>Free e-mail group hosting at http://www.eGroups.com/
>