I am cross posting this to IPP because I believ that it has
relevance to the semantics of the IPP Cancel-Job operation ..
Harry writes:
>>> Harry Lewis <harryl at us.ibm.com> 08/29 1:45 PM >>>
> We've had a bit of debate, here, about whether, upon detecting a cancel
> request, the agent should
> A. STATE=Processing REASON=processing to stop point
> B. STATE=Cancel REASON=processing to stop point
> ...
> The crux of the discussion is whether it's better to change State to
Cancel
> ASAP upon recognizing the request (B) or
> not change State to CANCEL until the cancel operation is complete and all
> MIB values are in their final state.
I agree with Harry that the solution should be to allow an implementation
to acknowledge the cancel request yet not force it to move the job
state to the cancelled immediately.
It has been our experience that many implementations can NOT immediately
and completely realize the full cancel semantics at the exact moment in time
that a cancel request is recieved: page images may have been buffered up,
paper might still be flowing through the print path, some devices simply
don't
support any notion of cancel at all.
It is much better to allow an implementation the option of keeping the job
in the 'processing' state and set a reason to 'processing-to-stop-point'
rather
than forcing it to move the job to the 'cancelled' state. When the
implementation
finally does move the job to the 'cancelled' state, then all parties can be
assured that there will not be any more changes to any of the other job
size and resource type attributes.
I propose that this be the semantics that we apply to the Cancel-Job IPP
operation. If the response to the Cancel-Job comes back as "ok", the
implementation is confirming that it is doing all it can to cancel the job
not
that the job state is now cancelled. However, the implementation is
indicating that the job state will eventually be set to 'cancelled' rather
than 'completed' - this might not not happen though until some point in
time
after the response is sent back. If the implementation supports the
"job-state-reasons" attribute, one of the reasons MUST include
'processing-to-stop-point' after receiving the Cancel-Job request.
Scott