Internet RFC/STD/FYI/BCP Archives
Alternate Formats: rfc2707.txt | rfc2707.txt.pdf
Network Working Group R. Bergman
Request for Comments: 2707 Dataproducts Corp.
Category: Informational T. Hastings, Ed.
Xerox Corporation
S. Isaacson
Novell, Inc.
H. Lewis
IBM Corp.
November 1999
Job Monitoring MIB - V1.0
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
IESG Note
This MIB module uses an unconventional scheme for modeling management
information (on top of the SNMP model) which is unique to this MIB.
The IESG recommends against using this document as an example for the
design of future MIBs.
The "Printer Working Group" industry consortium is not an IETF
working group, and the IETF does not recognize the Printer Working
Group as a standards-setting body. This document is being published
solely to provide information to the Internet community regarding a
MIB that might be deployed in the marketplace. Publication of this
document as an RFC is not an endorsement of this MIB.
Abstract
This document provides a printer industry standard SNMP MIB for (1)
monitoring the status and progress of print jobs (2) obtaining
resource requirements before a job is processed, (3) monitoring
resource consumption while a job is being processed and (4)
collecting resource accounting data after the completion of a job.
This MIB is intended to be implemented (1) in a printer or (2) in a
server that supports one or more printers. Use of the object set is
not limited to printing. However, support for services other than
printing is outside the scope of this Job Monitoring MIB. Future
extensions to this MIB may include, but are not limited to, fax
machines and scanners.
Table of Contents
1 INTRODUCTION 4
1.1 Types of Information in the MIB 5
1.2 Types of Job Monitoring Applications 6
2 TERMINOLOGY AND JOB MODEL 7
2.1 System Configurations for the Job Monitoring MIB 11
2.1.1 Configuration 1 - client-printer 11
2.1.2 Configuration 2 - client-server-printer - agent in the
server 12
2.1.3 Configuration 3 - client-server-printer - client
monitors printer agent and server 14
3 MANAGED OBJECT USAGE 15
3.1 Conformance Considerations 15
3.1.1 Conformance Terminology 16
3.1.2 Agent Conformance Requirements 16
3.1.2.1 MIB II System Group objects 17
3.1.2.2 MIB II Interface Group objects 17
3.1.2.3 Printer MIB objects 17
3.1.3 Job Monitoring Application Conformance Requirements 17
3.2 The Job Tables and the Oldest Active and Newest Active
Indexes 18
3.3 The Attribute Mechanism and the Attribute Table(s) 20
3.3.1 Conformance of Attribute Implementation 21
3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and
Attributes 21
3.3.3 Index Value Attributes 22
3.3.4 Data Sub-types and Attribute Naming Conventions 22
3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW)
Attributes 23
3.3.6 Requested Objects and Attributes 23
3.3.7 Consumption Attributes 24
3.3.8 Attribute Specifications 24
3.3.9 Job State Reason bit definitions 43
3.3.9.1 JmJobStateReasons1TC specification 44
3.3.9.2 JmJobStateReasons2TC specification 47
3.3.9.3 JmJobStateReasons3TC specification 51
3.3.9.4 JmJobStateReasons4TC specification 51
3.4 Monitoring Job Progress 51
3.5 Job Identification 55
3.5.1 The Job Submission ID specifications 56
3.6 Internationalization Considerations 60
3.6.1 Text generated by the server or device 61
3.6.2 Text supplied by the job submitter 61
3.6.3 'DateAndTime' for representing the date and time 63
3.7 IANA and PWG Registration Considerations 63
3.7.1 PWG Registration of enums 63
3.7.1.1 Type 1 enumerations 64
3.7.1.2 Type 2 enumerations 64
3.7.1.3 Type 3 enumeration 64
3.7.2 PWG Registration of type 2 bit values 65
3.7.3 PWG Registration of Job Submission Id Formats 65
3.7.4 PWG Registration of MIME types/sub-types for document-
formats 65
3.8 Security Considerations 65
3.8.1 Read-Write objects 65
3.8.2 Read-Only Objects In Other User's Jobs 66
3.9 Notifications 66
4 MIB SPECIFICATION 67
Textual conventions for this MIB module 68
JmUTF8StringTC 68
JmJobStringTC 68
JmNaturalLanguageTagTC 68
JmTimeStampTC 69
JmJobSourcePlatformTypeTC 69
JmFinishingTC 70
JmPrintQualityTC 71
JmPrinterResolutionTC 71
JmTonerEconomyTC 72
JmBooleanTC 72
JmMediumTypeTC 72
JmJobCollationTypeTC 74
JmJobSubmissionIDTypeTC 74
JmJobStateTC 75
JmAttributeTypeTC 78
JmJobServiceTypesTC 81
JmJobStateReasons1TC 83
JmJobStateReasons2TC 83
JmJobStateReasons3TC 83
JmJobStateReasons4TC 84
The General Group (MANDATORY) 84
jmGeneralJobSetIndex (Int32(1..32767)) 85
jmGeneralNumberOfActiveJobs (Int32(0..)) 86
jmGeneralOldestActiveJobIndex (Int32(0..)) 86
jmGeneralNewestActiveJobIndex (Int32(0..)) 86
jmGeneralJobPersistence (Int32(15..)) 87
jmGeneralAttributePersistence (Int32(15..)) 87
jmGeneralJobSetName (UTF8String63) 88
The Job ID Group (MANDATORY) 88
jmJobSubmissionID (OCTET STRING(SIZE(48))) 89
jmJobIDJobSetIndex (Int32(0..32767)) 90
jmJobIDJobIndex (Int32(0..)) 91
The Job Group (MANDATORY) 91
jmJobIndex (Int32(1..)) 92
jmJobState (JmJobStateTC) 92
jmJobStateReasons1 (JmJobStateReasons1TC) 93
jmNumberOfInterveningJobs (Int32(-2..)) 93
jmJobKOctetsPerCopyRequested (Int32(-2..)) 94
jmJobKOctetsProcessed (Int32(-2..)) 94
jmJobImpressionsPerCopyRequested (Int32(-2..)) 95
jmJobImpressionsCompleted (Int32(-2..)) 96
jmJobOwner (JobString63) 96
The Attribute Group (MANDATORY) 97
jmAttributeTypeIndex (JmAttributeTypeTC) 98
jmAttributeInstanceIndex (Int32(1..32767)) 99
jmAttributeValueAsInteger (Int32(-2..)) 99
jmAttributeValueAsOctets (Octets63) 100
5 APPENDIX A - IMPLEMENTING THE JOB LIFE CYCLE 104
6 APPENDIX B - SUPPORT OF JOB SUBMISSION PROTOCOLS 105
7 REFERENCES 105
8 NOTICES 108
9 AUTHORS' ADDRESSES 109
10 INDEX 111
11 Full Copyright Statement 114
1 Introduction
This specification defines an official Printer Working Group (PWG)
[PWG] standard SNMP MIB for the monitoring of jobs on network
printers. This specification is being published as an IETF
Information Document for the convenience of the Internet community.
In consultation with the IETF Application Area Directors, it was
concluded that this MIB specification properly belongs as an
Information document, because this MIB monitors a service node on the
network, rather than a network node proper.
The Job Monitoring MIB is intended to be implemented by an agent
within a printer or the first server closest to the printer, where
the printer is either directly connected to the server only or the
printer does not contain the job monitoring MIB agent. It is
recommended that implementations place the SNMP agent as close as
possible to the processing of the print job. This MIB applies to
printers with and without spooling capabilities. This MIB is
designed to be compatible with most current commonly-used job
submission protocols. In most environments that support high
function job submission/job control protocols, like ISO DPA [iso-
dpa], those protocols would be used to monitor and manage print jobs
rather than using the Job Monitoring MIB.
The Job Monitoring MIB consists of a General Group, a Job Submission
ID Group, a Job Group, and an Attribute Group. Each group is a
table. All accessible objects are read-only. The General Group
contains general information that applies to all jobs in a job set.
The Job Submission ID table maps the job submission ID that the
client uses to identify a job to the jmJobIndex that the Job
Monitoring Agent uses to identify jobs in the Job and Attribute
tables. The Job table contains the MANDATORY integer job state and
status objects. The Attribute table consists of multiple entries per
job that specify (1) job and document identification and parameters,
(2) requested resources, and (3) consumed resources during and after
job processing/printing. A larger number of job attributes are
defined as textual conventions that an agent SHALL return if the
server or device implements the functionality so represented and the
agent has access to the information.
1.1 Types of Information in the MIB
The job MIB is intended to provide the following information for the
indicated Role Models in the Printer MIB [print-mib] (Appendix D -
Roles of Users).
User:
Provide the ability to identify the least busy printer. The
user will be able to determine the number and size of jobs
waiting for each printer. No attempt is made to actually
predict the length of time that jobs will take.
Provide the ability to identify the current status of the
user's job (user queries).
Provide a timely indication that the job has completed and
where it can be found.
Provide error and diagnostic information for jobs that did not
successfully complete.
Operator:
Provide a presentation of the state of all the jobs in the
print system.
Provide the ability to identify the user that submitted the
print job.
Provide the ability to identify the resources required by each
job.
Provide the ability to define which physical printers are
candidates for the print job.
Provide some idea of how long each job will take. However,
exact estimates of time to process a job is not being
attempted. Instead, objects are included that allow the
operator to be able to make gross estimates.
Capacity Planner:
Provide the ability to determine printer utilization as a
function of time.
Provide the ability to determine how long jobs wait before
starting to print.
Accountant:
Provide information to allow the creation of a record of
resources consumed and printer usage data for charging users or
groups for resources consumed.
Provide information to allow the prediction of consumable usage
and resource need.
The MIB supports printers that can contain more than one job at a
time, but still be usable for low end printers that only contain a
single job at a time. In particular, the MIB supports the needs of
Windows and other PC environments for managing low-end direct-connect
(serial or parallel) and networked devices without unnecessary
overhead or complexity, while also providing for higher end systems
and devices.
1.2 Types of Job Monitoring Applications
The Job Monitoring MIB is designed for the following types of
monitoring applications:
1. Monitor a single job starting when the job is submitted and
ending a defined period after the job completes. The Job
Submission ID table provides the map to find the specific job
to be monitored.
2. Monitor all 'active' jobs in a queue, which this
specification generalizes to a "job set". End users may use
such a program when selecting a least busy printer, so the
MIB is designed for such a program to start up quickly and
find the information needed quickly without having to read
all (completed) jobs in order to find the active jobs.
System operators may also use such a program, in which case
it would be running for a long period of time and may also be
interested in the jobs that have completed. Finally such a
program may be used to provide an enhanced console and
logging capability.
3. Collect resource usage for accounting or system utilization
purposes that copy the completed job statistics to an
accounting system. It is recognized that depending on
accounting programs to copy MIB data during the job-retention
period is somewhat unreliable, since the accounting program
may not be running (or may have crashed). Such a program is
also expected to keep a shadow copy of the entire Job
Attribute table including completed, canceled, and aborted
jobs which the program updates on each polling cycle. Such a
program polls at the rate of the persistence of the Attribute
table. The design is not optimized to help such an
application determine which jobs are completed, canceled, or
aborted. Instead, the application SHOULD query each job that
the application's shadow copy shows was not complete,
canceled, or aborted at the previous poll cycle to see if it
is now complete or canceled, plus any new jobs that have been
submitted.
The MIB provides a set of objects that represent a compatible subset
of job and document attributes of the ISO DPA standard [iso-dpa] and
the Internet Printing Protocol (IPP) [ipp-model], so that coherence
is maintained between these two protocols and the information
presented to end users and system operators by monitoring
applications. However, the job monitoring MIB is intended to be used
with printers that implement other job submitting and management
protocols, such as IEEE 1284.1 (TIPSI) [tipsi], as well as with ones
that do implement ISO DPA. Thus the job monitoring MIB does not
require implementation of either the ISO DPA or IPP protocols.
The MIB is designed so that an additional MIB(s) can be specified in
the future for monitoring multi-function (scan, FAX, copy) jobs as an
augmentation to this MIB.
2 Terminology and Job Model
This section defines the terms that are used in this specification
and the general model for jobs in alphabetical order.
NOTE - Existing systems use conflicting terms, so these terms are
drawn from the ISO 10175 Document Printing Application (DPA)
standard [iso-dpa]. For example, PostScript systems use the term
session for what is called a job in this specification and the
term job to mean what is called a document in this specification.
Accounting Application: The SNMP management application that copies
job information to some more permanent medium so that another
application can perform accounting on the data for Accountants, Asset
Managers, and Capacity Planners use.
Agent: The network entity that accepts SNMP requests from a monitor
or accounting application and provides access to the instrumentation
for managing jobs modeled by the management objects defined in the
Job Monitoring MIB module for a server or a device.
Attribute: A name, value-pair that specifies a job or document
instruction, a status, or a condition of a job or a document that has
been submitted to a server or device. A particular attribute NEED
NOT be present in each job instance. In other words, attributes are
present in a job instance only when there is a need to express the
value, either because (1) the client supplied a value in the job
submission protocol, (2) the document data contained an embedded
attribute, or (3) the server or device supplied a default value. An
agent MAY represent an attribute as an entry (row) in the Attribute
table in this MIB in which entries are present only when necessary.
Attributes are identified in this MIB by an enum.
Client: The network entity that end users use to submit jobs to
spoolers, servers, or printers and other devices, depending on the
configuration, using any job submission protocol over a serial or
parallel port to a directly-connected device or over the network to a
networked-connected device.
Device: A hardware entity that (1) interfaces to humans, such as a
device that produces marks on paper or scans marks on paper to
produce an electronic representation, (2) accesses digital media,
such as CD-ROMs, or (3) interfaces electronically to another device,
such as sends FAX data to another FAX device.
Document: A sub-section within a job that contains print data and
document instructions that apply to just the document.
Document Instruction: An instruction specifying how to process the
document. Document instructions MAY be passed in the job submission
protocol separate from the actual document data, or MAY be embedded
in the document data or a combination, depending on the job
submission protocol and implementation.
End User: A user that uses a client to submit a print job. See
"user".
Impression: For a print job, an impression is the passage of the
entire side of a sheet by the marker, whether or not any marks are
made and independent of the number of passes that the side makes past
the marker. Thus a four pass color process counts as a single
impression, as does highlight color. Impression counters count all
kinds: monochrome, highlight color, and full process color, while
full color counters only count full color impressions, and high light
color counters only count high light color impressions.
One-sided processing involves one impression per sheet. Two-sided
processing involves two impressions per sheet. If a two-sided
document has an odd number of pages, the last sheet still counts as
two impressions, if that sheet makes two passes through the marker or
the marker marks on both sides of a sheet in a single pass. Two-up
printing is the placement of two logical pages on one side of a sheet
and so is still a single impression. See "page" and "sheet".
NOTE - Since impressions include blank sides, it is suggested that
accounting application implementers consider charging for sheets,
rather than impressions, possibly using the value of the sides
attribute to select different charges for one-sided versus two-sided
printing, since some users may think that impressions don't include
blank sides.
Internal Collation: The production of the sheets for each document
copy performed within the printing device by making multiple passes
over either the source or an intermediate representation of the
document.
Job: A unit of work whose results are expected together without
interjection of unrelated results. A job contains one or more
documents.
Job Accounting: The activity of a management application of
accessing the MIB and recording what happens to the job during and
after the processing of the job.
Job Instruction: An instruction specifying how, when, or where the
job is to be processed. Job instructions MAY be passed in the job
submission protocol or MAY be embedded in the document data or a
combination depending on the job submission protocol and
implementation.
Job Monitoring (using SNMP): The activity of a management
application of accessing the MIB and (1) identifying jobs in the job
tables being processed by the server, printer or other devices, and
(2) displaying information to the user about the processing of the
job.
Job Monitoring Application: The SNMP management application that End
Users, and System Operators use to monitor jobs using SNMP. A
monitor MAY be either a separate application or MAY be part of the
client that also submits jobs. See "monitor".
Job Set: A group of jobs that are queued and scheduled together
according to a specified scheduling algorithm for a specified device
or set of devices. For implementations that embed the SNMP agent in
the device, the MIB job set normally represents all the jobs known to
the device, so that the implementation only implements a single job
set. If the SNMP agent is implemented in a server that controls one
or more devices, each MIB job set represents a job queue for (1) a
specific device or (2) set of devices, if the server uses a single
queue to load balance between several devices. Each job set is
disjoint; no job SHALL be represented in more than one MIB job set.
Monitor: Short for Job Monitoring Application.
Page: A page is a logical division of the original source document.
Number up is the imposition of more than one page on a single side of
a sheet. See "impression" and "sheet" and "two-up".
Proxy: An agent that acts as a concentrator for one or more other
agents by accepting SNMP operations on the behalf of one or more
other agents, forwarding them on to those other agents, gathering
responses from those other agents and returning them to the original
requesting monitor.
Queuing: The act of a device or server of ordering (queuing) the
jobs for the purposes of scheduling the jobs to be processed.
Printer: A device that puts marks on media.
Server: A network entity that accepts jobs from clients and in turn
submits the jobs to printers and other devices that may be directly
connected to the server via a serial or parallel port or may be on
the network. A server MAY be a printer supervisor control program,
or a print spooler.
Sheet: A sheet is a single instance of a medium, whether printing on
one or both sides of the medium. See "impression" and "page".
SNMP Information Object: A name, value-pair that specifies an
action, a status, or a condition in an SNMP MIB. Objects are
identified in SNMP by an OBJECT IDENTIFIER.
Spooler: A server that accepts jobs, spools the data, and decides
when and on which printer to print the job. A spooler is a client to
a printer or a printer supervisor, depending on implementation.
Spooling: The act of a device or server of (1) accepting jobs and
(2) writing the job's attributes and document data on to secondary
storage.
Stacked: When a media sheet is placed in an output bin of a device.
Supervisor: A server that contains a control program that controls a
printer or other device. A supervisor is a client to the printer or
other device.
System Operator: A user that uses a monitor to monitor the system
and carries out tasks to keep the system running.
System Administrator: A user that specifies policy for the system.
Two-up: The placement of two pages on one side of a sheet so that
each side or impressions counts as two pages. See "page" and
"sheet".
User: A person that uses a client or a monitor. See "end user".
2.1 System Configurations for the Job Monitoring MIB
This section enumerates the three configurations in which the Job
Monitoring MIB is intended to be used. To simplify the pictures, the
devices are shown as printers. See section 1.1 entitled "Types of
Information in the MIB".
The diagram in the Printer MIB [print-mib] entitled: "One Printer's
View of the Network" is assumed for this MIB as well. Please refer
to that diagram to aid in understanding the following system
configurations.
2.1.1 Configuration 1 - client-printer
In the client-printer configuration 1, the client(s) submit jobs
directly to the printer, either by some direct connect, or by network
connection.
The job submitting client and/or monitoring application monitor jobs
by communicating directly with an agent that is part of the printer.
The agent in the printer SHALL keep the job in the Job Monitoring MIB
as long as the job is in the printer, plus a defined time period
after the job enters the completed state in which accounting programs
can copy out the accounting data from the Job Monitoring MIB.
all end-user ######## SNMP query
+-------+ +--------+ ---- job submission
|monitor| | client |
+---#---+ +--#--+--+
# # |
# ############ |
# # |
+==+===#=#=+==+ |
| | agent | | |
| +-------+ | |
| PRINTER <--------+
| | Print Job Delivery Channel
| |
+=============+
Figure 2-1 - Configuration 1 - client-printer - agent in the printer
The Job Monitoring MIB is designed to support the following
relationships (not shown in Figure 2-1):
1. Multiple clients MAY submit jobs to a printer.
2. Multiple clients MAY monitor a printer.
3. Multiple monitors MAY monitor a printer.
4. A client MAY submit jobs to multiple printers.
5. A monitor MAY monitor multiple printers.
2.1.2 Configuration 2 - client-server-printer - agent in the server
In the client-server-printer configuration 2, the client(s) submit
jobs to an intermediate server by some network connection, not
directly to the printer. While configuration 2 is included, the
design center for this MIB is configurations 1 and 3.
The job submitting client and/or monitoring application monitor jobs
by communicating directly with:
A Job Monitoring MIB agent that is part of the server (or a front
for the server)
There is no SNMP Job Monitoring MIB agent in the printer in
configuration 2, at least that the client or monitor are aware. In
this configuration, the agent SHALL return the current values of the
objects in the Job Monitoring MIB both for jobs the server keeps and
jobs that the server has submitted to the printer. The Job
Monitoring MIB agent obtains the required information from the
printer by a method that is beyond the scope of this document. The
agent in the server SHALL keep the job in the Job Monitoring MIB in
the server as long as the job is in the printer, plus a defined time
period after the job enters the completed state in which accounting
programs can copy out the accounting data from the Job Monitoring
MIB.
all end-user
+-------+ +----------+
|monitor| | client | ######## SNMP query
+---+---# +---#----+-+ **** non-SNMP cntrl
# # | ---- job submission
# # |
# # |
#=====#=+==v==+
| agent | |
+-------+ |
| server |
+----+-----+--+
control * |
********** |
* |
+========v====+ |
| | |
| | |
| PRINTER <---------+
| | Print Job Delivery Channel
| |
+=============+
Figure 2-2 - Configuration 2 - client-server-printer - agent in the
server
The Job Monitoring MIB is designed to support the following
relationships (not shown in Figure 2-2):
1. Multiple clients MAY submit jobs to a server.
2. Multiple clients MAY monitor a server.
3. Multiple monitors MAY monitor a server.
4. A client MAY submit jobs to multiple servers.
5. A monitor MAY monitor multiple servers.
6. Multiple servers MAY submit jobs to a printer.
7. Multiple servers MAY control a printer.
2.1.3 Configuration 3 - client-server-printer - client monitors printer
agent and server
In the client-server-printer configuration 3, the client(s) submit
jobs to an intermediate server by some network connection, not
directly to the printer. That server does not contain a Job
Monitoring MIB agent.
The job submitting client and/or monitoring application monitor jobs
by communicating directly with:
1. The server using some undefined protocol to monitor jobs in
the server (that does not contain the Job Monitoring MIB) AND
2. A Job Monitoring MIB agent that is part of the printer to
monitor jobs after the server passes the jobs to the printer.
In such configurations, the server deletes its copy of the
job from the server after submitting the job to the printer
usually almost immediately (before the job does much
processing, if any).
In configuration 3, the agent (in the printer) SHALL keep the values
of the objects in the Job Monitoring MIB that the agent implements
updated for a job that the server has submitted to the printer. The
agent SHALL obtain information about the jobs submitted to the
printer from the server (either in the job submission protocol, in
the document data, or by direct query of the server), in order to
populate some of the objects the Job Monitoring MIB in the printer.
The agent in the printer SHALL keep the job in the Job Monitoring MIB
as long as the job is in the Printer, and longer in order to
implement the completed state in which monitoring programs can copy
out the accounting data from the Job Monitoring MIB.
all end-user
+-------+ +----------+
|monitor| | client | ######## SNMP query
+---+---* +---*----+-+ **** non-SNMP query
# * * | ---- job submission
# * * |
# * * |
# *=====v====v==+
# | |
# | server |
# | |
# +----#-----+--+
# optional# |
# ########## |
# # |
+==+=v===v=+==+ |
| | agent | | |
| +-------+ | |
| PRINTER <---------+
| | Print Job Delivery Channel
| |
+=============+
Figure 2-3 - Configuration 3 - client-server-printer - client
monitors printer agent and server
The Job Monitoring MIB is designed to support the following
relationships (not shown in Figure 2-3):
1. Multiple clients MAY submit jobs to a server.
2. Multiple clients MAY monitor a server.
3. Multiple monitors MAY monitor a server.
4. A client MAY submit jobs to multiple servers.
5. A monitor MAY monitor multiple servers.
6. Multiple servers MAY submit jobs to a printer.
7. Multiple servers MAY control a printer.
3 Managed Object Usage
This section describes the usage of the objects in the MIB.
3.1 Conformance Considerations
In order to achieve interoperability between job monitoring
applications and job monitoring agents, this specification includes
the conformance requirements for both monitoring applications and
agents.
3.1.1 Conformance Terminology
This specification uses the verbs: "SHALL", "SHOULD", "MAY", and
"NEED NOT" to specify conformance requirements according to RFC 2119
[RFC2119] as follows:
"SHALL": indicates an action that the subject of the sentence
must implement in order to claim conformance to this specification
"MAY": indicates an action that the subject of the sentence does
not have to implement in order to claim conformance to this
specification, in other words that action is an implementation
option
"NEED NOT": indicates an action that the subject of the sentence
does not have to implement in order to claim conformance to this
specification. The verb "NEED NOT" is used instead of "may not",
since "may not" sounds like a prohibition.
"SHOULD": indicates an action that is recommended for the subject
of the sentence to implement, but is not required, in order to
claim conformance to this specification.
3.1.2 Agent Conformance Requirements
A conforming agent:
1. SHALL implement all MANDATORY groups in this specification.
2. SHALL implement any attributes if (1) the server or device
supports the functionality represented by the attribute and (2)
the information is available to the agent.
3. SHOULD implement both forms of an attribute if it implements an
attribute that permits a choice of INTEGER and OCTET STRING
forms, since implementing both forms may help management
applications by giving them a choice of representations, since
the representation are equivalent. See the JmAttributeTypeTC
textual-convention.
NOTE - This MIB, like the Printer MIB, is written following the
subset of SMIv2 that can be supported by SMIv1 and SNMPv1
implementations.
3.1.2.1 MIB II System Group objects
The Job Monitoring MIB agent SHALL implement all objects in the
System Group of MIB-II [mib-II], whether the Printer MIB [print-mib]
is implemented or not.
3.1.2.2 MIB II Interface Group objects
The Job Monitoring MIB agent SHALL implement all objects in the
Interfaces Group of MIB-II [mib-II], whether the Printer MIB [print-
mib] is implemented or not.
3.1.2.3 Printer MIB objects
If the agent is providing access to a device that is a printer, the
agent SHALL implement all of the MANDATORY objects in the Printer MIB
[print-mib] and all the objects in other MIBs that conformance to the
Printer MIB requires, such as the Host Resources MIB [hr-mib]. If
the agent is providing access to a server that controls one or more
direct-connect or networked printers, the agent NEED NOT implement
the Printer MIB and NEED NOT implement the Host Resources MIB.
3.1.3 Job Monitoring Application Conformance Requirements
A conforming job monitoring application:
1. SHALL accept the full syntactic range for all objects in all
MANDATORY groups and all MANDATORY attributes that are
required to be implemented by an agent according to Section
3.1.2 and SHALL either present them to the user or ignore
them.
2. SHALL accept the full syntactic range for all attributes,
including enum and bit values specified in this specification
and additional ones that may be registered with the PWG and
SHALL either present them to the user or ignore them. In
particular, a conforming job monitoring application SHALL not
malfunction when receiving any standard or registered enum or
bit values. See Section 3.7 entitled "IANA and PWG
Registration Considerations".
3. SHALL NOT fail when operating with agents that materialize
attributes after the job has been submitted, as opposed to
when the job is submitted.
4. SHALL, if it supports a time attribute, accept either form of
the time attribute, since agents are free to implement either
time form.
3.2 The Job Tables and the Oldest Active and Newest Active Indexes
The jmJobTable and jmAttributeTable contain objects and attributes,
respectively, for each job in a job set. These first two indexes
are:
1. jmGeneralJobSetIndex - which job set
2. jmJobIndex - which job in the job set
In order for a monitoring application to quickly find that active
jobs (jobs in the pending, processing, or processingStopped states),
the MIB contains two indexes:
1. jmGeneralOldestActiveJobIndex - the index of the active job
that has been in the tables the longest.
2. jmGeneralNewestActiveJobIndex - the index of the active job
that has been most recently added to the tables.
The agent SHALL assign the next incremental value of jmJobIndex to
the job, when a new job is accepted by the server or device to which
the agent is providing access. If the incremented value of
jmJobIndex would exceed the implementation-defined maximum value for
jmJobIndex, the agent SHALL 'wrap' back to 1. An agent uses the
resulting value of jmJobIndex for storing information in the
jmJobTable and the jmAttributeTable about the job.
It is recommended that the largest value for jmJobIndex be much
larger than the maximum number of jobs that the implementation can
contain at a single time, so as to minimize the premature re-use of a
jmJobIndex value for a newer job while clients retain the same '
stale' value for an older job.
It is recommended that agents that are providing access to
servers/devices that already allocate job-identifiers for jobs as
integers use the same integer value for the jmJobIndex. Then
management applications using this MIB and applications using other
protocols will see the same job identifiers for the same jobs.
Agents providing access to systems that contain jobs with a job
identifier of 0 SHALL map the job identifier value 0 to a jmJobIndex
value that is one higher than the highest job identifier value that
any job can have on that system. Then only job 0 will have a
different job-identifier value than the job's jmJobIndex value.
NOTE - If a server or device accepts jobs using multiple job
submission protocols, it may be difficult for the agent to meet the
recommendation to use the job-identifier values that the server or
device assigns as the jmJobIndex value, unless the server/device
assigns job-identifiers for each of its job submission protocols from
the same job-identifier number space.
Each time a new job is accepted by the server or device that the
agent is providing access to AND that job is to be 'active' (pending,
processing, or processingStopped, but not pendingHeld), the agent
SHALL copy the value of the job's jmJobIndex to the
jmGeneralNewestActiveJobIndex object. If the new job is to be '
inactive' (pendingHeld state), the agent SHALL not change the value
of jmGeneralNewestActiveJobIndex object (though the agent SHALL
assign the next incremental jmJobIndex value to the job).
When a job transitions from one of the 'active' job states (pending,
processing, processingStopped) to one of the 'inactive' job states
(pendingHeld, completed, canceled, or aborted), with a jmJobIndex
value that matches the jmGeneralOldestActiveJobIndex object, the
agent SHALL advance (or wrap) the value to the next oldest 'active'
job, if any. See the JmJobStateTC textual-convention for a
definition of the job states.
Whenever a job transitions from one of the 'inactive' job states to
one of the 'active' job states (from pendingHeld to pending or
processing), the agent SHALL update the value of either the
jmGeneralOldestActiveJobIndex or the jmGeneralNewestActiveJobIndex
objects, or both, if the job's jmJobIndex value is outside the range
between jmGeneralOldestActiveJobIndex and
jmGeneralNewestActiveJobIndex.
When all jobs become 'inactive', i.e., enter the pendingHeld,
completed, canceled, or aborted states, the agent SHALL set the value
of both the jmGeneralOldestActiveJobIndex and
jmGeneralNewestActiveJobIndex objects to 0.
NOTE - Applications that wish to efficiently access all of the active
jobs MAY use jmGeneralOldestActiveJobIndex value to start with the
oldest active job and continue until they reach the index value equal
to jmGeneralNewestActiveJobIndex, skipping over any pendingHeld,
completed, canceled, or aborted jobs that might intervene.
If an application detects that the jmGeneralNewestActiveJobIndex is
smaller than jmGeneralOldestActiveJobIndex, the job index has
wrapped. In this case, the application SHALL reset the index to 1
when the end of the table is reached and continue the GetNext
operations to find the rest of the active jobs.
NOTE - Applications detect the end of the jmAttributeTable table when
the OID returned by the GetNext operation is an OID in a different
MIB. There is no object in this MIB that specifies the maximum value
for the jmJobIndex supported by the implementation.
When the server or device is power-cycled, the agent SHALL remember
the next jmJobIndex value to be assigned, so that new jobs are not
assigned the same jmJobIndex as recent jobs before the power cycle.
3.3 The Attribute Mechanism and the Attribute Table(s)
Attributes are similar to information objects, except that attributes
are identified by an enum, instead of an OID, so that attributes may
be registered without requiring a new MIB. Also an implementation
that does not have the functionality represented by the attribute can
omit the attribute entirely, rather than having to return a
distinguished value. The agent is free to materialize an attribute
in the jmAttributeTable as soon as the agent is aware of the value of
the attribute.
The agent materializes job attributes in a four-indexed
jmAttributeTable:
1. jmGeneralJobSetIndex - which job set
2. jmJobIndex - which job in the job set
3. jmAttributeTypeIndex - which attribute
4. jmAttributeInstanceIndex - which attribute instance for those
attributes that can have multiple values per job.
Some attributes represent information about a job, such as a file-
name, a document-name, a submission-time or a completion time. Other
attributes represent resources required, e.g., a medium or a
colorant, etc. to process the job before the job starts processing OR
to indicate the amount of the resource consumed during and after
processing, e.g., pages completed or impressions completed. If both
a required and a consumed value of a resource is needed, this
specification assigns two separate attribute enums in the textual
convention.
NOTE - The table of contents lists all the attributes in order. This
order is the order of enum assignments which is the order that the
SNMP GetNext operation returns attributes. Most attributes apply to
all three configurations covered by this MIB specification (see
section 2.1 entitled "System Configurations for the Job Monitoring
MIB"). Those attributes that apply to a particular configuration are
indicated as 'Configuration n:' and SHALL NOT be used with other
configurations.
3.3.1 Conformance of Attribute Implementation
An agent SHALL implement any attribute if (1) the server or device
supports the functionality represented by the attribute and (2) the
information is available to the agent. The agent MAY create the
attribute row in the jmAttributeTable when the information is
available or MAY create the row earlier with the designated 'unknown'
value appropriate for that attribute. See next section.
If the server or device does not implement or does not provide access
to the information about an attribute, the agent SHOULD NOT create
the corresponding row in the jmAttributeTable.
3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and Attributes
Some attributes have a 'useful' Integer32 value, some have a 'useful'
OCTET STRING value, some MAY have either or both depending on
implementation, and some MUST have both. See the JmAttributeTypeTC
textual convention for the specification of each attribute.
SNMP requires that if an object cannot be implemented because its
values cannot be accessed, then a compliant agent SHALL return an
SNMP error in SNMPv1 or an exception value in SNMPv2. However, this
MIB has been designed so that 'all' objects can and SHALL be
implemented by an agent, so that neither the SNMPv1 error nor the
SNMPv2 exception value SHALL be generated by the agent. This MIB has
also been designed so that when an agent materializes an attribute,
the agent SHALL materialize a row consisting of both the
jmAttributeValueAsInteger and jmAttributeValueAsOctets objects.
In general, values for objects and attributes have been chosen so
that a management application will be able to determine whether a '
useful', 'unknown', or 'other' value is available. When a useful
value is not available for an object, that agent SHALL return a
zero-length string for octet strings, the value 'unknown(2)' for
enums, a '0' value for an object that represents an index in another
table, and a value '-2' for counting integers.
Since each attribute is represented by a row consisting of both the
jmAttributeValueAsInteger and jmAttributeValueAsOctets MANDATORY
objects, SNMP requires that the agent SHALL always create an
attribute row with both objects specified. However, for most
attributes the agent SHALL return a "useful" value for one of the
objects and SHALL return the 'other' value for the other object. For
integer only attributes, the agent SHALL always return a zero-length
string value for the jmAttributeValueAsOctets object. For octet
string only attributes, the agent SHALL always return a '-1' value
for the jmAttributeValueAsInteger object.
3.3.3 Index Value Attributes
A number of attributes are indexes in other tables. Such attribute
names end with the word 'Index'. If the agent has not (yet) assigned
an index value for a particular index attribute for a job, the agent
SHALL either: (1) return the value 0 or (2) not add this attribute to
the jmAttributeTable until the index value is assigned. In the
interests of brevity, the semantics for 0 is specified once here and
is not repeated for each index attribute specification and a DEFVAL
of 0 is implied, even though the DEFVAL for jmAttributeValueAsInteger
is -2.
3.3.4 Data Sub-types and Attribute Naming Conventions
Many attributes are sub-typed to give a more specific data type than
Integer32 or OCTET STRING. The data sub-type of each attribute is
indicated on the first line(s) of the description. Some attributes
have several different data sub-type representations. When an
attribute has both an Integer32 data sub-type and an OCTET STRING
data sub-type, the attribute can be represented in a single row in
the jmAttributeTable. In this case, the data sub-type name is not
included as the last part of the name of the attribute, e.g.,
documentFormat(38) which is both an enum and/or a name. When the
data sub-types cannot be represented by a single row in the
jmAttributeTable, each such representation is considered a separate
attribute and is assigned a separate name and enum value. For these
attributes, the name of the data sub-type is the last part of the
name of the attribute: Name, Index, DateAndTime, TimeStamp, etc. For
example, documentFormatIndex(37) is an index.
NOTE: The Table of Contents also lists the data sub-type and/or data
sub-types of each attribute, using the textual-convention name when
such is defined. The following abbreviations are used in the Table
of Contents as shown:
'Int32(-2..)' Integer32 (-2..2147483647)
'Int32(0..)' Integer32 (0..2147483647)
'Int32(1..)' Integer32 (1..2147483647)
'Int32(m..n)' For all other Integer ranges, the lower
and upper bound of the range is
indicated.
'UTF8String63' JmUTF8StringTC (SIZE(0..63))
'JobString63' JmJobStringTC (SIZE(0..63))
'Octets63' OCTET STRING (SIZE(0..63))
'Octets(m..n)' For all other OCTET STRING ranges, the
exact range is indicated.
3.3.5 Single-Value (Row) Versus Multi-Value (MULTI-ROW) Attributes
Most attributes have only one row per job. However, a few attributes
can have multiple values per job or even per document, where each
value is a separate row in the jmAttributeTable. Unless indicated
with 'MULTI-ROW:' in the JmAttributeTypeTC description, an agent
SHALL ensure that each attribute occurs only once in the
jmAttributeTable for a job. Most of the 'MULTI-ROW' attributes do
not allow duplicate values, i.e., the agent SHALL ensure that each
value occurs only once for a job. Only if the specification of the '
MULTI-ROW' attribute also says "There is no restriction on the same
xxx occurring in multiple rows" can the agent allow duplicate values
to occur for the job.
NOTE - Duplicates are allowed for 'extensive' 'MULTI-ROW' attributes,
such as fileName(34) or documentName(35) which are specified to be '
per-document' attributes, but are not allowed for 'intensive' '
MULTI-ROW' attributes, such as mediumConsumed(171) and
documentFormat(38) which are specified to be 'per-job' attributes.
3.3.6 Requested Objects and Attributes
A number of objects and attributes record requirements for the job.
Such object and attribute names end with the word 'Requested'. In
the interests of brevity, the phrase 'requested' means: (1) requested
by the client (or intervening server) in the job submission protocol
and may also mean (2) embedded in the submitted document data, and/or
(3) defaulted by the recipient device or server with the same
semantics as if the requester had supplied, depending on
implementation. Also if a value is supplied by the job submission
client, and the server/device determines a better value, through
processing or other means, the agent MAY return that better value for
such object and attribute.
3.3.7 Consumption Attributes
A number of objects and attributes record consumption. Such
attribute names end with the word 'Completed' or 'Consumed'. If the
job has not yet consumed what that resource is metering, the agent
either: (1) SHALL return the value 0 or (2) SHALL not add this
attribute to the jmAttributeTable until the consumption begins. In
the interests of brevity, the semantics for 0 is specified once here
and is not repeated for each consumption attribute specification and
a DEFVAL of 0 is implied, even though the DEFVAL for
jmAttributeValueAsInteger is -2.
3.3.8 Attribute Specifications
This section specifies the job attributes.
In the following definitions of the attributes, each description
indicates whether the useful value of the attribute SHALL be
represented using the jmAttributeValueAsInteger or the
jmAttributeValueAsOctets objects by the initial tag: 'INTEGER:' or '
OCTETS:', respectively.
Some attributes allow the agent implementer a choice of useful values
of either an integer, an octet string representation, or both,
depending on implementation. These attributes are indicated with '
INTEGER:' AND/OR 'OCTETS:' tags.
A very few attributes require both objects at the same time to
represent a pair of useful values (see mediumConsumed(171)). These
attributes are indicated with 'INTEGER:' AND 'OCTETS:' tags. See the
jmAttributeGroup for the descriptions of these two MANDATORY objects.
NOTE - The enum assignments are grouped logically with values
assigned in groups of 20, so that additional values may be registered
in the future and assigned a value that is part of their logical
grouping.
Values in the range 2**30 to 2**31-1 are reserved for private or
experimental usage. This range corresponds to the same range
reserved in IPP. Implementers are warned that use of such values may
conflict with other implementations. Implementers are encouraged to
request registration of enum values following the procedures in
Section 3.7.1.
NOTE: No attribute name exceeds 31 characters.
The standard attribute types are:
jmAttributeTypeIndex Datatype
-------------------- --------
other(1), Integer32 (-2..2147483647)
AND/OR
OCTET STRING(SIZE(0..63))
INTEGER: and/or OCTETS: An attribute that is not in the
list and/or that has not been approved and registered with
the PWG.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job State attributes (3 - 19 decimal)
+
+ The following attributes specify the state of a job.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jobStateReasons2(3), JmJobStateReasons2TC
INTEGER: Additional information about the job's current state
that augments the jmJobState object. See the description under
the JmJobStateReasons1TC textual-convention.
jobStateReasons3(4), JmJobStateReasons3TC
INTEGER: Additional information about the job's current state
that augments the jmJobState object. See the description under
JmJobStateReasons1TC textual-convention.
jobStateReasons4(5), JmJobStateReasons4TC
INTEGER: Additional information about the job's current state
that augments the jmJobState object. See the description under
JmJobStateReasons1TC textual-convention.
processingMessage(6), JmUTF8StringTC (SIZE(0..63))
OCTETS: MULTI-ROW: A coded character set message that is
generated by the server or device during the processing of the
job as a simple form of processing log to show progress and any
problems. The natural language of each value is specified by
the corresponding processingMessageNaturalLangTag(7) value.
NOTE - This attribute is intended for such conditions as
interpreter messages, rather than being the printable form of
the jmJobState and jmJobStateReasons1 objects and
jobStateReasons2, jobStateReasons3, and jobStateReasons4
attributes. In order to produce a localized printable form of
these job state objects/attribute, a management application
SHOULD produce a message from their enum and bit values.
NOTE - There is no job description attribute in IPP/1.0 that
corresponds to this attribute and this attribute does not
correspond to the IPP/1.0 'job-state-message' job description
attribute, which is just a printable form of the IPP 'job-state'
and 'job-state-reasons' job attributes.
There is no restriction for the same message occurring in
multiple rows.
processingMessageNaturalLangTag(7), OCTET STRING(SIZE(0..63))
OCTETS: MULTI-ROW: The natural language of the corresponding
processingMessage(6) attribute value. See section 3.6.1,
entitled 'Text generated by the server or device'.
If the agent does not know the natural language of the job
processing message, the agent SHALL either (1) return a zero
length string value for the processingMessageNaturalLangTag(7)
attribute or (2) not return the
processingMessageNaturalLangTag(7) attribute for the job.
There is no restriction for the same tag occurring in multiple
rows, since when this attribute is implemented, it SHOULD have a
value row for each corresponding processingMessage(6) attribute
value row.
jobCodedCharSet(8), CodedCharSet
INTEGER: The MIBenum identifier of the coded character set that
the agent is using to represent coded character set objects and
attributes of type 'JmJobStringTC'. These coded character set
objects and attributes are either: (1) supplied by the job
submitting client or (2) defaulted by the server or device when
omitted by the job submitting client. The agent SHALL represent
these objects and attributes in the MIB either (1) in the coded
character set as they were submitted or (2) MAY convert the
coded character set to another coded character set or encoding
scheme as identified by the jobCodedCharSet(8) attribute. See
section 3.6.2, entitled 'Text supplied by the job submitter'.
These MIBenum values are assigned by IANA [IANA-charsets] when
the coded character sets are registered. The coded character
set SHALL be one of the ones registered with IANA [IANA] and the
enum value uses the CodedCharSet textual-convention from the
Printer MIB. See the JmJobStringTC textual-convention.
If the agent does not know what coded character set was used by
the job submitting client, the agent SHALL either (1) return the
'unknown(2)' value for the jobCodedCharSet(8) attribute or (2)
not return the jobCodedCharSet(8) attribute for the job.
jobNaturalLanguageTag(9), OCTET STRING(SIZE(0..63))
OCTETS: The natural language of the job attributes supplied by
the job submitter or defaulted by the server or device for the
job, i.e., all objects and attributes represented by the '
JmJobStringTC' textual-convention, such as jobName,
mediumRequested, etc. See Section 3.6.2, entitled 'Text
supplied by the job submitter'.
If the agent does not know what natural language was used by the
job submitting client, the agent SHALL either (1) return a zero
length string value for the jobNaturalLanguageTag(9) attribute
or (2) not return jobNaturalLanguageTag(9) attribute for the
job.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job Identification attributes (20 - 49 decimal)
+
+ The following attributes help an end user, a system
+ operator, or an accounting program identify a job.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jobURI(20), OCTET STRING(SIZE(0..63))
OCTETS: MULTI-ROW: The job's Universal Resource
Identifier (URI) [RFC1738]. See IPP [ipp-model] for
example usage.
NOTE - The agent may be able to generate this value on each
SNMP Get operation from smaller values, rather than having
to store the entire URI.
If the URI exceeds 63 octets, the agent SHALL use multiple
values, with the next 63 octets coming in the second value,
etc.
NOTE - IPP [ipp-model] has a 1023-octet maximum length for
a URI, though the URI standard itself and HTTP/1.1 specify
no maximum length.
jobAccountName(21), OCTET STRING(SIZE(0..63))
OCTETS: Arbitrary binary information which MAY be coded
character set data or encrypted data supplied by the
submitting user for use by accounting services to allocate
or categorize charges for services provided, such as a
customer account name or number.
NOTE: This attribute NEED NOT be printable characters.
serverAssignedJobName(22), JmJobStringTC (SIZE(0..63))
OCTETS: Configuration 3 only: The human readable string
name, number, or ID of the job as assigned by the server
that submitted the job to the device that the agent is
providing access to with this MIB.
NOTE - This attribute is intended for enabling a user to
find his/her job that a server submitted to a device when
either the client does not support the jmJobSubmissionID or
the server does not pass the jmJobSubmissionID through to
the device.
jobName(23), JmJobStringTC (SIZE(0..63))
OCTETS: The human readable string name of the job as
assigned by the submitting user to help the user
distinguish between his/her various jobs. This name does
not need to be unique.
This attribute is intended for enabling a user or the
user's application to convey a job name that MAY be printed
on a start sheet, returned in a query result, or used in
notification or logging messages.
In order to assist users to find their jobs for job
submission protocols that don't supply a jmJobSubmissionID,
the agent SHOULD maintain the jobName attribute for the
time specified by the jmGeneralJobPersistence object,
rather than the (shorter) jmGeneralAttributePersistence
object.
If this attribute is not specified when the job is
submitted, no job name is assumed, but implementation
specific defaults are allowed, such as the value of the
documentName attribute of the first document in the job or
the fileName attribute of the first document in the job.
The jobName attribute is distinguished from the jobComment
attribute, in that the jobName attribute is intended to
permit the submitting user to distinguish between different
jobs that he/she has submitted. The jobComment attribute
is intended to be free form additional information that a
user might wish to use to communicate with himself/herself,
such as a reminder of what to do with the results or to
indicate a different set of input parameters were tried in
several different job submissions.
jobServiceTypes(24), JmJobServiceTypesTC
INTEGER: Specifies the type(s) of service to which the job
has been submitted (print, fax, scan, etc.). The service
type is bit encoded with each job service type so that more
general and arbitrary services can be created, such as
services with more than one destination type, or ones with
only a source or only a destination. For example, a job
service might scan, faxOut, and print a single job. In
this case, three bits would be set in the jobServiceTypes
attribute, corresponding to the hexadecimal values: 0x8 +
0x20 + 0x4, respectively, yielding: 0x2C.
Whether this attribute is set from a job attribute supplied
by the job submission client or is set by the recipient job
submission server or device depends on the job submission
protocol. This attribute SHALL be implemented if the
server or device has other types in addition to or instead
of printing.
One of the purposes of this attribute is to permit a
requester to filter out jobs that are not of interest. For
example, a printer operator may only be interested in jobs
that include printing.
jobSourceChannelIndex(25), Integer32 (0..2147483647)
INTEGER: The index of the row in the associated Printer
MIB [print-mib] of the channel which is the source of the
print job.
jobSourcePlatformType(26), JmJobSourcePlatformTypeTC
INTEGER: The source platform type of the immediate
upstream submitter that submitted the job to the server
(configuration 2) or device (configuration 1 and 3) to
which the agent is providing access. For configuration 1,
this is the type of the client that submitted the job to
the device; for configuration 2, this is the type of the
client that submitted the job to the server; and for
configuration 3, this is the type of the server that
submitted the job to the device.
submittingServerName(27), JmJobStringTC (SIZE(0..63))
OCTETS: For configuration 3 only: The administrative name
of the server that submitted the job to the device.
submittingApplicationName(28), JmJobStringTC (SIZE(0..63))
OCTETS: The name of the client application (not the server
in configuration 3) that submitted the job to the server or
device.
jobOriginatingHost(29), JmJobStringTC (SIZE(0..63))
OCTETS: The name of the client host (not the server host
name in configuration 3) that submitted the job to the
server or device.
deviceNameRequested(30), JmJobStringTC (SIZE(0..63))
OCTETS: The administratively defined coded character set
name of the target device requested by the submitting user.
For configuration 1, its value corresponds to the Printer
MIB [print-mib]: prtGeneralPrinterName object. For
configuration 2 and 3, its value is the name of the logical
or physical device that the user supplied to indicate to
the server on which device(s) they wanted the job to be
processed.
queueNameRequested(31), JmJobStringTC (SIZE(0..63))
OCTETS: The administratively defined coded character set
name of the target queue requested by the submitting user.
For configuration 1, its value corresponds to the queue in
the device for which the agent is providing access. For
configuration 2 and 3, its value is the name of the queue
that the user supplied to indicate to the server on which
device(s) they wanted the job to be processed.
NOTE - typically an implementation SHOULD support either
the deviceNameRequested or queueNameRequested attribute,
but not both.
physicalDevice(32), hrDeviceIndex
AND/OR
JmUTF8StringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The index of the physical device MIB
instance requested/used, such as the Printer MIB [print-mib].
This value is an hrDeviceIndex value. See the Host
Resources MIB [hr-mib].
AND/OR
OCTETS: MULTI-ROW: The name of the physical device to
which the job is assigned.
numberOfDocuments(33), Integer32 (-2..2147483647)
INTEGER: The number of documents in this job.
The agent SHOULD return this attribute if the job has more
than one document.
fileName(34), JmJobStringTC (SIZE(0..63))
OCTETS: MULTI-ROW: The coded character set file name or
URI [URI-spec] of the document.
There is no restriction on the same file name occurring in
multiple rows.
documentName(35), JmJobStringTC (SIZE(0..63))
OCTETS: MULTI-ROW: The coded character set name of the
document.
There is no restriction on the same document name occurring
in multiple rows.
jobComment(36), JmJobStringTC (SIZE(0..63))
OCTETS: An arbitrary human-readable coded character text
string supplied by the submitting user or the job
submitting application program for any purpose. For
example, a user might indicate what he/she is going to do
with the printed output or the job submitting application
program might indicate how the document was produced.
The jobComment attribute is not intended to be a name; see
the jobName attribute.
documentFormatIndex(37), Integer32 (0..2147483647)
INTEGER: MULTI-ROW: The index in the prtInterpreterTable
in the Printer MIB [print-mib] of the page description
language (PDL) or control language interpreter that this
job requires/uses. A document or a job MAY use more than
one PDL or control language.
NOTE - As with all intensive attributes where multiple rows
are allowed, there SHALL be only one distinct row for each
distinct interpreter; there SHALL be no duplicates.
NOTE - This attribute type is intended to be used with an
agent that implements the Printer MIB and SHALL not be used
if the agent does not implement the Printer MIB. Such an
agent SHALL use the documentFormat attribute instead.
documentFormat(38), PrtInterpreterLangFamilyTC
AND/OR
OCTET STRING(SIZE(0..63))
INTEGER: MULTI-ROW: The interpreter language family
corresponding to the Printer MIB [print-mib]
prtInterpreterLangFamily object, that this job
requires/uses. A document or a job MAY use more than one
PDL or control language.
AND/OR
OCTETS: MULTI-ROW: The document format registered as a
media type [iana-media-types], i.e., the name of the MIME
content-type/subtype. Examples: 'application/postscript',
'application/vnd.hp-PCL', 'application/pdf', 'text/plain'
(US-ASCII SHALL be assumed), 'text/plain; charset=iso-8859-1',
and 'application/octet-stream'. The IPP 'document-format'
job attribute uses these same values with the same semantics.
See the IPP [ipp-model] 'mimeMediaType' attribute syntax and
the document-format attribute for further examples and
explanation.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job Parameter attributes (50 - 67 decimal)
+
+ The following attributes represent input parameters
+ supplied by the submitting client in the job submission
+ protocol.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jobPriority(50), Integer32 (-2..100)
INTEGER: The priority for scheduling the job. It is used by
servers and devices that employ a priority-based scheduling
algorithm.
A higher value specifies a higher priority. The value 1 is
defined to indicate the lowest possible priority (a job which a
priority-based scheduling algorithm SHALL pass over in favor of
higher priority jobs). The value 100 is defined to indicate the
highest possible priority. Priority is expected to be evenly or
'normally' distributed across this range. The mapping of
vendor-defined priority over this range is implementation-
specific. -2 indicates unknown.
jobProcessAfterDateAndTime(51), DateAndTime (SNMPv2-TC)
OCTETS: The calendar date and time of day after which the job
SHALL become a candidate to be scheduled for processing. If the
value of this attribute is in the future, the server SHALL set
the value of the job's jmJobState object to pendingHeld and add
the jobProcessAfterSpecified bit value to the job's
jmJobStateReasons1 object. When the specified date and time
arrives, the server SHALL remove the jobProcessAfterSpecified
bit value from the job's jmJobStateReasons1 object and, if no
other reasons remain, SHALL change the job's jmJobState object
to pending.
jobHold(52), JmBooleanTC
INTEGER: If the value is 'true(4)', a client has explicitly
specified that the job is to be held until explicitly released.
Until the job is explicitly released by a client, the job SHALL
be in the pendingHeld state with the jobHoldSpecified value in
the jmJobStateReasons1 attribute.
jobHoldUntil(53), JmJobStringTC (SIZE(0..63))
OCTETS: The named time period during which the job SHALL become
a candidate for processing, such as 'evening', 'night', '
weekend', 'second-shift', 'third-shift', etc., (supported values
configured by the system administrator). See IPP [ipp-model]
for the standard keyword values. Until that time period
arrives, the job SHALL be in the pendingHeld state with the
jobHoldUntilSpecified value in the jmJobStateReasons1 object.
The value 'no-hold' SHALL indicate explicitly that no time
period has been specified; the absence of this attribute SHALL
indicate implicitly that no time period has been specified.
outputBin(54), Integer32 (0..2147483647)
AND/OR
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The output subunit index in the Printer
MIB [print-mib]
AND/OR
OCTETS: MULTI-ROW: the name or number (represented as ASCII
digits) of the output bin to which all or part of the job is
placed in.
sides(55), Integer32 (-2..2)
INTEGER: MULTI-ROW: The number of sides, '1' or '2', that any
document in this job requires/used.
finishing(56), JmFinishingTC
INTEGER: MULTI-ROW: Type of finishing that any document in
this job requires/used.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Image Quality attributes (requested and consumed) (70 - 87)
+
+ For devices that can vary the image quality.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
printQualityRequested(70), JmPrintQualityTC
INTEGER: MULTI-ROW: The print quality selection requested for
a document in the job for printers that allow quality
differentiation.
printQualityUsed(71), JmPrintQualityTC
INTEGER: MULTI-ROW: The print quality selection actually used
by a document in the job for printers that allow quality
differentiation.
printerResolutionRequested(72), JmPrinterResolutionTC
OCTETS: MULTI-ROW: The printer resolution requested for a
document in the job for printers that support resolution
selection.
printerResolutionUsed(73), JmPrinterResolutionTC
OCTETS: MULTI-ROW: The printer resolution actually used by a
document in the job for printers that support resolution
selection.
tonerEcomonyRequested(74), JmTonerEconomyTC
INTEGER: MULTI-ROW: The toner economy selection requested for
documents in the job for printers that allow toner economy
differentiation.
tonerEcomonyUsed(75), JmTonerEconomyTC
INTEGER: MULTI-ROW: The toner economy selection actually used
by documents in the job for printers that allow toner economy
differentiation.
tonerDensityRequested(76) Integer32 (-2..100)
INTEGER: MULTI-ROW: The toner density requested for a document
in this job for devices that can vary toner density levels.
Level 1 is the lowest density and level 100 is the highest
density level. Devices with a smaller range, SHALL map the
1-100 range evenly onto the implemented range.
tonerDensityUsed(77), Integer32 (-2..100)
INTEGER: MULTI-ROW: The toner density used by documents in
this job for devices that can vary toner density levels. Level
1 is the lowest density and level 100 is the highest density
level. Devices with a smaller range, SHALL map the 1-100 range
evenly onto the implemented range.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Job Progress attributes (requested and consumed) (90-109)
+
+ Pairs of these attributes can be used by monitoring
+ applications to show an indication of relative progress
+ to users. See section 3.4, entitled:
+ 'Monitoring Job Progress'.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jobCopiesRequested(90), Integer32 (-2..2147483647)
INTEGER: The number of copies of the entire job that are to be
produced.
jobCopiesCompleted(91), Integer32 (-2..2147483647)
INTEGER: The number of copies of the entire job that have been
completed so far.
documentCopiesRequested(92), Integer32 (-2..2147483647)
INTEGER: The total count of the number of document copies
requested for the job as a whole. If there are documents A, B,
and C, and document B is specified to produce 4 copies, the
number of document copies requested is 6 for the job.
This attribute SHALL be used only when a job has multiple
documents. The jobCopiesRequested attribute SHALL be used when
the job has only one document.
documentCopiesCompleted(93), Integer32 (-2..2147483647)
INTEGER: The total count of the number of document copies
completed so far for the job as a whole. If there are documents
A, B, and C, and document B is specified to produce 4 copies,
the number of document copies starts a 0 and runs up to 6 for
the job as the job processes.
This attribute SHALL be used only when a job has multiple
documents. The jobCopiesCompleted attribute SHALL be used when
the job has only one document.
jobKOctetsTransferred(94), Integer32 (-2..2147483647)
INTEGER: The number of K (1024) octets transferred to the
server or device to which the agent is providing access. This
count is independent of the number of copies of the job or
documents that will be produced, but it is only a measure of the
number of bytes transferred to the server or device.
The agent SHALL round the actual number of octets transferred up
to the next higher K. Thus 0 octets SHALL be represented as '
0', 1-1024 octets SHALL BE represented as '1', 1025-2048 SHALL
be '2', etc. When the job completes, the values of the
jmJobKOctetsPerCopyRequested object and the
jobKOctetsTransferred attribute SHALL be equal.
NOTE - The jobKOctetsTransferred can be used with the
jmJobKOctetsPerCopyRequested object in order to produce a
relative indication of the progress of the job for agents that
do not implement the jmJobKOctetsProcessed object.
sheetCompletedCopyNumber(95), Integer32 (-2..2147483647)
INTEGER: The number of the copy being stacked for the current
document. This number starts at 0, is set to 1 when the first
sheet of the first copy for each document is being stacked and
is equal to n where n is the nth sheet stacked in the current
document copy. See section 3.4 , entitled 'Monitoring Job
Progress'.
sheetCompletedDocumentNumber(96), Integer32 (-2..2147483647)
INTEGER: The ordinal number of the document in the job that is
currently being stacked. This number starts at 0, increments to
1 when the first sheet of the first document in the job is being
stacked, and is equal to n where n is the nth document in the
job, starting with 1.
Implementations that only support one document jobs SHOULD NOT
implement this attribute.
jobCollationType(97), JmJobCollationTypeTC
INTEGER: The type of job collation. See also Section 3.4,
entitled 'Monitoring Job Progress'.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Impression attributes (110 - 129 decimal)
+
+ See the definition of the terms 'impression', 'sheet',
+ and 'page' in Section 2.
+
+ See also jmJobImpressionsPerCopyRequested and
+ jmJobImpressionsCompleted objects in the jmJobTable.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
impressionsSpooled(110), Integer32 (-2..2147483647)
INTEGER: The number of impressions spooled to the server or
device for the job so far.
impressionsSentToDevice(111), Integer32 (-2..2147483647)
INTEGER: The number of impressions sent to the device for the
job so far.
impressionsInterpreted(112), Integer32 (-2..2147483647)
INTEGER: The number of impressions interpreted for the job so
far.
impressionsCompletedCurrentCopy(113),
Integer32 (-2..2147483647)
INTEGER: The number of impressions completed by the device for
the current copy of the current document so far. For printing,
the impressions completed includes interpreting, marking, and
stacking the output. For other types of job services, the
number of impressions completed includes the number of
impressions processed.
This value SHALL be reset to 0 for each document in the job and
for each document copy.
fullColorImpressionsCompleted(114), Integer32 (-2..2147483647)
INTEGER: The number of full color impressions completed by the
device for this job so far. For printing, the impressions
completed includes interpreting, marking, and stacking the
output. For other types of job services, the number of
impressions completed includes the number of impressions
processed. Full color impressions are typically defined as those
requiring 3 or more colorants, but this MAY vary by
implementation. In any case, the value of this attribute counts
by 1 for each side that has full color, not by the number of
colors per side (and the other impression counters are
incremented, except highlightColorImpressionsCompleted(115)).
highlightColorImpressionsCompleted(115),
Integer32 (-2..2147483647)
INTEGER: The number of highlight color impressions
completed by the device for this job so far. For printing,
the impressions completed includes interpreting, marking,
and stacking the output. For other types of job services,
the number of impressions completed includes the number of
impressions processed. Highlight color impressions are
typically defined as those requiring black plus one other
colorant, but this MAY vary by implementation. In any
case, the value of this attribute counts by 1 for each side
that has highlight color (and the other impression counters
are incremented, except
fullColorImpressionsCompleted(114)).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Page attributes (130 - 149 decimal)
+
+ See the definition of 'impression', 'sheet', and 'page'
+ in Section 2.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
pagesRequested(130), Integer32 (-2..2147483647)
INTEGER: The number of logical pages requested by the job
to be processed.
pagesCompleted(131), Integer32 (-2..2147483647)
INTEGER: The number of logical pages completed for this
job so far.
For implementations where multiple copies are produced by
the interpreter with only a single pass over the data, the
final value SHALL be equal to the value of the
pagesRequested object. For implementations where multiple
copies are produced by the interpreter by processing the
data for each copy, the final value SHALL be a multiple of
the value of the pagesRequested object.
NOTE - See the impressionsCompletedCurrentCopy and
pagesCompletedCurrentCopy attributes for attributes that
are reset on each document copy.
NOTE - The pagesCompleted object can be used with the
pagesRequested object to provide an indication of the
relative progress of the job, provided that the
multiplicative factor is taken into account for some
implementations of multiple copies.
pagesCompletedCurrentCopy(132), Integer32 (-2..2147483647)
INTEGER: The number of logical pages completed for the
current copy of the document so far. This value SHALL be
reset to 0 for each document in the job and for each
document copy.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Sheet attributes (150 - 169 decimal)
+
+ See the definition of 'impression', 'sheet', and 'page'
+ in Section 2.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
sheetsRequested(150), Integer32 (-2..2147483647)
INTEGER: The total number of medium sheets requested to be
produced for this job.
Unlike the jmJobKOctetsPerCopyRequested and
jmJobImpressionsPerCopyRequested attributes, the
sheetsRequested(150) attribute SHALL include the
multiplicative factor contributed by the number of copies
and so is the total number of sheets to be produced by the
job, as opposed to the size of the document(s) submitted.
sheetsCompleted(151), Integer32 (-2..2147483647)
INTEGER: The total number of medium sheets that have
completed marking and stacking for the entire job so far
whether those sheets have been processed on one side or on
both.
sheetsCompletedCurrentCopy(152), Integer32 (-2..2147483647)
INTEGER: The number of medium sheets that have completed
marking and stacking for the current copy of a document in
the job so far whether those sheets have been processed on
one side or on both.
The value of this attribute SHALL be 0 before the job
starts processing and SHALL be reset to 1 after the first
sheet of each document and document copy in the job is
processed and stacked.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Resources attributes (requested and consumed) (170 - 189)
+
+ Pairs of these attributes can be used by monitoring
+ applications to show an indication of relative usage to
+ users, i.e., a 'thermometer'.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mediumRequested(170), JmMediumTypeTC
AND/OR
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The type
AND/OR
OCTETS: MULTI-ROW: the name of the medium that is
required by the job.
NOTE - The name (JmJobStringTC) values correspond to the
name values of the prtInputMediaName object in the Printer
MIB [print-mib] and the name, size, and input tray values
of the IPP 'media' attribute [ipp-model].
mediumConsumed(171), Integer32 (-2..2147483647)
AND
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The number of sheets
AND
OCTETS: MULTI-ROW: the name of the medium that has been
consumed so far whether those sheets have been processed on
one side or on both.
This attribute SHALL have both Integer32 and OCTET STRING
(represented as JmJobStringTC) values.
NOTE - The name (JmJobStringTC) values correspond to the
name values of the prtInputMediaName object in the Printer
MIB [print-mib] and the name, size, and input tray values
of the IPP 'media' attribute [ipp-model].
colorantRequested(172), Integer32 (-2..2147483647)
AND/OR
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The index (prtMarkerColorantIndex) in
the Printer MIB [print-mib]
AND/OR
OCTETS: MULTI-ROW: the name of the colorant requested.
NOTE - The name (JmJobStringTC) values correspond to the
name values of the prtMarkerColorantValue object in the
Printer MIB. Examples are: red, blue.
colorantConsumed(173), Integer32 (-2..2147483647)
AND/OR
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The index (prtMarkerColorantIndex) in
the Printer MIB [print-mib]
AND/OR
OCTETS: MULTI-ROW: the name of the colorant consumed.
NOTE - The name (JmJobStringTC) values correspond to the
name values of the prtMarkerColorantValue object in the
Printer MIB. Examples are: red, blue
mediumTypeConsumed(174), Integer32 (-2..2147483647)
AND
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The number of sheets of the indicated
medium type that has been consumed so far whether those
sheets have been processed on one side or on both
AND
OCTETS: MULTI-ROW: the name of that medium type.
This attribute SHALL have both Integer32 and OCTET STRING
(represented as JmJobStringTC) values.
NOTE - The type name (JmJobStringTC) values correspond to
the type name values of the prtInputMediaType object in the
Printer MIB [print-mib]. Values are: 'stationery',
'transparency', 'envelope', etc. These medium type names
correspond to the enum values of JmMediumTypeTC used in the
mediumRequested attribute.
mediumSizeConsumed(175), Integer32 (-2..2147483647)
AND
JmJobStringTC (SIZE(0..63))
INTEGER: MULTI-ROW: The number of sheets of the indicated
medium size that has been consumed so far whether those
sheets have been processed on one side or on both
AND
OCTETS: MULTI-ROW: the name of that medium size.
This attribute SHALL have both Integer32 and OCTET STRING
(represented as JmJobStringTC) values.
NOTE - The size name (JmJobStringTC) values correspond to
the size name values in the Printer MIB [print-mib]
Appendix B. These size name values are also a subset of
the keyword values defined by [ipp-model] for the 'media'
Job Template attribute. Values are: 'letter', 'a', 'iso-
a4', 'jis-b4', etc.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Time attributes (set by server or device) (190 - 209 decimal)
+
+ This section of attributes are ones that are set by the
+ server or device that accepts jobs. Two forms of time are
+ provided. Each form is represented in a separate attribute.
+ See section 3.1.2 and section 3.1.3 for the
+ conformance requirements for time attribute for agents and
+ monitoring applications, respectively. The two forms are:
+
+ 'DateAndTime' is an 8 or 11 octet binary encoded year,
+ month, day, hour, minute, second, deci-second with
+ optional offset from UTC. See SNMPv2-TC [SMIv2-TC].
+
+ NOTE: 'DateAndTime' is not printable characters; it is
+ binary.
+
+ 'JmTimeStampTC' is the time of day measured in the number of
+ seconds since the system was booted.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jobSubmissionToServerTime(190), JmTimeStampTC
AND/OR
DateAndTime
INTEGER: Configuration 3 only: The time
AND/OR
OCTETS: the date and time that the job was submitted to
the server (as distinguished from the device which uses
jobSubmissionTime).
jobSubmissionTime(191), JmTimeStampTC
AND/OR
DateAndTime
INTEGER: Configurations 1, 2, and 3: The time
AND/OR
OCTETS: the date and time that the job was submitted to
the server or device to which the agent is providing
access.
jobStartedBeingHeldTime(192), JmTimeStampTC
AND/OR
DateAndTime
INTEGER: The time
AND/OR
OCTETS: the date and time that the job last entered the
pendingHeld state. If the job has never entered the
pendingHeld state, then the value SHALL be '0' or the
attribute SHALL not be present in the table.
jobStartedProcessingTime(193), JmTimeStampTC
AND/OR
DateAndTime
INTEGER: The time
AND/OR
OCTETS: the date and time that the job started processing.
jobCompletionTime(194), JmTimeStampTC
AND/OR
DateAndTime
INTEGER: The time
AND/OR
OCTETS: the date and time that the job entered the
completed, canceled, or aborted state.
jobProcessingCPUTime(195) Integer32 (-2..2147483647)
UNITS 'seconds'
INTEGER: The amount of CPU time in seconds that the job
has been in the processing state. If the job enters the
processingStopped state, that elapsed time SHALL not be
included. In other words, the jobProcessingCPUTime value
SHOULD be relatively repeatable when the same job is
processed again on the same device.
3.3.9 Job State Reason bit definitions
The JmJobStateReasonsNTC (N=1..4) textual-conventions are used with
the jmJobStateReasons1 object and jobStateReasonsN (N=2..4),
respectively, to provide additional information regarding the current
jmJobState object value. These values MAY be used with any job state
or states for which the reason makes sense.
NOTE - While values cannot be added to the jmJobState object without
impacting deployed clients that take actions upon receiving
jmJobState values, it is the intent that additional
JmJobStateReasonsNTC enums can be defined and registered without
impacting such deployed clients. In other words, the
jmJobStateReasons1 object and jobStateReasonsN attributes are
intended to be extensible.
NOTE - The Job Monitoring MIB contains a superset of the IPP values
[ipp-model] for the IPP 'job-state-reasons' attribute, since the Job
Monitoring MIB is intended to cover other job submission protocols as
well. Also some of the names of the reasons have been changed from '
printer' to 'device', since the Job Monitoring MIB is intended to
cover additional types of devices, including input devices, such as
scanners.
3.3.9.1 JmJobStateReasons1TC specification
The following standard values are defined (in hexadecimal) as powers
of two, since multiple values MAY be used at the same time. For ease
of understanding, the JmJobStateReasons1TC reasons are presented in
the order in which the reasons are likely to occur (if implemented),
starting with the 'jobIncoming' value and ending with the '
jobCompletedWithErrors' value.
other 0x1
The job state reason is not one of the standardized or
registered reasons.
unknown 0x2
The job state reason is not known to the agent or is
indeterminent.
jobIncoming 0x4
The job has been accepted by the server or device, but the
server or device is expecting (1) additional operations from the
client to finish creating the job and/or (2) is
accessing/accepting document data.
submissionInterrupted 0x8
The job was not completely submitted for some unforeseen reason,
such as: (1) the server has crashed before the job was closed by
the client, (2) the server or the document transfer method has
crashed in some non-recoverable way before the document data was
entirely transferred to the server, (3) the client crashed or
failed to close the job before the time-out period.
jobOutgoing 0x10
Configuration 2 only: The server is transmitting the job to the
device.
jobHoldSpecified 0x20
The value of the job's jobHold(52) attribute is TRUE. The job
SHALL NOT be a candidate for processing until this reason is
removed and there are no other reasons to hold the job.
jobHoldUntilSpecified 0x40
The value of the job's jobHoldUntil(53) attribute specifies a
time period that is still in the future. The job SHALL NOT be a
candidate for processing until this reason is removed and there
are no other reasons to hold the job.
jobProcessAfterSpecified 0x80
The value of the job's jobProcessAfterDateAndTime(51) attribute
specifies a time that is still in the future. The job SHALL NOT
be a candidate for processing until this reason is removed and
there are no other reasons to hold the job.
resourcesAreNotReady 0x100
At least one of the resources needed by the job, such as media,
fonts, resource objects, etc., is not ready on any of the
physical devices for which the job is a candidate. This
condition MAY be detected when the job is accepted, or
subsequently while the job is pending or processing, depending
on implementation.
deviceStoppedPartly 0x200
One or more, but not all, of the devices to which the job is
assigned are stopped. If all of the devices are stopped (or the
only device is stopped), the deviceStopped reason SHALL be used.
deviceStopped 0x400
The device(s) to which the job is assigned is (are all) stopped.
jobInterpreting 0x800
The device to which the job is assigned is interpreting the
document data.
jobPrinting 0x1000
The output device to which the job is assigned is marking media.
This value is useful for servers and output devices which spend
a great deal of time processing (1) when no marking is happening
and then want to show that marking is now happening or (2) when
the job is in the process of being canceled or aborted while the
job remains in the processing state, but the marking has not yet
stopped so that impression or sheet counts are still increasing
for the job.
jobCanceledByUser 0x2000
The job was canceled by the owner of the job, i.e., by a user
whose name is the same as the value of the job's jmJobOwner
object, or by some other authorized end-user, such as a member
of the job owner's security group.
jobCanceledByOperator 0x4000
The job was canceled by the operator, i.e., by a user who has
been authenticated as having operator privileges (whether local
or remote).
jobCanceledAtDevice 0x8000
The job was canceled by an unidentified local user, i.e., a user
at a console at the device.
abortedBySystem 0x10000
The job (1) is in the process of being aborted, (2) has been
aborted by the system and placed in the 'aborted' state, or (3)
has been aborted by the system and placed in the 'pendingHeld'
state, so that a user or operator can manually try the job
again.
processingToStopPoint 0x20000
The requester has issued an operation to cancel or interrupt the
job or the server/device has aborted the job, but the
server/device is still performing some actions on the job until
a specified stop point occurs or job termination/cleanup is
completed.
This reason is recommended to be used in conjunction with the
processing job state to indicate that the server/device is still
performing some actions on the job while the job remains in the
processing state. After all the job's resources consumed
counters have stopped incrementing, the server/device moves the
job from the processing state to the canceled or aborted job
states.
serviceOffLine 0x40000
The service or document transform is off-line and accepting no
jobs. All pending jobs are put into the pendingHeld state.
This situation could be true if the service's or document
transform's input is impaired or broken.
jobCompletedSuccessfully 0x80000
The job completed successfully.
jobCompletedWithWarnings 0x100000
The job completed with warnings.
jobCompletedWithErrors 0x200000
The job completed with errors (and possibly warnings too).
The following additional job state reasons have been added to
represent job states that are in ISO DPA [iso-dpa] and other job
submission protocols:
jobPaused 0x400000
The job has been indefinitely suspended by a client issuing an
operation to suspend the job so that other jobs may proceed
using the same devices. The client MAY issue an operation to
resume the paused job at any time, in which case the agent SHALL
remove the jobPaused values from the job's jmJobStateReasons1
object and the job is eventually resumed at or near the point
where the job was paused.
jobInterrupted 0x800000 The job has been
interrupted while processing by a client
issuing an operation that specifies another job to be run
instead of the current job. The server or device will
automatically resume the interrupted job when the interrupting
job completes.
jobRetained 0x1000000
The job is being retained by the server or device with all of
the job's document data (and submitted resources, such as fonts,
logos, and forms, if any). Thus a client could issue an
operation to the server or device to either (1) re-do the job
(or a copy of the job) on the same server or device or (2)
resubmit the job to another server or device. When a client
could no longer re-do/resubmit the job, such as after the
document data has been discarded, the agent SHALL remove the
jobRetained value from the jmJobStateReasons1 object.
These bit definitions are the equivalent of a type 2 enum except
that combinations of bits may be used together. See section
3.7.1.2. The remaining bits are reserved for future
standardization and/or registration.
3.3.9.2 JmJobStateReasons2TC specification
The following standard values are defined (in hexadecimal) as powers
of two, since multiple values MAY be used at the same time.
cascaded 0x1
An outbound gateway has transmitted all of the job's job and
document attributes and data to another spooling system.
deletedByAdministrator 0x2
The administrator has deleted the job.
discardTimeArrived 0x4
The job has been deleted due to the fact that the time specified
by the job's job-discard-time attribute has arrived.
postProcessingFailed 0x8
The post-processing agent failed while trying to log accounting
attributes for the job; therefore the job has been placed into
the completed state with the jobRetained jmJobStateReasons1
object value for a system-defined period of time, so the
administrator can examine it, resubmit it, etc.
jobTransforming 0x10
The server/device is interpreting document data and producing
another electronic representation.
maxJobFaultCountExceeded 0x20
The job has faulted several times and has exceeded the
administratively defined fault count limit.
devicesNeedAttentionTimeOut 0x40
One or more document transforms that the job is using needs
human intervention in order for the job to make progress, but
the human intervention did not occur within the site-settable
time-out value.
needsKeyOperatorTimeOut 0x80
One or more devices or document transforms that the job is using
need a specially trained operator (who may need a key to unlock
the device and gain access) in order for the job to make
progress, but the key operator intervention did not occur within
the site-settable time-out value.
jobStartWaitTimeOut 0x100
The server/device has stopped the job at the beginning of
processing to await human action, such as installing a special
cartridge or special non-standard media, but the job was not
resumed within the site-settable time-out value and the
server/device has transitioned the job to the pendingHeld state.
jobEndWaitTimeOut 0x200
The server/device has stopped the job at the end of processing
to await human action, such as removing a special cartridge or
restoring standard media, but the job was not resumed within the
site-settable time-out value and the server/device has
transitioned the job to the completed state.
jobPasswordWaitTimeOut 0x400
The server/device has stopped the job at the beginning of
processing to await input of the job's password, but the
password was not received within the site-settable time-out
value.
deviceTimedOut 0x800
A device that the job was using has not responded in a period
specified by the device's site-settable attribute.
connectingToDeviceTimeOut 0x1000
The server is attempting to connect to one or more devices which
may be dial-up, polled, or queued, and so may be busy with
traffic from other systems, but server was unable to connect to
the device within the site-settable time-out value.
transferring 0x2000
The job is being transferred to a down stream server or
downstream device.
queuedInDevice 0x4000
The server/device has queued the job in a down stream server or
downstream device.
jobQueued 0x8000
The server/device has queued the document data.
jobCleanup 0x10000
The server/device is performing cleanup activity as part of
ending normal processing.
jobPasswordWait 0x20000
The server/device has selected the job to be next to process,
but instead of assigning resources and starting the job
processing, the server/device has transitioned the job to the
pendingHeld state to await entry of a password (and dispatched
another job, if there is one).
validating 0x40000
The server/device is validating the job after accepting the job.
queueHeld 0x80000
The operator has held the entire job set or queue.
jobProofWait 0x100000
The job has produced a single proof copy and is in the
pendingHeld state waiting for the requester to issue an
operation to release the job to print normally, obeying any job
and document copy attributes that were originally submitted.
heldForDiagnostics 0x200000
The system is running intrusive diagnostics, so that all jobs
are being held.
noSpaceOnServer 0x800000
There is no room on the server to store all of the job.
pinRequired 0x1000000
The System Administrator settable device policy is (1) to
require PINs, and (2) to hold jobs that do not have a pin
supplied as an input parameter when the job was created.
exceededAccountLimit 0x2000000
The account for which this job is drawn has exceeded its limit.
This condition SHOULD be detected before the job is scheduled so
that the user does not wait until his/her job is scheduled only
to find that the account is overdrawn. This condition MAY also
occur while the job is processing either as processing begins or
part way through processing.
heldForRetry 0x4000000
The job encountered some errors that the server/device could not
recover from with its normal retry procedures, but the error
might not be encountered if the job is processed again in the
future. Example cases are phone number busy or remote file
system in-accessible. For such a situation, the server/device
SHALL transition the job from the processing to the pendingHeld,
rather than to the aborted state.
The following values are from the X/Open PSIS draft standard:
canceledByShutdown 0x8000000
The job was canceled because the server or device was shutdown
before completing the job.
deviceUnavailable 0x10000000
This job was aborted by the system because the device is
currently unable to accept jobs.
wrongDevice 0x20000000
This job was aborted by the system because the device is unable
to handle this particular job; the spooler SHOULD try another
device or the user should submit the job to another device.
badJob 0x40000000
This job was aborted by the system because this job has a major
problem, such as an ill-formed PDL; the spooler SHOULD not even
try another device.
These bit definitions are the equivalent of a type 2 enum except that
combinations of them may be used together. See section 3.7.1.2.
3.3.9.3 JmJobStateReasons3TC specification
This textual-convention is used with the jobStateReasons3 attribute
to provides additional information regarding the jmJobState object.
The following standard values are defined (in hexadecimal) as powers
of two, since multiple values may be used at the same time:
jobInterruptedByDeviceFailure 0x1
A device or the print system software that the job was using has
failed while the job was processing. The server or device is
keeping the job in the pendingHeld state until an operator can
determine what to do with the job.
These bit definitions are the equivalent of a type 2 enum except that
combinations of them may be used together. See section 3.7.1.2. The
remaining bits are reserved for future standardization and/or
registration.
3.3.9.4 JmJobStateReasons4TC specification
This textual-convention is used with the jobStateReasons4 attribute
to provides additional information regarding the jmJobState object.
The following standard values are defined (in hexadecimal) as powers
of two, since multiple values MAY be used at the same time.
None defined at this time.
These bit definitions are the equivalent of a type 2 enum except that
combinations of them may be used together. See section 3.7.1.2. The
remaining bits are reserved for future standardization and/or
registration.
3.4 Monitoring Job Progress
There are a number of objects and attributes for monitoring the
progress of a job. These objects and attributes count the number of
K octets, impressions, sheets, and pages requested or completed. For
impressions and sheets, "completed" means stacked, unless the
implementation is unable to detect when each sheet is stacked, in
which case stacked is approximated when processing of each sheet
completes. There are objects and attributes for the overall job and
for the current copy of the document currently being stacked. For
the latter, the rate at which the various objects and attributes
count depends on the sheet and document collation of the job.
Job Collation included sheet collation and document collation. Sheet
collation is defined to be the ordering of sheets within a document
copy. Document collation is defined to be ordering of document
copies within a multi-document job. There are three types of job
collation (see terminology definitions in Section 2):
1.uncollatedSheets(3) - No collation of the sheets within each
document copy, i.e., each sheet of a document that is to produce
multiple copies is replicated before the next sheet in the
document is processed and stacked. If the device has an output
bin collator, the uncollatedSheets(3) value may actually produce
collated sheets as far as the user is concerned (in the output
bins). However, when the job collation is the to a monitoring
application between a device that has an output bin collator and
one that does not.
2.collatedDocuments(4) - Collation of the sheets within each
document copy is performed within the printing device by making
multiple passes over either the source or an intermediate
representation of the document. In addition, when there are
multiple documents per job, the i'th copy of each document is
stacked before the j'th copy of each document, i.e., the
documents are collated within each job copy. For example, if a
job is submitted with documents, A and B, the job is made
available to the end user as: A, B, A, B, .... The '
collatedDocuments(4)' value corresponds to the IPP [ipp-model] '
separate-documents-collated-copies' value of the "multiple-
document-handling" attribute.
If jobCopiesRequested or documentCopiesRequested = 1, then
jobCollationType is defined as 4.
3.uncollatedDocuments(5) - Collation of the sheets within each
document copy is performed within the printing device by making
multiple passes over either the source or an intermediate
representation of the document. In addition, when there are
multiple documents per job, all copies of the first document in
the job are stacked before the any copied of the next document in
the job, i.e., the documents are uncollated within the job. For
example, if a job is submitted with documents, A and B, the job
is mad available to the end user as: A, A, ..., B, B, .... The
'uncollatedDocuments(5)' value corresponds to the IPP [ipp-model]
'separate-documents-uncollated-copies' value of the "multiple-
document-handling" attribute.
Consider the following four variables that are used to monitor the
progress of a job's impressions:
1.jmJobImpressionsCompleted - counts the total number of
impressions stacked for the job
2.impressionsCompletedCurrentCopy - counts the number of
impressions stacked for the current document copy
3.sheetCompletedCopyNumber - identifies the number of the copy for
the current document being stacked where the first copy is 1.
4.sheetCompletedDocumentNumber - identifies the current document
within the job that is being stacked where the first document in
a job is 1. NOTE: this attribute SHOULD NOT be implemented for
implementations that only support one document per job.
For each of the three types of job collation, a job with three copies
of two documents (1, 2), where each document consists of 3
impressions, the four variables have the following values as each
sheet is stacked for one-sided printing:
Job Collation Type = uncollatedSheets(3)
jmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 1 2 1
3 1 3 1
4 2 1 1
5 2 2 1
6 2 3 1
7 3 1 1
8 3 2 1
9 3 3 1
10 1 1 2
11 1 2 2
12 1 3 2
13 2 1 2
14 2 2 2
15 2 3 2
16 3 1 2
17 3 2 2
18 3 3 2
Job Collation Type = collatedDocuments(4)
JmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 1 2
5 2 1 2
6 3 1 2
7 1 2 1
8 2 2 1
9 3 2 1
10 1 2 2
11 2 2 2
12 3 2 2
13 1 3 1
14 2 3 1
15 3 3 1
16 1 3 2
17 2 3 2
18 3 3 2
Job Collation Type = uncollatedDocuments(5)
jmJobImpressions Impressions sheetCompleted sheetCompleted
Completed CompletedCurrent CopyNumber DocumentNumber
Copy
0 0 0 0
1 1 1 1
2 2 1 1
3 3 1 1
4 1 2 1
5 2 2 1
6 3 2 1
7 1 3 1
8 2 3 1
9 3 3 1
10 1 1 2
11 2 1 2
12 3 1 2
13 1 2 2
14 2 2 2
15 3 2 2
16 1 3 2
17 2 3 2
18 3 3 2
3.5 Job Identification
There are a number of attributes that permit a user, operator or
system administrator to identify jobs of interest, such as jobURI,
jobName, jobOriginatingHost, etc. In addition, there is a
jmJobSubmissionID object that is a text string table index. Being a
table index allows a monitoring application to quickly locate and
identify a particular job of interest that was submitted from a
particular client by the user invoking the monitoring application
without having to scan the entire job table. The Job Monitoring MIB
needs to provide for identification of the job at both sides of the
job submission process. The primary identification point is the
client side. The jmJobSubmissionID allows the monitoring application
to identify the job of interest from all the jobs currently "known"
by the server or device. The value of jmJobSubmissionID can be
assigned by either the client's local system or a downstream server
or device. The point of assignment depends on the job submission
protocol in use.
The server/device-side identifier, called the jmJobIndex object,
SHALL be assigned by the SNMP Job Monitoring MIB agent when the
server or device accepts the jobs from submitting clients. The
jmJobIndex object allows the interested party to obtain all objects
desired that relate to a particular job. See Section 3.2, entitled '
The Job Tables and the Oldest Active and Newest Active Indexes' for
the specification of how the agent SHALL assign the jmJobIndex
values.
The MIB provides a mapping table that maps each jmJobSubmissionID
value to a corresponding jmJobIndex value generated by the agent, so
that an application can determine the correct value for the
jmJobIndex value for the job of interest in a single Get operation,
given the Job Submission ID. See the jmJobIDGroup.
In some configurations there may be more than one application program
that monitors the same job when the job passes from one network
entity to another when it is submitted. See configuration 3. When
there are multiple job submission IDs, each entity MAY supply an
appropriate jmJobSubmissionID value. In this case there would be a
separate entry in the jmJobSubmissionID table, one for each
jmJobSubmissionID. All entries would map to the same jmJobIndex that
contains the job data. When the job is deleted, it is up to the
agent to remove all