Subject: IPP> 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

From: Tom Hastings <[email-masked]>
Date: Wed, 4 Jun 1997 11:35:58 PDT

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: <[email-masked]>
>Date: Wed, 4 Jun 1997 11:04:50 PDT
>From: JK Martin <[email-masked]>
>To: [email-masked]
>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 [email-masked] Wed Jun  4 09:00 EDT 1997
>Date: Wed, 4 Jun 1997 05:53:39 PDT
>To: [email-masked], [email-masked]
>From: Tom Hastings <[email-masked]>
>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 -----
>
>
>
>