Subject: JMP> Final IPP/JMP job-state and job-state-reasons

From: Tom Hastings <[email-masked]>
Date: Wed, 11 Jun 1997 01:09:59 PDT

I've cross posted the final updates IPP and JMP job-state and job-state-reasons
specifications with the final agreements reached on the June 6 telecon.  I've 
incorporated the JMP specifications into the MIB.

Scott will integrate the IPP specifications into the Model document.

ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r--   1 pwg      pwg        57826 Jun 11 07:45 jobstate.pdf
-rw-r--r--   1 pwg      pwg        41694 Jun 11 07:45 jobstate.txt
-rw-r--r--   1 pwg      pwg        92160 Jun 11 07:46 jobstatr.doc
-rw-r--r--   1 pwg      pwg       109555 Jun 11 07:48 jobstatr.pdf
-rw-r--r--   1 pwg      pwg       114072 Jun 11 07:49 jobstatr.pdr

ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/
-rw-r--r--   1 pwg      pwg        57856 Jun 11 07:55 jobstate.doc
-rw-r--r--   1 pwg      pwg        57826 Jun 11 07:55 jobstate.pdf
-rw-r--r--   1 pwg      pwg        41694 Jun 11 07:56 jobstate.txt
-rw-r--r--   1 pwg      pwg        92160 Jun 11 07:57 jobstatr.doc
-rw-r--r--   1 pwg      pwg       109555 Jun 11 07:58 jobstatr.pdf
-rw-r--r--   1 pwg      pwg       114072 Jun 11 07:59 jobstatr.pdr

jobstatr.doc is the revision marks from the last Internet-Drafts of each.
jobstatr.pdr is red revision marks
jobstatr.pdf is black revision marks

jobstate.doc is without revision marks
jobstate.pdf is without revision marks

Here is the beginning of the jobstate.doc file that list the changes:

Subject: IPP and JMP agreements on job-state and job-state-reasons
From:  Tom Hastings
Date:  6/6/97
File:  jobstatr.doc (with revision marks) jobstate.doc (without revisions)

This document is the final updated IPP "job-state" and "job-state-reasons"
attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects
from the IPP telecon, of Friday, June 6.  

1.  We agreed to the following states for IPP and JMP:

    IPP                            JMP
                                   other(1)
    'unknown'                      unknown(2)
    'pending'                      pending(3)
    'pending-held'                 pendingHeld(4)
    'processing'                   processing(5)
    'processing-stopped'           proessingStopped(6)
    'canceled'                     canceled(7)
    'aborted'                      aborted(8)
    'completed'                    completed(9)

2. We agreed on the simplified job state transition diagram sentence at the
end explaining the transitions into the canceled state that are not shown:

For JMP:
The following figure shows the normal job state transitions:

                                                        +----> canceled(7)
                                                       /
    +----> pending(3) ---------> processing(5) -------+------> completed(9)
    |         ^                       ^                \
--->+         |                       |                 +----> aborted(8)
    |         v                       v                /
    +----> pendingHeld(4)    processingStopped(6) ----+

Figure 1 - Normal Job State Transitions

Normally a job progresses only from left to right.  Other state transitions
are unlikely, but are not forbidden.  Not shown are the transitions to the
canceled state from the pending, pendingHeld, processing, and
processingStopped states.  

Jobs in the pending, processing, and processingStopped states are called
'active', while jobs in the pendingHeld, canceled, aborted, and completed
states are called 'in-active'."

For IPP:
The following figure shows the normal job state transitions:

                                          +--> canceled
                                                 /
    +---> pending --------> processing ---------+-----> completed
    |        ^                   ^               \
--->+        |                   |                +---> aborted
    |        v                   v               /
    +---> pending-held   processing-stopped ----+

Figure 2 - Normal Job State Transitions

Normally a job progresses only from left to right.  Other state transitions
are unlikely, but are not forbidden.  Not shown are the transitions to the
'canceled' state from the 'pending', 'pending-held', 'processing', and
'processing-stopped' states."

3. Conformance:  we agreed that no job states are MANDATORY.  
For JMP the sentence proposed by Ron will be added:

All possible enums for this object SHALL be reported if implemented by the
device and available to the agent.  

The corresponding sentence for IPP will be:

All possible job states SHALL be returned by the Printer object if
implemented by the output device and available to the Printer object
implementation.

4. We agreed to not specify which job state reasons go with which states.
An implementation can use the reasons with any state for which the reason
makes sense.

The following JMP sentence will be included in the JmJobStateReasons1TC
textual-convention:

The following standard values are defined (in hexadecimal) as powers of two,
since multiple values may be used at the same time.  These values MAY be
used with any job state for which the reason makes sense.  

The corresponding IPP "job-state-reasons" attribute sentence is:

The following standard values are defined and MAY be used with any job state
for which the reason makes sense.

5. We agreed that job-state-reasons are all OPTIONAL.

The following JMP sentence will be included in the JmJobStateReasons1TC
textual-convention:

Implementation of these values is OPTIONAL, i.e., an agent NEED NOT
implement them, even if the device supports the functionality represented by
the reason and is available to the agent.

The corresponding IPP "job-state-reasons" attribute sentence is:

Implementation of these values is OPTIONAL, i.e., the Printer object NEED
NOT return them, even if the output device supports the functionality
represented by the reason and is available to the Printer object software.

The following are the changes from the previous IPP and JMP published
Internet-Draft specifications:

1. In JMP remove the 'printing' state.

2. Add the 'pending-held' and 'processing-stopped' states to IPP.

3. Rename the JMP 'held' state to 'pendingHeld' and rename the JMP state
'needsAttention' to 'processingStopped'.

4. In both IPP and JMP add the 'aborted' state and make it a final state.

5. In both IPP and JMP remove the 'aborted-by-system' job-state-reason, 
since the new 'aborted' state says it all.

6. In IPP replace the 'terminating' state with the 'canceled' and 'aborted'
states and make 'canceled' and 'aborted' final states, like the
JMP 'canceled' and 'completed' states.

7. Since the pendingHeld state has been added, JMP no longer needs a generic
jobHeld job state reason.

8. No job states are MANDATORY in IPP and JMP.  However, those that are
implemented in the device and are available to the Printer/agent shall be
returned.

9. Job state reasons are OPTIONAL in IPP and JMP.

---

From: "Caruso,Angelo" <[email-masked]>
Date: Wed, 11 Jun 1997 09:00:07 PDT

> the reason and is available to the agent.

The last part of the last sentence here, "i.e., an agent NEED NOT 
 implement them, even if the device supports the functionality 
 represented by the reason and is available to the agent", is 
 pratically encouraging implementors NOT to implement the job state 
 reasons. Why not just say "they're optional", PERIOD? I suggest the 
 wording be shortened to,

"Implementation of these values is OPTIONAL."

for both JMP and IPP.

Thanks,
Angelo