Agenda for job-state and job-state-reasons part of today's telecon.
1. Is the updated text for IPP and JMP ok?
2. Names of the state agreed? (not exactly as in the minutes)?
(can we just simplify the names to the last word in the hyphendated names?)
3. in-coming and out-going issue
4. any other problems with the rest of the specification sent out for
the 6/4 telecon: jobstate.pdf.
Here is Scott's complete agenda:
Friday June 6
2:00 pm - 4:00 pm Mountain
800-600-5302
code: 346463
Agenda:
1. Job State and Job State Reasons
2. Presentation of attributes in the Model document
- separate doc?
- lists of keyword values
3. Run through the remaining issues in the document
Scott Isaacson
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?
Do we agree on the following state transition diagrams:
The corresponding IPP text will be:
6.3.2.5 job-state (type1 keyword)
This attribute identifies the current state of the job.
The Printer may provide additional information about each state value by
supplying one or more values of the job's companion "job-state-reasons"
attribute depending on implementation. While the job states cannot be added
to without impacting deployed clients that take actions upon receiving job
state values, it is the intent that additional "job-state-reasons" values
can be defined without impacting such deployed clients. In other words, the
"job-state-reasons" attribute is intended to be extensible.
Standard values are:
unknown The job state is not known, or its state is indeterminate.
pending The job is a candidate to start processing, but is not yet processing.
pending-held The job is not a candidate for processing for any number of
reasons and will resume pending as soon as the reasons are no longer
present. The job's "job-state-reason" attribute shall indicate why the job
is no longer a candidate for processing.
processing Either:1. the job is using, or is attempting to use, one or
more document transforms which include (1) purely software processes that
are interpreting a PDL, and (2) hardware devices that are interpreting a
PDL, making marks on a medium, and/or performing finishing, such as stapling
OR 2. the server has made the job ready for printing, but the output device
is not yet printing it, either because the job hasn't reached the output
device or because the job is queued in the output device or some other
spooler, awaiting the output device to print it.
ISSUE: The "job-state-reasons" specification is that the job is in 'pending'
state not 'processing' state.When the job is in the 'processing' state, the
entire job state includes the detailed status represented in the printer's
"printer-state", "printer-state-reasons", and "printer-state-message
attributes.Implementations may include additional values in the job's
"job-state-reasons" attribute to indicate the progress of the job, such as
adding the 'job-printing' value to indicate when the output device is
actually making marks on paper. Most implementations won't bother with this
nuance.
processing-stopped The job has stopped while processing for any number of
reasons and will continue processing as soon as the reasons are no longer
present. The job's "job-state-reason" attribute shall indicate why the job
has stopped processing.If the output device is stopped, the
'printer-stopped' value shall be included in the job's "job-state-reasons"
attribute. When the output device is stopped, the device usually indicates
its condition in human readable form locally at the device. A client can
obtain more complete device status remotely by querying the printer's
"printer-state-reasons" attribute.
canceled The job has been canceled by a Cancel-Job operation and is either
(1) in the process of terminating or (2) has completed terminating. The
job's "job-state-reasons" attribute shall contain either the
'canceled-by-user' or 'canceled-by-operator' value.
aborted The job has been aborted by the system, usually while the job was in
the 'processing' state.
completed The job has completed successfully or with warnings or errors and
all of the job media sheets have been properly stacked in the appropriate
output tray or bin. The job's "job-state-reasons" attribute shall contain
one of: 'completed-successfully', 'completed-with-warnings', or
'completed-with-errors'.
The length of time that jobs remain in the 'canceled', 'aborted', and
'completed' states depends on implementation.
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 through three states.
Even though the IPP protocol defines seven values for job states, Printers
SHALL only implement those states which are appropriate for the particular
implementation.
For JMP:
JmJobStateTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The current state of the job (pending, processing, completed, etc.).
The following figure shows the normal job state transitions:
+--> canceled(7)
/
+---> pending(3) --------> processing(5) -----+----> completed(9)
| ^ ^ \
--->+ | | +--> aborted(8)
| v v /
+---> pendingHeld(4) processingStopped(6) --+
<-------------- active -----------------> <-- in-active -->
Figure 4 - Normal Job State Transitions
Normally a job progresses only from left to right. Other state transitions
are unlikely, but are not forbidden. The canceled state can be entered from
the pending, pendingHeld, processing, or processingStopped states."
-- This is a type 2 enumeration. See Section 7.1 on page 25.
SYNTAX INTEGER {
other(1),
-- The job state is not one of the defined states.
unknown(2),
---- The job state is not known, or its state is indeterminate.
pending(3),
---- The job is waiting to start processing, but is not yet processing.
pendingHeld(4),
---------------------- The job is not yet a candidate for processing for
any number of reasons and will resume pending as soon as the reasons are no
longer present. The reasons are represented as bits in the jobStateReasons1
object and/or jobStateReasonsn (n=2..4) attribute. Some reasons are used in
other states to give added information about the job state. See the
JmJobStateReasonsnTC (n=1..4) textual convention for the specification of
each reason and in which states the reasons are intended to be used.
processing(4), --
--------------------------------------------------------------------
Either: 1. The job is using, or is attempting to use, one or more document
transforms which include (1) purely software processes that are interpreting
a PDL, and (2) hardware devices that are interpreting a PDL, making marks on
a medium, and/or performing finishing, such as stapling OR2. (configuration
2) the server has made the job ready for printing, but the output device is
not yet printing it, either because the job hasn't reached the output device
or because the job is queued in the output device or some other spooler,
awaiting the output device to print it.
ISSUE: The definitions of job-outgoing say that the job state is 'pending',
not 'processing'. Can we remove paragraph 2 about from the definition of
the 'processing' state?When the job is in the processing state, the entire
job state includes the detailed status represented in the device MIB
indicated by the hrDeviceIndex value of the job's physicalDevice
attribute.Implementations MAY, though they NEED NOT, include additional
values in the job's jmJobStateReasons1 object to indicate the progress of
the job, such as adding the jobPrinting value to indicate when the device is
actually making marks on paper.
processingStopped(7), --
------------------------------------ The job has stopped while processing
for any number of reasons and will continue processing as soon as the
reasons are no longer present. The job's jmJobStateReasons1 object and/or
the job's jobStateReasonsn (n=2..4) attributes SHOULD indicate why the job
has stopped processing. For example, if the output device is stopped, the
deviceStopped value SHOULD be included in the job's jmJobStateReasons1
object. NOTE - When an output device is stopped, the device usually
indicate its condition in human readable form locally at the device. The
management application can obtain more complete device status remotely by
querying the appropriate device MIB using the job's deviceIndex attribute(s).
canceled(5), --
------------ The job is in the process of being terminated by the server or
device or has completed terminating the job, because a client canceled the
job. The job's jobStateReasons1 attribute SHOULD contain either the
canceledByUser or canceledByOperator value.
aborted(6) --
---- The job has been aborted by the system, usually while the job was in
the processing state.
completed(7) --
------------ The job has completed successfully or with warnings or errors
after processing and all of the media have been successfully stacked in the
output bin(s). The job's jobStateReasons1 attribute SHOULD contain one of:
completedSuccessfully, completedWithWarnings, or completedWithErrors.
}