I'd like to put this ISSUE of the 'canceled' and 'aborted' job state
semantics on the IPP agenda for next week, 9/17, so that we can keep
IPP and JMP in synch for job states.
Please send any comments ahead of time as well.
Thanks,
Tom
>Return-Path: <ipp-owner at pwg.org>
>X-Sender: hastings at zazen>Date: Wed, 10 Sep 1997 08:47:43 PDT
>To: ipp at pwg.org, jmp at pwg.org>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics
>Sender: ipp-owner at pwg.org>>There has been a good discussion in both the IPP and JMP DL about
>the semantics of the 'canceled' state: whether the job moves to
>'canceled' state immediately upon acceptance of the Cancel-Job operation
>or whether the job moves to the 'canceled' state when the canceling has
>completed and the job is quiescent (all the job accounting counters have
>stopped counting, and all the media sheets are stacked).
>>Usually the time difference is just a few seconds after the Cancel-Job
>operation has been accepted, but in some implementations the time could be
>considerably longer than a few seconds, including fixing a paper jam or
>paper out.
>>The same discussion also applies to when the system aborts a job.
>Does the job move to the 'aborted' state immediately, or when the
>system finishes aborting the job?
>>The 'completed' state is specified as being reached when all of the
>processing, including "media sheets successfully stacked", so that the
>'completed' state is reached after the job is quiescent.
>>It is hoped that we could discuss this issue at the IPP telecon today
>and continue and resolve it at the IPP meeting next week in Atlanta
>(with JMP participation). We need to keep both specs in synch.
>>>>The issue is whether to continue the current IPP and JMP semantics:
>>>A. Leading Edge Job State Transition:
>>1. The job changes immediately to the 'canceled' or 'aborted' states
>from the 'processing' state with the 'processing-to-stop-point'
>and 'canceled-by-xxx' reasons set.
>>2. WHEN the canceling or aborting is complete the 'processing-to-stop-point'
>job state reason is removed (but the job state doesn't change since
>the job is alread in the 'canceled' or 'aborted').
>>>OR change the IPP and JMP semantics to:
>>>B. Trailing Edge Job State Transition:
>>1. The job remains in 'processing' with 'processing-to-stop-point'
>and 'canceled-by-xxx' OR 'aborted-by-system' reasons set.
>>2. WHEN the canceling or aborting is completed the 'processing-to-stop-point'
>is removed AND the job transitions to the 'canceled' or 'aborted' state
>with either 'canceled-by-xxx' or 'aborted-by-system' remaining.
>>(Actually, the 'aborted-by-system' is redundant with the 'aborted' state,
>but if there every is another reason to abort a job, it may be good
>to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system'
>is also useful in the pending-held state for systems that chose to
>allow a user or operator to release a job that has had a problem,
>perhaps after modifying the job or the environment).
>>>>>PROs and CONs:
>>>1. The 'canceled' and 'aborted' states become quiescent states, like
>the 'completed' state already is.
>>The advantage of Trailing Edge Job State Transition is that the three
>terminal states: 'completed', 'canceled', and 'aborted' would be
>all quiescent state.
>>With the Leading Edge Job State Transition semantics, 'completed' is
>quiescent, and 'canceled' and 'aborted' are not.
>>>2. Easier rejection of operations: just use the job state, not the reasons
>>The advantage of the Leading Edge Job State Transition is that it
>is clearer when operations are illegal: only the job states are involved.
>This is the classis job state transition diagram showing operations
>and job state transitions.
>>So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error
>that the job is in an inappropriate state whenever the job state
>is 'completed', 'canceled', or 'aborted'.
>>With the Trailing Edge Job State Transition, the user and the Printer
>have to look at both the job state and the job-state-reasons in order
>to reject multiple Cancel-Job operations and the job state transition
>diagram is more complicated.
>>>3. Better notification/trapping when job is quiescent
>>The advantage of Trailing Edge Job State Transitions is that an application
>program, such as an accounting program, that gets a notification or trap
>on job state transitions, will get the notification or trap on entering
>the 'completed', 'canceled', or 'aborted' state AFTER all the processing
>has completed and all the counts have finished counting, so that polling
>can be avoided for any additional processing to stop point activity.
>>Also the job state reflects the completion of an operation, not just the
>acceptance of the operation for those operations that are not performed
>before the response is returned, such as Cancel-Job, when the job is
>in the 'processing' state.
>>NOTE: IPP has notification, but JMP does not have SNMP trapping, though
>all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?)
>>>>E-MAIL conclusion:
>>The e-mail discussion seems to favor changing the IPP and JMP semantics
>to "Trailing Edge Job State Transition" semantics, since many protocols
>use states to mean that the operation has finished all of its work.
>Also reducing polling seems to be more important than simplfying the Printer
>implementation and the job state transition diagram when legal operations
>are shown.
>>*******************************************************************
>We need to see if the rest of the IPP and JMP participants agree
>to change the spec to Traling Edge Job State Transition semantics.
>*******************************************************************
>>>Probably neither side would be happy with a compromise that complicates
>the state model by adding a new Job state: 'terminating' (the name
>used for the ISO DPA job state). Then the 'processing-to-stop-point' reason
>would not be needed for this.
>>With such a compromise, there would be a job state transition when the
>Cancel-job operation is accepted (leading edge transition from 'processing'
>to 'terminating') and when the operation completes
>(trailing edge transition from 'terminating' to 'completed',
>'canceled', or 'aborted'). The Cancel-Job operation would be rejected
>when the job was in the 'terminating' job state (as well as when in the
>'completed', 'canceled', and 'aborted' job states).
>>>Comments?
>>Tom
>>>