Carl-Uno said we could have 15 minutes on the joint IPP/JMP job-state
and job-state-reasons issues (see attached).
JMP people, please call in, so we can put these issues to bed for both
IPP and JMP.
(NOTE - the entire document is NOT included in the e-mail. You should
fetch at least the .pdf file without revison marks (jobstate.pdf) from the
ftp server).
Thanks,
Tom
>Date: Wed, 04 Jun 1997 05:53:39 -0700
>To: jmp, ipp
>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: Updated IPP/JMP joint job-state/job-state-reasons specs for IPP
telecon today 1:00 PM PDT (4:00 PM EDT) with a few issues
>>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.
>>