Please send any comments ahead of time as well.
Thanks,
Tom
>Return-Path: <ipp-owner@pwg.org>
>X-Sender: hastings@zazen
>Date: Wed, 10 Sep 1997 08:47:43 PDT
>To: ipp@pwg.org, jmp@pwg.org
>From: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: IPP> MOD - 'canceled' and 'aborted' job state semantics
>Sender: ipp-owner@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
>
>
>