IPP> Re: JMP> Cancel

IPP> Re: JMP> Cancel

IPP> Re: JMP> Cancel

Scott Isaacson SISAACSON at novell.com
Fri Aug 29 16:59:56 EDT 1997

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
> 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
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'
than forcing it to move the job to the 'cancelled' state.  When the
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
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
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.



More information about the Ipp mailing list