Subject: IPP> MOD - ISSUE: 'canceled' and 'aborted' job state semantics

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Sep 1997 19:45:22 PDT

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: <[email-masked]>
>X-Sender: hastings@zazen
>Date: Wed, 10 Sep 1997 08:47:43 PDT
>To: [email-masked], [email-masked]
>From: Tom Hastings <[email-masked]>
>Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics
>Sender: [email-masked]
>
>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
>
>
>