The .pdf files are now fixed in the jmp/contribution/
They had been truncated:
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r-- 1 pwg pwg 89653 Jun 4 18:33 jobstate.pdf
-rw-r--r-- 1 pwg pwg 42819 Jun 4 12:29 jobstate.txt
-rw-r--r-- 1 pwg pwg 113132 Jun 4 12:30 jobstatr.doc
-rw-r--r-- 1 pwg pwg 143298 Jun 4 18:33 jobstatr.pdf
-rw-r--r-- 1 pwg pwg 148621 Jun 4 18:33 jobstatr.pdr
The ones in ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/
were ok as posted
Sorry for the problems.
Tom
>Return-Path: <jkm at uscore.underscore.com>
>Date: Wed, 4 Jun 1997 11:04:50 PDT
>From: JK Martin <jkm at underscore.com>
>To: hastings at cp10.es.xerox.com>Subject: Re: JMP> 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
>X-Sun-Charset: US-ASCII
>>Tom,
>>You've got some problems with a couple of your uploaded files:
>> jobstate.pdf -- Is empty
> jobstatr.pdf -- Is either truncated or otherwise is bad for Acrobat
>> ...jay
>>----- Begin Included Message -----
>>>From jmp-owner at pwg.org Wed Jun 4 09:00 EDT 1997
>Date: Wed, 4 Jun 1997 05:53:39 PDT
>To: jmp at pwg.org, ipp at pwg.org>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: JMP> 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.
>>>>>----- End Included Message -----
>>>>