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 entries that point to the job from the
jmJobSubmissionID table as well.
The jobName attribute provides a name that the user supplies as a job
attribute with the job. The jobName attribute is not necessarily
unique, even for one user, let alone across users.
3.5.1 The Job Submission ID specifications
This section specifies the formats for each of the registered Job
Submission Ids. This format is used by the JmJobSubmissionIDTypeTC.
Each job submission ID is a fixed-length, 48-octet printable US-ASCII
[US-ASCII] coded character string containing no control characters,
consisting of the following fields:
octet 1: The format letter identifying the format. The
US-ASCII characters '0-9', 'A-Z', and 'a-z' are assigned
in order giving 62 possible formats.
octets 2-40: A 39-character, US-ASCII trailing SPACE
filled field specified by the format letter, if the data
is less than 39 ASCII characters.
octets 41-48: A sequential or random US-ASCII number to
make the ID quasi-unique.
If the client does not supply a job submission ID in the job
submission protocol, then the agent SHALL assign a job submission ID
using any of the standard formats that are reserved for the agent.
Clients SHALL not use formats that are reserved for agents and agents
SHALL NOT use formats that are reserved for clients, in order to
reduce conflicts in ID generation. See the description for which
formats are reserved for clients or for agents.
Registration of additional formats may be done following the
procedures described in Section 3.7.3.
The format values defined at the time of completion of this
specification are:
Format
Letter Description
------ ------------
'0' Job Owner generated by the server/device
octets 2-40: The last 39 bytes of the jmJobOwner object.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the agent.
This format is reserved for agents.
NOTE - Clients wishing to use a job submission ID that
incorporates the job owner, SHALL use format '8', not
format '0'.
'1' Job Name
octets 2-40: The last 39 bytes of the jobName attribute.
octets 41-48: The US-ASCII 8-decimal-digit random number
assigned by the client.
This format is reserved for clients.
'2' Client MAC address
octets 2-40: The client MAC address: in hexadecimal with
each nibble of the 6 octet address being '0'-'9' or
'A' - 'F' (uppercase only). Most significant octet first.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'3' Client URL
octets 2-40: The last 39 bytes of the client URL [URI-spec].
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'4' Job URI
octets 2-40: The last 39 bytes of the URI [URI-spec]
assigned by the server or device to the job when the job
was submitted for processing.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the agent.
This format is reserved for agents.
'5' POSIX User Number
octets 2-40: The last 39 bytes of a user number, such as
POSIX user number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'6' User Account Number
octets 2-40: The last 39 bytes of the user account number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'7' DTMF Incoming FAX routing number
octets 2-40: The last 39 bytes of the DTMF incoming FAX
routing number.
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients.
'8' Job Owner supplied by the client
octets 2-40: The last 39 bytes of the job owner name (that the
agent returns in the jmJobOwner object).
octets 41-48: The US-ASCII 8-decimal-digit sequential number
assigned by the client.
This format is reserved for clients. See format '0' which is
reserved for agents.
'9' Host Name
octets 2-40: The last 39 bytes of the host name with trailing
SPACES that submitted the job to this server/device using
a protocol, such as LPD [RFC1179] which includes the host
name in the job submission protocol.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the job id generated by the submitting
server (configuration 3) or the client (configuration 1
and 2), such as in the LPD protocol.
This format is reserved for clients.
'A' AppleTalk Protocol
octets 2-40: Contains the AppleTalk printer name, with the
first character of the name in octet 2. AppleTalk printer
names are a maximum of 31 characters. Any unused portion
of this field shall be filled with spaces.
octets 41-48: '00000XXX', where 'XXX' is the 3-digit US-ASCII
decimal representation of the Connection Id.
This format is reserved for agents.
'B' NetWare PServer
octets 2-40: Contains the Directory Path Name as recorded by
the Novell File Server in the queue directory. If the
string is less than 40 octets, the left-most character in
the string shall appear in octet position 2. Otherwise,
only the last 39 bytes shall be included. Any unused
portion of this field shall be filled with spaces.
octets 41-48: '000XXXXX' The US-ASCII representation of the
Job Number as per the NetWare File Server Queue Management
Services.
This format is reserved for agents.
'C' Server Message Block protocol (SMB)
octets 2-40: Contains a decimal (US-ASCII coded)
representation of the 16 bit SMB Tree Id field, which
uniquely identifies the connection that submitted the job
to the printer. The most significant digit of the numeric
string shall be placed in octet position 2. All unused
portions of this field shall be filled with spaces. The
SMB Tree Id has a maximum value of 65,535.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the File Handle returned from the device
to the client in response to a Create Print File command.
This format is reserved for agents.
'D' Transport Independent Printer/System Interface (TIP/SI)
octets 2-40: Contains the Job Name from the Job Control-Start
Job (JC-SJ) command. If the Job Name portion is less than
40 octets, the left-most character in the string shall
appear in octet position 2. Any unused portion of this
field shall be filled with spaces. Otherwise, only the
last 39 bytes shall be included.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
See format '1' reserved to clients to submit job name ids
in which they supply octets 41-48.
'E' IPDS on the MVS or VSE platform
octets 2-40: Contains bytes 2-27 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'01'. Bytes 28-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
'F' IPDS on the VM platform
octets 2-40: Contains bytes 2-31 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'02'. Bytes 32-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the file name.
'G' IPDS on the OS/400 platform
octets 2-40: Contains bytes 2-36 of the XOH Define Group
Boundary Group ID triplet. Octet position 2 MUST carry
the value x'03'. Bytes 37-40 MUST be filled with spaces.
octets 41-48: The US-ASCII 8-decimal-digit leading zero
representation of the jmJobIndex assigned by the agent.
This format is reserved for agents, since the agent supplies
octets 41-48, though the client supplies the job name.
NOTE - the job submission id is only intended to be unique between a
limited set of clients for a limited duration of time, namely, for
the life time of the job in the context of the server or device that
is processing the job. Some of the formats include something that is
unique per client and a random number so that the same job submitted
by the same client will have a different job submission id. For
other formats, where part of the id is guaranteed to be unique for
each client, such as the MAC address or URL, a sequential number
SHOULD suffice for each client (and may be easier for each client to
manage). Therefore, the length of the job submission id has been
selected to reduce the probability of collision to an extremely low
number, but is not intended to be an absolute guarantee of
uniqueness. None-the-less, collisions are remotely possible, but
without bad consequences, since this MIB is intended to be used only
for monitoring jobs, not for controlling and managing them.
3.6 Internationalization Considerations
This section describes the internationalization considerations
included in this MIB.
3.6.1 Text generated by the server or device
There are a few objects and attributes generated by the server or
device that SHALL be represented using the Universal Multiple-Octet
Coded Character Set (UCS) [ISO-10646]. These objects and attributes
are always supplied (if implemented) by the agent, not by the job
submitting client:
1. jmGeneralJobSetName object
2. processingMessage(6) attribute
3. physicalDevice(32) (name value) attribute
The character encoding scheme for representing these objects and
attributes SHALL be UTF-8 as REQUIRED by RFC2277 [RFC2277]. The '
JmUTF8StringTC' textual convention is used to indicate UTF-8 text
strings.
NOTE - For strings in 7-bit US-ASCII, there is no impact since the
UTF-8 representation of 7-bit ASCII is identical to the US-ASCII
[US-ASCII] encoding.
The text contained in the processingMessage(6) attribute is generated
by the server/device. The natural language for the
processingMessage(6) attribute is identified by the
processingMessageNaturalLangTag(7) attribute. The
processingMessageNaturalLangTag(7) attribute uses the
JmNaturalLanguageTagTC textual convention which SHALL conform to the
language tag mechanism specified in RFC1766 [RFC1766]. The
JmNaturalLanguageTagTC value is the same as the IPP [ipp-model] '
naturalLanguage' attribute syntax. RFC1766 specifies that a US-
ASCII string consisting of the natural language followed by an
optional country field. Both fields use the same two-character codes
from ISO 639 [ISO-639] and ISO 3166 [ISO-3166], respectively, that
are used in the Printer MIB for identifying language and country.
Examples of the values of the processingMessageNaturalLangTag(7)
attribute include:
1. 'en' for English
2. 'en-us' for US English
3. 'fr' for French
4. 'de' for German
3.6.2 Text supplied by the job submitter
All of the objects and attributes represented by the 'JmJobStringTC'
textual-convention are either (1) supplied in the job submission
protocol by the client that submits the job to the server or device
or (2) are defaulted by the server or device if the job submitting
client does not supply values. 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. In any case, the
resulting coded character set representation SHOULD be UTF-8 [UTF-8],
but SHALL be one in which the code positions from 0 to 31 is not
used, 32 to 127 is US-ASCII [US-ASCII], 127 is not unused, and the
remaining code positions 128 to 255 represent single-byte or multi-
byte graphic characters structured according to ISO 2022 [ISO-2022]
or are unused.
The coded character set SHALL be one of the ones registered with IANA
[IANA] and SHALL be identified by the jobCodedCharSet attribute in
the jmJobAttributeTable for the job. 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 attribute or (2) not return the jobCodedCharSet
attribute for the job.
Examples of coded character sets which meet this criteria for use as
the value of the jobCodedCharSet job attribute are: US-ASCII [US-
ASCII], ISO 8859-1 (Latin-1) [ISO-8859-1], any ISO 8859-n, HP Roman8,
IBM Code Page 850, Windows Default 8-bit set, UTF-8 [UTF-8], US-ASCII
plus JIS X0208-1990 Japanese [JIS X0208], US-ASCII plus GB2312-1980
PRC Chinese [GB2312]. See the IANA registry of coded character sets
[IANA charsets].
Examples of coded character sets which do not meet this criteria are:
national 7-bit sets conforming to ISO 646 (except US-ASCII), EBCDIC,
and ISO 10646 (Unicode) [ISO-10646]. In order to represent Unicode
characters, the UTF-8 [UTF-8] encoding scheme SHALL be used which has
been assigned the MIBenum value of '106' by IANA.
The jobCodedCharSet attribute uses the imported 'CodedCharSet'
textual-convention from the Printer MIB [printmib].
The natural language for attributes represented by the textual-
convention JmJobStringTC is identified either (1) by the
jobNaturalLanguageTag(9) attribute or is keywords in US-English (as
in IPP). A monitoring application SHOULD attempt to localize
keywords into the language of the user by means of some lookup
mechanism. If the keyword value is not known to the monitoring
application, the monitoring application SHOULD assume that the value
is in the natural language specified by the job's
jobNaturalLanguageTag(9) attribute and SHOULD present the value to
its user as is. The jobNaturalLanguageTag(9) attribute value SHALL
have the same syntax and semantics as the
processingMessageNaturalLangTag(7) attribute, except that the
jobNaturalLanguageTag(9) attribute identifies the natural language of
attributes supplied by the job submitter instead of the natural
language of the processingMessage(6) attribute. See Section 3.6.1.
3.6.3 'DateAndTime' for representing the date and time
This MIB also contains objects that are represented using the
DateAndTime textual convention from SMIv2 [SMIv2-TC]. The job
management application SHALL display such objects in the locale of
the user running the monitoring application.
3.7 IANA and PWG Registration Considerations
This MIB does not require any additional registration schemes for
IANA, but does depend on registration schemes that other Internet
standards track specifications have set up. The names of these IANA
registration assignments under the /in-notes/iana/assignments/ path:
1.printer-language-numbers - used as enums in the documentFormat(38)
attribute
2.media-types - uses as keywords in the documentFormat(38) attribute
3.character-sets - used as enums in the jobCodedCharSet(8) attribute
The Printer Working Group (PWG) will handle registration of
additional enums after approving this standard, according to the
procedures described in this section:
3.7.1 PWG Registration of enums
This specification uses textual conventions to define enumerated
values (enums) and bit values. Enumerations (enums) and bit values
are sets of symbolic values defined for use with one or more objects
or attributes. All enumeration sets and bit value sets are assigned
a symbolic data type name (textual convention). As a convention the
symbolic name ends in "TC" for textual convention. These
enumerations are defined at the beginning of the MIB module
specification.
The PWG has defined several type of enumerations for use in the Job
Monitoring MIB and the Printer MIB [print-mib]. These types differ
in the method employed to control the addition of new enumerations.
Throughout this document, references to "type n enum", where n can be
1, 2 or 3 can be found in the various tables. The definitions of
these types of enumerations are:
3.7.1.1 Type 1 enumerations
Type 1 enumeration: All the values are defined in the Job Monitoring
MIB specification (RFCfor the Job Monitoring MIB). Additional
enumerated values require a new RFC.
There are no type 1 enums in the current document.
3.7.1.2 Type 2 enumerations
Type 2 enumeration: An initial set of values are defined in the Job
Monitoring MIB specification. Additional enumerated values are
registered with the PWG.
The following type 2 enums are contained in the current document:
1. JmUTF8StringTC
2. JmJobStringTC
3. JmNaturalLanguageTagTC
4. JmTimeStampTC
5. JmFinishingTC [same enum values as IPP "finishing" attribute]
6. JmPrintQualityTC [same enum values as IPP "print-quality"
attribute]
7. JmTonerEconomyTC
8. JmMediumTypeTC
9. JmJobSubmissionIDTypeTC
10.JmJobCollationTypeTC
11.JmJobStateTC [same enum values as IPP "job-state" attribute]
12.JmAttributeTypeTC
For those textual conventions that have the same enum values as the
indicated IPP Job attribute are simultaneously registered by the PWG
for use with IPP [ipp-model] and the Job Monitoring MIB.
3.7.1.3 Type 3 enumeration
Type 3 enumeration: An initial set of values are defined in the Job
Monitoring MIB specification. Additional enumerated values are
registered through the PWG without PWG review.
There are no type 3 enums in the current document.
3.7.2 PWG Registration of type 2 bit values
This memo contains the following type 2 bit value textual-
conventions:
1. JmJobServiceTypesTC
2. JmJobStateReasons1TC
3. JmJobStateReasons2TC
4. JmJobStateReasons3TC
5. JmJobStateReasons4TC
These textual-conventions are defined as bits in an Integer so that
they can be used with SNMPv1 SMI. The jobStateReasonsN (N=1..4)
attributes are defined as bit values using the corresponding
JmJobStateReasonsNTC textual-conventions.
The registration of JmJobServiceTypesTC and JmJobStateReasonsNTC bit
values follow the procedures for a type 2 enum as specified in
Section 3.7.1.2.
3.7.3 PWG Registration of Job Submission Id Formats
In addition to enums and bit values, this specification assigns a
single ASCII digit or letter to various job submission ID formats.
See the JmJobSubmissionIDTypeTC textual-convention and the object.
The registration of JobSubmissionID format numbers follows the
procedures for a type 2 enum as specified in Section 3.7.1.2.
3.7.4 PWG Registration of MIME types/sub-types for document-formats
The documentFormat(38) attribute has MIME type/sub-type values for
indicating document formats which IANA registers as "media type"
names. The values of the documentFormat(38) attribute are the same
as the corresponding Internet Printing Protocol (IPP) "document-
format" Job attribute values [ipp-model].
3.8 Security Considerations
3.8.1 Read-Write objects
All objects are read-only, greatly simplifying the security
considerations. If another MIB augments this MIB, that MIB might
accept SNMP Write operations to objects in that MIB whose effect is
to modify the values of read-only objects in this MIB. However, that
MIB SHALL have to support the required access control in order to
achieve security, not this MIB.
3.8.2 Read-Only Objects In Other User's Jobs
The security policy of some sites MAY be that unprivileged users can
only get the objects from jobs that they submitted, plus a few
minimal objects from other jobs, such as the
jmJobKOctetsPerCopyRequested and jmJobKOctetsProcessed objects, so
that a user can tell how busy a printer is. Other sites MAY allow
all unprivileged users to see all objects of all jobs. This MIB does
not require, nor does it specify how, such restrictions would be
implemented. A monitoring application SHOULD enforce the site
security policy with respect to returning information to an
unprivileged end user that is using the monitoring application to
monitor jobs that do not belong to that user, i.e., the jmJobOwner
object in the jmJobTable does not match the user's user name.
An operator is a privileged user that would be able to see all
objects of all jobs, independent of the policy for unprivileged
users.
3.9 Notifications
This MIB does not specify any notifications. For simplicity,
management applications are expected to poll for status. The
jmGeneralJobPersistence and jmGeneralAttributePersistence objects
assist an application to determine the polling rate. The resulting
network traffic is not expected to be significant.
4 MIB specification
The following pages constitute the actual Job Monitoring MIB.
Job-Monitoring-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, enterprises,
Integer32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
-- The following textual-conventions are needed to implement
-- certain attributes, but are not needed to compile this MIB.
-- They are provided here for convenience:
-- hrDeviceIndex FROM HOST-RESOURCES-MIB
-- DateAndTime FROM SNMPv2-TC
-- PrtInterpreterLangFamilyTC,
-- CodedCharSet FROM Printer-MIB
-- Use the enterprises arc assigned to the PWG which is pwg(2699).
-- Group all PWG mibs under mibs(1).
jobmonMIB MODULE-IDENTITY
LAST-UPDATED "9902190000Z"
ORGANIZATION "Printer Working Group (PWG)"
CONTACT-INFO
"Tom Hastings
Postal: Xerox Corp.
Mail stop ESAE-231
701 S. Aviation Blvd.
El Segundo, CA 90245
Tel: (301)333-6413
Fax: (301)333-5514
E-mail: hastings@cp10.es.xerox.com
Send questions and comments to the Printer Working Group (PWG)
using the Job Monitoring Project (JMP) Mailing List:
jmp@pwg.org
For further information, including how to subscribe to the
jmp mailing list, access the PWG web page under 'JMP':
http://www.pwg.org/
Implementers of this specification are encouraged to join the
jmp mailing list in order to participate in discussions on any
clarifications needed and registration proposals being reviewed
in order to achieve consensus."
DESCRIPTION
"The MIB module for monitoring job in servers, printers, and
other devices.
Version: 1.0"
-- revision history
REVISION "9902190000Z"
DESCRIPTION " This version published as RFC2707"
::= { enterprises pwg(2699) mibs(1) jobmonMIB(1) }
-- Textual conventions for this MIB module
JmUTF8StringTC ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"To facilitate internationalization, this TC represents
information taken from the ISO/IEC IS 10646-1 character set,
encoded as an octet string using the UTF-8 character encoding
scheme.
See section 3.6.1, entitled: 'Text generated by the server or
device'."
SYNTAX OCTET STRING (SIZE (0..63))
JmJobStringTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"To facilitate internationalization, this TC represents
information using any coded character set registered by IANA as
specified in section 3.7. While it is recommended that the
coded character set be UTF-8 [UTF-8], the actual coded
character set SHALL be indicated by the value of the
jobCodedCharSet(8) attribute for the job.
See section 3.6.2, entitled: 'Text supplied by the job
submitter'."
SYNTAX OCTET STRING (SIZE (0..63))
JmNaturalLanguageTagTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An IETF RFC1766-compliant 'language tag', with zero or more
sub-tags that identify a natural language. While RFC1766
specifies that the US-ASCII values are case-insensitive, this
MIB specification requires that all characters SHALL be lower
case in order to simplify comparing by management applications.
See section 3.6.1, entitled: 'Text generated by the server or
device' and section 3.6.2, entitled: 'Text supplied by the job
submitter'."
SYNTAX OCTET STRING (SIZE (0..63))
JmTimeStampTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The simple time at which an event took place. The units are
in seconds since the system was booted.
NOTE - JmTimeStampTC is defined in units of seconds, rather
than 100ths of seconds, so as to be simpler for agents to
implement (even if they have to implement the 100ths of a
second to comply with implementing sysUpTime in MIB-II[mib-
II].)
NOTE - JmTimeStampTC is defined as an Integer32 so that it can
be used as a value of an attribute, i.e., as a value of the
jmAttributeValueAsInteger object. The TimeStamp textual-
convention defined in SNMPv2-TC [SMIv2-TC] is defined as an
APPLICATION 3 IMPLICIT INTEGER tag, not an Integer32 which is
defined in SNMPv2-SMI [SMIv2-TC] as UNIVERSAL 2 IMPLICIT
INTEGER, so cannot be used in this MIB as one of the values of
jmAttributeValueAsInteger."
SYNTAX INTEGER (0..2147483647)
JmJobSourcePlatformTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The source platform type that can submit jobs to servers or
devices in any of the 3 configurations.
This is a type 2 enumeration. See Section 3.7.1.2. See also
IANA operating-system-names registry."
SYNTAX INTEGER {
other(1),
unknown(2),
sptUNIX(3), -- UNIX
sptOS2(4), -- OS/2
sptPCDOS(5), -- DOS
sptNT(6), -- NT
sptMVS(7), -- MVS
sptVM(8), -- VM
sptOS400(9), -- OS/400
sptVMS(10), -- VMS
sptWindows(11), -- Windows
sptNetWare(12) -- NetWare
}
JmFinishingTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The type of finishing operation.
These values are the same as the enum values of the IPP
'finishings' attribute. See Section 3.7.1.2.
other(1),
Some other finishing operation besides one of the specified
or registered values.
unknown(2),
The finishing is unknown.
none(3),
Perform no finishing.
staple(4),
Bind the document(s) with one or more staples. The exact
number and placement of the staples is site-defined.
punch(5),
Holes are required in the finished document. The exact
number and placement of the holes is site-defined. The
punch specification MAY be satisfied (in a site- and
implementation-specific manner) either by
drilling/punching, or by substituting pre-drilled media.
cover(6),
Select a non-printed (or pre-printed) cover for the
document. This does not supplant the specification of a
printed cover (on cover stock medium) by the document
itself.
bind(7)
Binding is to be applied to the document; the type and
placement of the binding is product-specific.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
other(1),
unknown(2),
none(3),
staple(4),
punch(5),
cover(6),
bind(7)
}
JmPrintQualityTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Print quality settings.
These values are the same as the enum values of the IPP 'print-
quality' attribute. See Section 3.7.1.2.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
other(1), -- Not one of the specified or registered
-- values.
unknown(2), -- The actual value is unknown.
draft(3), -- Lowest quality available on the printer.
normal(4), -- Normal or intermediate quality on the
-- printer.
high(5) -- Highest quality available on the printer.
}
JmPrinterResolutionTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Printer resolutions.
Nine octets consisting of two 4-octet SIGNED-INTEGERs followed
by a SIGNED-BYTE. The values are the same as those specified
in the Printer MIB [printmib]. The first SIGNED-INTEGER
contains the value of prtMarkerAddressabilityXFeedDir. The
second SIGNED-INTEGER contains the value of
prtMarkerAddressabilityFeedDir. The SIGNED-BYTE contains the
value of prtMarkerAddressabilityUnit.
Note: the latter value is either 3 (tenThousandsOfInches) or 4
(micrometers) and the addressability is in 10,000 units of
measure. Thus the SIGNED-INTEGERs represent integral values in
either dots-per-inch or dots-per-centimeter.
The syntax is the same as the IPP 'printer-resolution'
attribute. See Section 3.7.1.2."
SYNTAX OCTET STRING (SIZE(9))
JmTonerEconomyTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Toner economy settings.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
unknown(2), -- unknown.
off(3), -- Off. Normal. Use full toner.
on(4) -- On. Use less toner than normal.
}
JmBooleanTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Boolean true or false value.
This is a type 2 enumeration. See Section 3.7.1.2."
SYNTAX INTEGER {
unknown(2), -- unknown.
false(3), -- FALSE.
true(4) -- TRUE.
}
JmMediumTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Identifies the type of medium.
other(1),
The type is neither one of the values listed in this
specification nor a registered value.
unknown(2),
The type is not known.
stationery(3),
Separately cut sheets of an opaque material.
transparency(4),
Separately cut sheets of a transparent material.
envelope(5),
Envelopes that can be used for conventional mailing
purposes.
envelopePlain(6),
Envelopes that are not preprinted and have no windows.
envelopeWindow(7),
Envelopes that have windows for addressing purposes.
continuousLong(8),
Continuously connected sheets of an opaque material
connected along the long edge.
continuousShort(9),
Continuously connected sheets of an opaque material
connected along the short edge.
tabStock(10),
Media with tabs.
multiPartForm(11),
Form medium composed of multiple layers not pre-attached to
one another; each sheet MAY be drawn separately from an
input source.
labels(12),
Label-stock.
multiLayer(13)
Form medium composed of multiple layers which are pre-
attached to one another, e.g. for use with impact printers.
This is a type 2 enumeration. See Section 3.7.1.2. These enum
values correspond to the keyword name strings of the
prtInputMediaType object in the Printer MIB [print-mib]. There
is no printer description attribute in IPP/1.0 that represents
these values."
SYNTAX INTEGER {
other(1),
unknown(2),
stationery(3),
transparency(4),
envelope(5),
envelopePlain(6),
envelopeWindow(7),
continuousLong(8),
continuousShort(9),
tabStock(10),
multiPartForm(11),
labels(12),
multiLayer(13)
}
JmJobCollationTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value is the type of job collation. Implementations that
don't support multiple documents or don't support multiple
copies SHALL NOT support the uncollatedDocuments(5) value.
This is a type 2 enumeration. See Section 3.7.1.2. See also
Section 3.4, entitled 'Monitoring Job Progress'."
SYNTAX INTEGER {
other(1),
unknown(2),
uncollatedSheets(3), -- sheets within each document copy
-- are not collated: 1 1 ..., 2 2 ...,
-- No corresponding value of IPP
-- "multiple-document-handling"
collatedDocuments(4), -- internal collated sheets,
-- documents: A, B, A, B, ...
-- Corresponds to IPP "multiple-
-- document-handling"='separate-
-- documents-collated-copies'
uncollatedDocuments(5) -- internal collated sheets,
-- documents: A, A, ..., B, B, ...
-- Corresponds to IPP "multiple-
-- document-handling"='separate-
-- documents-uncollated-copies'
}
JmJobSubmissionIDTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Identifies the format type of a job submission ID.
Each job submission ID is a fixed-length, 48-octet printable
US-ASCII [US-ASCII] coded character string containing no
control characters, consisting of the fields defined in section
3.5.1.
This is like a type 2 enumeration. See section 3.7.3."
SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z'
JmJobStateTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The current state of the job (pending, processing, completed,
etc.). The following figure shows the normal job state
transitions:
+----> canceled(7)
/
+---> pending(3) -------> processing(5) ------+------> completed(9)
| ^ ^ \
--->+ | | +----> aborted(8)
| v v /
+---> pendingHeld(4) processingStopped(6) ---+
Figure 4 - Normal Job State Transitions
Normally a job progresses from left to right. Other state
transitions are unlikely, but are not forbidden. Not shown are
the transitions to the canceled state from the pending,
pendingHeld, and processingStopped states.
Jobs in the pending, processing, and processingStopped states
are called 'active', while jobs in the pendingHeld, canceled,
aborted, and completed states are called 'inactive'. Jobs
reach one of the three terminal states: completed, canceled, or
aborted, after the jobs have completed all activity, and all
MIB objects and attributes have reached their final values for
the job.
These values are the same as the enum values of the IPP 'job-
state' job attribute. See Section 3.7.1.2.
unknown(2),
The job state is not known, or its state is indeterminate.
pending(3),
The job is a candidate to start processing, but is not yet
processing.
pendingHeld(4),
The job is not a candidate for processing for any number of
reasons but will return to the pending state as soon as the
reasons are no longer present. The job's
jmJobStateReasons1 object and/or jobStateReasonsN (N=2..4)
attributes SHALL indicate why the job is no longer a
candidate for processing. The reasons are represented as
bits in the jmJobStateReasons1 object and/or
jobStateReasonsN (N=2..4) attributes. See the
JmJobStateReasonsNTC (N=1..4) textual convention for the
specification of each reason.
processing(5),
One or more of:
1. the job is using, or is attempting to use, one or
more purely software processes that are analyzing,
creating, or interpreting a PDL, etc.,
2. the job is using, or is attempting to use, one or
more hardware devices that are interpreting a PDL,
making mark on a medium, and/or performing finishing,
such as stapling, etc., OR
3. (configuration 2) the server has made the job ready
for printing, but the output device is not yet printing
it, either because the job hasn't reached the output
device or because the job is queued in the output
device or some other spooler, awaiting the output
device to print it.
When the job is in the processing state, the entire job
state includes the detailed status represented in the
device MIB indicated by the hrDeviceIndex value of the
job's physicalDevice attribute, if the agent implements
such a device MIB.
Implementations MAY, though they NEED NOT, include
additional values in the job's jmJobStateReasons1 object
to indicate the progress of the job, such as adding the
jobPrinting value to indicate when the device is actually
making marks on a medium and/or the processingToStopPoint
value to indicate that the server or device is in the
process of canceling or aborting the job.
processingStopped(6),
The job has stopped while processing for any number of
reasons and will return to the processing state as soon
as the reasons are no longer present.
The job's jmJobStateReasons1 object and/or the job's
jobStateReasonsN (N=2..4) attributes MAY indicate why the
job has stopped processing. For example, if the output
device is stopped, the deviceStopped value MAY be
included in the job's jmJobStateReasons1 object.
NOTE - When an output device is stopped, the device
usually indicates its condition in human readable form
at the device. The management application can obtain
more complete device status remotely by querying the
appropriate device MIB using the job's deviceIndex
attribute(s), if the agent implements such a device MIB
canceled(7),
A client has canceled the job and the server or device
has completed canceling the job AND all MIB objects and
attributes have reached their final values for the job.
While the server or device is canceling the job, the
job's jmJobStateReasons1 object SHOULD contain the
processingToStopPoint value and one of the
canceledByUser, canceledByOperator, or canceledAtDevice