JMP people,
Pleae call-in today so we can finish the agreements on the IPP/JMP
job-state and job-state-reasons attributes.
June 4
------
Call-in: 1-423-673-6712
Access: 190148
All calls are at 4PM EDT (1PM PDT)
I've cross-posted (again) 5 files dealing with the agreements and updated text
on the IPP "job-state" and "job-state-reasons" attributes and the
corresonding JMP jmJobState and jmJobStateReason1 objects in:
ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/
-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf
-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt
-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc
-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf
-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r-- 1 pwg pwg 89653 Jun 4 12:45 jobstate.pdf
-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:02 jobstate.txt
-rw-r--r-- 1 pwg pwg 113152 Jun 4 12:03 jobstatr.doc
-rw-r--r-- 1 pwg pwg 143298 Jun 4 12:47 jobstatr.pdf
-rw-r--r-- 1 pwg pwg 148621 Jun 4 12:48 jobstatr.pdr
The *.doc files are MS-WORD V6.0a
The jobstate.* are with revisions accepted (i.e., no revisions marks).
The jobstatr.* are with revisions marked from the current texts of IPP
and JMP. The jobstatr.pdf has black revision marks and the
jobstatr.pdr file has red revision marks.
These results are from the joint IPP/JMP telecon last Wednesday,
May 28. There is an IPP issue listed below and in the document
which Carl-Uno said we could handle on the IPP telecon, tommorrow,
Wed, June 4, if it takes a short time. If it takes longer, we will
need to setup a separate IPP Model telecon, since the major discussion
for the IPP telecon will be the new protocol document.
There is also a JMP issue listed below that could be handled at this
separate IPP Model telecon, if the JMP issue listed below need discussion.
JMP people,
Please read these files to make sure you agree with the agreements we
reached last week on IPP and their impact on JMP. It would be good to
see if we have agreement between IPP and JMP on these crucial
job state and job state reasons attributes (which are JMP SNMP objects).
If you have problems, please raise them on the IPP and JMP DLs so that
we can decide how to process the issues at the IPP telecon tommorrow:
Thanks,
Tom
In the JMP jmJobState and jmJobStateReasons1 spec I added explicity conditions
for each CONDITIONALLY MANDATORY job state and job state reason. Please read
and see if this helps the discussion that JMP has been having around what
MANDATORY and CONDITIONALLY MANDATORY means for SNMP agent conformance.
Tom
Subject: IPP and JMP agreements on job-state and job-state-reasons
From: Tom Hastings
Date: 5/30/97
File: jobstatr.doc (with revision marks) jobstate.doc (without revisions)
This document is the updated IPP "job-state" and "job-state-reasons"
attributes and the corresponding JMP jmJobState and jmJobStateReasons1 objects
from the IPP telecon, of Wednesday, May 27. There we agreed to having 7
states in common between IPP and JMP: pending, pending-stopped, processing,
processing-stopped, canceled, aborted, and completed. The JMP values of the
jmJobStateReasons1 object are a superset of the IPP values of the
"job-state-reasons" attribute.
I've applied revision marks to the specification of 5/25/97 to show the
changes, both to the commentary and the specification.
There are three joint IPP/JMP issues and one JMP-only issue listed below.
I've included Ron's suggestions to
eliminate duplication between the object and textual convention descriptions
and to put more explanation in the objects and less in the textual conventions
in the process.
I've re-ordered the job-state-reasons to be in the order that jobs normally
proceed by job states. This will help with understanding that Jay requested
about "the day in the life of a job".
I've also attempted to make each job state and job state reason more concise
without changing the meaning.
If any Job Monitoring MIB participants disagree with the agreements,
please send e-mail ASAP, since I'm editing the agreements into the
Job Monitoring MIB.
Talking to Scott, I have taken the "job-state", "job-state-reasons", and
"job-state-message" attribute sections from IPP and edited in the
changes with revision marks. After each edited IPP section, I've edited
corresponding Job Monitoring MIB TC and object or attribute section.
I've made jmJobStateReasons1 an object in the jmJobTable, since the JMP
e-mail discussion indicated that it should be MANDATORY. The remaining
jobStateReasons2, jobStateReasons3, and jobStateReasons4 remain as
attributes in the jmAttributeTable. (No attributes in the attribute
table are MANDATORY, except jobOwner, and we are discussing means to
make jobOwner an object in a MANDATORY table, somehow, possibly using the
jmJobIDTable.)
JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of
'pending-stopped'?
The IPP protocol has a "job-hold-until", so having the name of the state be
'held' aligns with that name better making it clearer to the user the
relationship between the attribute and the state. Also some current systems
have a 'held' state, so that current practice for system that have such as
state is to call that state 'held'. Also the ISO DPA has a 'held' state.
Finally, our sub-classing in the names doesn't work for 'completed', since
we have 'aborted' and 'canceled', not 'completed-aborted' and
'completed-canceled', so why have it for pending-stopped, which may prove
fairly startling to a user, while 'held' is readily understandable.
Joint IPP/JMP ISSUE - Should in-coming and out-going jobs be in 'pending' or
'processing' states?
In the IPP Internet-Draft, there is a conflict between the semantics of the
'processing' state specified under the "job-state" attribute and the
"job-state-reasons" values: 'job-sending-to-output-device' and
'job-queued-in-output-device' which we agreed to combine into: 'job-outgoing'.
In the "job-state" definition, 'job-outgoing' is in the 'processing' state,
while the "job-state-reasons" definition says that 'job-outgoing' shall be in
the 'pending' state. Which do we want the IPP and JMP spec to say?
Joint IPP/JMP ISSUE: Should 'completed-with-warnings' and
'completed-with-errors' be mandatory job-state-reasons values or not?
Currently both IPP and JMP specs say they are mandatory reasons.
JMP ISSUE - which JmJobStateReasons1TC values are MANDATORY?
If none are, the jmJobStateReasons1 object could go back to the
jmAttributeTable.
Summary of IPP and JMP job state and job state reasons agreements
------------------------------------------------------------------
Here is the summary of the job state and job state reasons agreements:
1. In JMP remove the 'printing' state.
2. Rename the JMP 'held' state to 'pending-stopped' and rename the JMP state
'needsAttention' to 'processingStopped'.
3. In both IPP and JMP add the 'aborted' state and make it a final state.
4. In both IPP and JMP remove the 'aborted-by-system' job-state-reason,
since the new 'aborted' state says it all.
5. 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.
6. Since the pending-stopped state has been added, JMP no longer needs a
generic jobHeld job state reason.
So the simplified state transition diagram for IPP and JMP was agreed to be:
The following figure shows the normal job state transitions. Other
transitions are unlikely, but are not forbidden.
+--> canceled
/
+----> pending --------> processing --+----> aborted
| ^ ^ \
--->+ | | +--> completed
| v v
+----> pending-stopped processing-stopped
Figure 1 - Normal job state transitions
Normally a job progresses only from left to right.