I've cross-posted 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 67224 May 27 19:17 jobstate.pdf
-rw-r--r-- 1 pwg pwg 40694 May 27 19:31 jobstate.txt
-rw-r--r-- 1 pwg pwg 102901 May 27 19:17 jobstatr.doc
-rw-r--r-- 1 pwg pwg 121920 May 27 19:17 jobstatr.pdf
-rw-r--r-- 1 pwg pwg 125261 May 27 19:18 jobstatr.pdr
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r-- 1 pwg pwg 67224 May 27 19:25 jobstate.pdf
-rw-r--r-- 1 pwg pwg 40694 May 27 19:25 jobstate.txt
-rw-r--r-- 1 pwg pwg 102912 May 27 19:25 jobstatr.doc
-rw-r--r-- 1 pwg pwg 121956 May 27 19:26 jobstatr.pdf
-rw-r--r-- 1 pwg pwg 125293 May 27 19:26 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 21. There is an IPP issue listed below and in the document
which Carl-Uno said we could handle on the IPP telecon, tommorrow,
Wed, May 28, 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:
May 28
------
Call-in: 1-309-671-1035, 1-3pm PDT (4-6pm EDT)
Access: 190148
NOTE: A different number from usual IPP numbers.
Thanks,
Tom
Here is the beginning of the files that I posted (you'll have to
pull the files to see the actual revised texts for IPP and JMP):
Subject: IPP and JMP agreements on job-state and job-state-reasons
From: Tom Hastings
Date: 5/25/97
File: jobstatr.doc (with revision marks) jobstate.doc (without revisions)
I carried out the JMP action item to schedule the discussion about
aligning the job state and job state reasons between IPP and JMP,
Wednesday, 21 May, 1-3pm PDT.
We came to a good agreement taking the best ideas from each. Unfortunately,
Ron and Harry were not in on the call.
There is one IPP Issue and one JMP issue listed below.
I'm attempting to include any rough consensus generated on the e-mail list
since last Wednesday's meeting as well. 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.)
IPP ISSUE - Should in-coming and out-going jobs be in 'pending' or
'processing' states?
In the 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'.
JMP ISSUE - generic job-held job state reason vs. adding held job state
----------------------------------------------------------------------
when the job is in the pending state to allow job monitoring applications to
be able to distinguish between job state reasons that prevent the job from
being a candidate for processing from those that are just purely informational
without knowing the particular reason (which may be a newly registered reason
that the application couldn't have known about).
IPP solves this problem by changing the keyword values for reasons that keep
the job from being a candidate for processing to all begin with 'job-hold-'.
But the Job Monitoring MIB uses enum codes, not keywords, so there isn't a
good way for the agent to indicate such a distinction to an application.
There are two possibilities:
1. Add a generic jobHeld value to the JMP JmJobStateReasons1TC which an agent
shall set in addition to the specific reason that keeps the job from being a
candidate for processing, i.e., the agent shall set jobHeld along with
jobHoldUntilSpecified, jobProcessAfterSpecified, and
jobHoldUntilResourcesAreReady reasons.
2. Instead of introducing the generic jobHeld value, add back the held job
state to JMP (and leave IPP without the 'held' state, since the reason values
are distinguishable to an application from the 'job-hold-' keyword prefix.
I've written up alternative 1, since it is a superset of IPP. However,
alternative 2 is a simple alternative. Since the JMP agent is only reflecting
job state and not implementing a job state machine, the complexity of another
job state is not such a problem for implementing an agent and is somewhat
easier for the application.
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 'held', 'printing', and 'needsAttention' states.
2. In both IPP and JMP add the 'aborted' state and make it a final state.
3. In both IPP and JMP remove the 'aborted-by-system' job-state-reason,
since the new 'aborted' state says it all.
4. 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.
So the simplified state transition diagram for IPP and JMP was agreed to be:
New state
Old state <non- pending processing canceled aborted completed
existent> (3) (4) 5) (6) (7)
<non-existent> yes yes
pending(3) yes yes
processing(4) yes yes yes
canceled(5) yes
aborted(6) yes
completed(7) yes
Generally state transitions are from left to right. A blank
entry indicates unlikely, but allowed, transitions.
The following diagram is simpler to understand than the table, so lets
replace the above table with the following in both IPP and JMP:
+--> canceled
/
pending --> processing --+----> aborted
\
+--> completed
Normally a job progresses only from left to right through three states.
Conformance Requirements for job states
---------------------------------------
JMP requires that processing(4), aborted(6), and completed(7) are mandatory,
so that pending(3), canceled(5), and unknown(2) are conditionally mandatory.
(IPP level 1 does not have CancelJob, so we have to make the canceled state
conditionally mandatory in JMP in order to instrument a level 1 IPP system.)
The former JMP needsAttention state was also mandatory, so that the
equivalent new job-state-reason: deviceStopped, is a mandatory value of
the JMP jmJobStateReasons1 object. The deviceStopped value aligns with the
IPP 'printer-stopped' value of the "job-state-reasons" attribute, but we
are trying to be more general in JMP, so we use the word 'device', not
'printer'.
If deviceStopped is a MANDATORY reason, then the jobStateReasons1 attribute
becomes MANDATORY. Therefore, the jobStateReasons1 JMP attribute moves to
the jmJobTable, since it is an Integer, not Octets, and will be called
the jmJobStateReasons1 object. The other 3 jobStateReasonsN (N=2, 3, and 4)
will remain in the jmJobAttributeTable as conditionally mandatory attributes.
There were two major reasons that IPP replaced the 'needs-attention' state
with the 'printer-stopped' job-state-reason:
1. IPP felt it was as important for a user to know that the printer that their
job was waiting for was stopped, as it was for the user whose job was the
current job. Therefore, whether the job was in the 'pending'
or 'processing' state we wanted to indicate that the printer had stopped for
the job. Therefore, need-attention is really a reason, not a state.
If needs-attention were a job state, when the printer resumes, the job would
go back to either 'pending' or 'processing', depending on which state the job
had been in previously.
Remembering which previous state was a problem. Also the user should know
whether his job was the current one or some other users was the current job,
since in an unattended shop, the onus might be on the current user to fix the
problem. By keeping the job in the same state ('pending' or 'processing'),
instead of moving the job to a different 'needs-attention' state
and setting the job-state-reason, there was no need to remember the
previous state.
2. The job state reason was renamed from 'needs-attention' to
'printer-stopped', because the printer might need attention but the current
job could still make progress because the printer hasn't stopped. For
example, toner low or media low or an input tray is empty, but the current
job is not using that tray. Also the operator might have intentionally
stopped the printer, so needs-attention would be misleading.
You'll have to copy the files from ftp://ftp.pwg.org/pub/pwg/
cited above in order to see the actual text changes to IPP and JMP.
Tom