The job monitoring textual-conventions and explanation Module: JOB-MONNITORING-TC Editor: Tom Hastings Date: 25-October-1995 Version: 0.7 File: jobtc.doc, .psr, .ps, .txt, .mib This specification contains the job monitoring textual-conventions which are a companion specification to the job monitoring MIB (see files: jobmon.doc, .psr, .ps, .txt, .mib). This specification also includes the explanatory information about the job monitoring MIB and should be read first. It is intended that this specification can be updated and re-issued as needed with more textual conventions and/or explanatory material, while the job monitoring MIB remains with no change, making the MIB more stable. The job monitoring MIB specifies objects for monitoring print jobs, including accounting. The object groups are arranged so that an additional MIB may be developed that supports multifunction jobs (print, scan, FAX, etc.), including scan-only jobs. Such a MIB is intended to augment the job monitoring MIB. The objects in the job monitoring MIB are a subset of the job and document attributes of the ISO 10175 Document Printing Application (DPA) standard (Final text, May 1995). Multiple documents per job are supported as an optional feature (as in ISO DPA). The full ISO DPA standard is available via anonymous ftp at ftp-out.external.hp.com in directory: /pub/snmpmib/dpa in WORD (.doc), ASN.1 (.asn) and PostScript(tm) (.ps) forms. Job Management not in this MIB This job monitoring MIB does not contain job management functions, such as cancelling jobs, promoting jobs, etc. If job management is desired, a separate MIB should be developed so that the conformance to that job management MIB would be kept separate from the conformance to this job monitoring MIB. Then some implementations will implement the job monitoring MIB and others could implement both the job monitoring MIB and the job management MIB. The job management MIB would provides writeable objects that augment the job and document tables in the job monitoring MIB. Such writeable objects could provide the means to cancel jobs, cancel documents, promote jobs (to be printed next), etc. The Multifunction Job Model The specification of objects for scan and FAX is just beginning, and needs agreement on a multifunction (MF) job model first. The current thinking on the model for MF jobs is that simple jobs, called simple jobs, need to be able to specify more than one MF device. Therefore, a job needs to specify both scanner and printer attributes. Consequently, the printer-centric attributes in the current proposal (ISO DPA is currently printer-centric) do not need to be changed to be more general. Instead, scanner-centric attributes need to be added to this MIB (and to ISO DPA). An out-bound FAX is modeled as a (dial-out) printer, so that a dial-up and FAX-specific attributes need to be added to the MIB (and to ISO DPA). Multiple outbound FAX destinations can be specified by a single multi-valued attribute with a value for each phone number (needs a MIB table). Thus multiple FAX destinations can be handled by a simple job. An in-bound FAX is modeled as a (dial-in) scanner. For more complex systems, more complex jobs, called complex jobs, contain other jobs that perform separate steps of a multifunction job. Each such contained job can be separately scheduled, so that one such sub-job could be a scan job and another could be a print job. A complex job could contain multiple source jobs and multiple destination jobs of different types. For example, a comlex job could contain a (simple) scan-to-file job, a file-to-print job, and a file-to-FAX job. A (very) complex job might contain other complex jobs, as well as simple jobs. A conformance option for both simple and complex jobs is that a job can contain multiple documents. Suitable levels of conformance need to be specified for these four combinations. Object Naming The prefix for all objects in this MIB is "jm" for "job monitoring". The names of each MIB object, as well as the specifications for each MIB object, are copied directly from the corresponding job or document attribute specification in the ISO DPA standard. The DPA attribute names are changed to conform to MIB conventions, by: 1. Preceding each attribute with the prefix "jm". 2. Beginning each job attribute with the word "Job", if the DPA job attribute did not already being with the "job-". The "Job" first word also corresponds to the name of the table. 3. Beginning each document attribute with the prefix "Doc", if the DPA document attribute did not aleady begin with "doc-". DPA document attributes beginning with "document-" have been changed to begin with "Doc" for consistency. The "Doc" first word also corresponds to the name of the table. 4. Remove each hyphen (-) between words and upcase the first letter of each word. The order of the MIB objects follows the order of the corresponding DPA attributes, except that OPTIONAL MIB objects have been moved to separate groups, since each group must be all MANDATORY or all OPTIONAL. Folowing SMI guidelines, each table is contained in a separate group. Since all objects are in tables in this MIB, so that multiple devices can be supported (same as in RFV 1759), the names of the groups and the names of the tables are the same. Attributes that are print-specific are put into a separate conditionally mandatory group, so that a future multifunction MIB could represent a scanner-only device, without requiring the print-specific group. The first line of each DESCRIPTION is the name of the corresponding ISO DPA attribute. NOTE - For a few attributes it is necessary to include some specific MIB specification, along with the ISO DPA specification. In such cases, the MIB-specific text precedes the ISO DPA attribute name and ISO DPA specification text which, in this case, starts with "ISO DPA:". In certain cases, the ISO DPA specification is augmented with words inside square brackets ([]) so that it is clear what is taken from ISO DPA and what has been added by this MIB specification. The descriptions of new attributes (not from ISO DPA) are extensions will be proposed to the ISO DPA committee, so they are labeled "(extension)". At the end of each standard value description, the ISO DPA Object Identifier (OID) name is indicated in parentheses, e.g., "(id-val-job- state-printing)". Terminology In this MIB specification, the terms "client" and "server" shall mean the entity that submitted the job and the entity that accepted the job, respectively (via some other protocol than SNMP and not using this MIB). The term "server" shall mean a printer or a software spooling system. These terms are the same as those used in ISO DPA and the specifications that have been copied from ISO DPA into this MIB specification. The terms "management station" and "SNMP agent" (or more simply "agent") refer to the entity that submits SNMP requests and the entity that accepts SNMP requests according to this MIB specification, respectively. Thus it should be clear in this MIB specification when the specification is referring to (1) the entities that submitted/accepted the print job using some other protocol versus (2) those entities that are querying the jobs and responding to job queries using SNMP and this MIB. The following diagram shows the relationship between the client and server and between the management station and the agent. See also the diagrams in the Printer MIB (RFC 1759). +--------+ +--------------------+ | client | | management station | +--------+ +--------------------+ ^ ^ job | | submission | | SNMP protocol | | v v +--------------------------+----------+ | server (printer or a | agent | | (spooling) print service | | + + + The term "object" is used in this MIB as in all SNMP MIBs to mean a data element in a MIB. The term "attribute" is used in ISO DPA for the same concept as an object in an SNMP MIB. Goals and Requirements for the Job Monitoring MIB The goals and requirements for the job monitoring MIB are: 1. Provide a limited set (29) of mandatory job and document attributes for a printer, plus a comparable number (41) optional job and document attributes, not a complete set of job and document attributes for a print spooling system. This mandatory subset is intended to be used with printer devices that do not include spooling; the optional subset may be used with a printer that does include spooling or with a spooling system. 2. Provide for 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, meet the needs of Windows and other PC environments for managing low-end networked devices without unnecessary overhead or complexity, while also providing for higher end printers, devices, and print systems. Since the job monitoring MIB will also be transformed into a companion DMTF MIF, the job monitoring MIB/MIF should meet the needs for managing devices using the DMTF DMI when the devices are directly connected to PCs. 3. Provide for job information after the printer has finished printing the job . This job information on completed jobs is intended to be used by: management stations that provide job status to system operators that are remote from the printer a management station that is co-located with the printer to privide an enhanced console capability end user job monitoring programs that give end users status on progress and completion of jobs during the complete life cycle of the job, including for a period after the job completes system accounting programs that copy the completed job statistics to an accounting system. Such so that accounting programs can copy the data for implementation on low-end printers that cannot rely on the print system to reliably write the accounting information when the job completes. 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). system usage statistics gathering programs that copy the completed job statistics to system usage logs 4. Provide a compatible subset of job and document attributes of the ISO DPA standard, so that coherence is maintained between the two protocols and information seen by end users and system operators. However, the job monitoring MIB is intended to be used with printers and print systems that implemented other job submitting and management protocols, such as IEEE 1284.1 (NPAP), as well as with ones that do implement ISO DPA. So nothing in the job monitoring MIB shall require implementation of the ISO DPA protocol. 5. Design this job monitoring MIB so that an addtional MIB can be specified in the future for monitoring multifunction (scan, FAX, copy, and print) jobs. Deisgn this job monitoring MIB so that the future multifunction job monitoring MIB is able to augment (rather than supersede) this MIB.A subsidiary goal is for this job monitoring MIB to be designed so that the future multifuncton MIB can be used with scan systems that do not have a printer. So nothing in the job monitoring MIB requires implementation of the printer MIB (RFC 1759), if the device or system does not have a printer. 6. Solve the security policy problem that unauthorized users cannot access job information for jobs that are not theirs. Solving the security problem requires SNMP V2 security. However, this MIB is also intended to be used with SNMP V1 by prividing essor conformance requirements when implementing V1. 7. Do not provide for additional job management functions, such as ModifyJob, CancelJob, PromoteJob, PauseJob, ResumeJob, InterruptJob. If these job management functions are desired, put them into a second job mangement MIB that augments this job monitoring MIB. Then the conformance to this job management MIB is kept distict from the conformance to such a job management MIB, since some implementations may want to only do the job monitoring MIB and others may want to implement both. The ITEF/DMTF Printer Working Group (PWG) may wish to develop both MIBs in parallel. However, this document refers only to the job monitoring MIB. 8. Provide for monitoring of jobs that clients submit (1) directly to printers (end user clients or spooling print systems acting as clients) and (2) to spooling print systems. Thus the problem of multiple client- server relationships that can exist in some print scenarios must be provided for. Fortunately, the ISO DPA provides job attributes for submission and monitoring such cascaded job scenarios. 9. Provide SNMP MIB access to jobs submitted to the printer or print system by any protocol, including printers and print systems that accept jobs using multiple protocols. 10. Only provide objects that are primarily of interest to system operators and system managers. Implication: Do not need to include some objects that ISO DPA has corresponding job and document attributes that are required for ISO DPA level 1 or level 2 conformance. Also include some attributes in the job monitoring MIB that are not ISO DPA level 1 or level 2 conformance requirements. Events Traps are generated when any of the following MIB objects change values, so that a management station can update the screen immediately, if it wishes: Job: job-priority current-job-state job-state-reasons printer-state-of-printers-assigned job-message-from-administrator Document: document-state Text Attributes There are three different kinds of text strings used in MIBs: 1. Strings that are represented as Network Virtual Terminal (NVT) ASCII and are never localized. Such strings are specified in MIBs using the SMI textual convention: DisplayString. 2. Strings that are localized by the agent according to one or more locales specified by the management station. A locale specificaion consists of a language, a territory, and a coded character set. Such strings are specified in MIBs using the SMI textual convention: InternationalDisplayString. 3. Strings that are represented in one or more coded character sets by the agent and that management stations can select which coded character set representation for the agent to return in a get by specifying the desired coded character set as an index. Such string are specified in MIBs using the (new) textual convention: CodeIndexedStringIndex that point to objects of type CodeIndexedString. See the General textual-conventions for a description of the General Current Localization group, the General Localization groupo, the General Code Indexed String group and the General Coded Char Set group in the General textual-conventions specification and module. See the General MIB for the objects in these groups that are intended to be used with many MIBs. The Job Information table and Document Information table The job information table and the document information table are like the RFC 1759 (printer MIB) alerts table, in that the printer (SNMP agent): 1. adds jobs to the job info table as the jobs are submitted to the printer (jobs are submitted to the printer via some protocol other than SNMP). Each job is indexed using the job identifier generated by the server when the job was submitted. 2. removes jobs from the job info table when they have exceeded the time that retained and completed jobs remain in the table or are deleted (by SNMP or other protocol that is outside the scope of this MIB). 3. adds documents to the document info table as the document part of each job is submitted to the printer (jobs contain one or more documents which are also submitted to the printer via some protocol other than SNMP). Each document is indexed using both the job identifier generated by the server when the job was submitted and the document sequence number which starts at 1 for the first document in a job. 4. removes document from the document info table when the containing job is removed from the table or the document is deleted (by some protocol other than SNMP using this job monitoring MIB). The SNMP management station can access job information using the job identifier generated by the printer (or print service) when the job was submitted (via some protocol other than SMNP). Jobs in the ISO DPA 'completed' state have very few job attributes, while jobs in the 'retained' state have all their job and document attributes. Implementation of the 'retained' and 'completed' states is optional in ISO DPA. ISO DPA requires that a completed job (if implemented) have at least the following attributes: job-identifier, job-owner, current-job-state (with completed value), printers-assigned, and job-state-reasons. Similarly in this MIB, a job in the 'completed' state need no longer contain most of the objects (columns) that the job contained while was in other states, including the 'retained' state. The purpose of the retained state is to permit a job to be reprinted again, while the purpose of the completed state is to keep a record of completed jobs for some implementation-defined period of time. Conforming agents shall return values for the following objects for jobs in the completed state (if the implementation-defined period is greater than 0): jmJobIdentifier jmJobOwner jmJobName jmJobCurrentState jmPrintersAssigned jmJobStateReasons Logical and physical printers The ISO DPA standard permits a software printer object containing printer attributes to represent either a logical printer, a physical printer or both. A logical printer is the abstraction that users submit jobs. The physical printer is the abstraction that operators deal with in managing the output devices. Using ISO DPA, the system administrator can create a logical printer that is associated with more than one physical printer in order to achieve load balancing across several output devices. Also the system administrator can create a number of logical printers (with different defaults) that are associated with the same physical printer(s). In ISO DPA, a client can request job attributes by specifying either a logical printer or a physical printer (see ISO DPA ListObjectAttributes operation under the get-ordered-job sub-function). When requesting jobs associated with a logical printer, the DPA server shall return all jobs that are competing for the associated physical printers, not just the jobs that were submitted to the specified logical printer. Conformance to this job monitoring MIB does not require the support of the concept of logical devices, unless the agent is suporting a servie that has the concept of logical devices. However, if logical printers are suppported this job monitoring MIB requires that the SNMP agent also return all jobs that are candidates for the physical printer(s) associated with the specified logical printer. So the high order table index for the job monitoring tables is the hrDeviceIndex from the host resources MIB (RFC 1514). Thus the device in the host resources MIB can specify a logical printer or a physical printer. RFC 1514 (host resouces MIB) already defines an OID for a printer device type. The means for indicating that a device in the host resources MIB is a logical, a physical, or both a logical-and-physical device is outside the scope of this job monitoring MIB. Logical printers might be represented by a new device type OID or by extension of the host resources MIB with a new object that augments the device type, so that any device, not just printers, could be indicated as logical or physical. However, some of the objects in the Printer MIB may not be appropriate for a logical printer, especially when the logical printer is representing more than one physical printer. Overview of the Job Monitoring MIB groups and tables Following SMI recommendations, no group contains more than one table. Since this MIB contains no scalar objects, since all objects are per- printer and, therefore, indexed by hrDeviceIndex from the host resources MIB, each group consists entirely of a single table. Therefore, there is a one to one correspondence between group names and table names. Optional tables augment mandatory tables. The jobs MIB is divided into the following groups in the following order. Legend: Group Name name of the group T type of information in the group: G general not device-type specific, so can be used by print jobs or by scan jobs (when a scan job MIB is written to augment this MIB) P printer-centric C Compliance: M mandatory C conditionally mandatory, i.e., mandatory for (spooling) print systems (as opposed to printers) O optional N number of objects in the group Table table name Description description of the group Group T C N Table Description ----- - - - ----- ----------- Job G M 16 JobInfo The mandatory job objects for Information each job (device-type independent). Devices G M 2 DevicesAssigned The table for the job that Assigned contains the hrDeviceIndex and the status of each of the physical devices to which the job has been assigned. Optional G O 11 OptionalJobInfo The optional job table that Job (augments) augments the Job table with Information additional optional job objects for each job (device-type independent). Print P C 13 PrintJobInfo The conditionally mandatory job Job (augments) table that augments the Job table Information with additional print-centric job attributes for each job, i.e., is mandatory for agents that support printers Media P O 2 MediaConsumed The media types and amounts Consumed consumed by each job. Color P O 2 ColorImpressions The colors and amounts consumed by Impressions Consumed each job. Consumed Document G M 9 DocInfo The mandatory document objects Information for each document in each job. Print P C 6 DocInfo The conditionally mandatory Document (augments) document table that augments the Information Document table with additional print-centric document attributes, i.e., mandatory for agents that support printers. Media P O 7 MediaSupported The optional media supported by Supported this (logical or physical) device. Job Alert G M 2 none The job and document job alert objects. Minimal Implementation: only 29 accessible objects A simple device need only implement the mandatory groups. If the device only contains one job at a time and a job can contain only one document, the device need implement only one row of the JobInfo, DevicesAssigned, and DocInfo tables. Thus the total number of accessible objects for a minimal implementation is only: 16+2+9+2=29 accessible objects. The total number of mandatory tables is 3, each with only one row, plus 4 tables in the General MIB (for localization and CodeIndexedStrings). Job Monitoring textual conventions The job monitoring textual conventions include type 2 and type 3 enums (see RFC 1759 for discussion of type 1, 2, and 3 enums). Therefore, only the JOB-MONITORING-TC module need be republished when a new enum value needs to be added; the JOB-MONITORING-MIB module itself does not. Type 1 enums are left in the JOB-MONITORING-MIB module itself, since adding to them is a significant change that affects all implementations. The following textual-conventions are imported from the SNMPv2 SMI (RFC 1443): DisplayString Particular subset of US-ASCII, called network virtual terminal (NVT) ASCII. Such strings are never localized. DateAndTime Date and time, including time zones RowStatus To allow management stations to create rows in tables. The following textual-conventions are imported from the General MIB: Ordinal16 1..2**15-1 (don't use sign bit) Cardinal16 0..2**15-1 (don't use sign bit) Ordinal32 1..2**31-1 (don't use sign bit) Cardinal32 0..2**31-1 (don't use sign bit) Cardinal64 0..2**63-1 (don't use sign bit) CodeIndexedStringIndex index to GenCodedStringTable for CodeIndexedStringIndex objects NOTE: The Ordinal32 and Cardinal32 have the same sizes as the host resouces (hr) MIB device indexes The following textual-conventions are imported from the Printer MIB textual conventions module (proposed to be separated from the Printer MIB when the Printer MIB is promoted to draft status): JmPrtChannelType Channel types from RFC 1759 JmPrtDocFormat Document format enums from RFC 1759 Should be a separate TC in RFC 1759 The following textual-conventions are defined here in the JOB- MONITORING-TC module: DPAJobState Job states from ISO DPA DPAJobStateReasons Job state reasons bit encoded but derived from ISO DPA DPADeviceState Printer states from ISO DPA, with states for other devices to be added (to this TC and to ISO DPA) DPADocType Document types from ISO DPA DPADocState Document states from ISO DPA DPADocOutput Document output handling bit encoded but derived from ISO DPA The types that start with DPA have enum values that are algorithmically derived from the last arc of the corresponding ISO DPA OBJECT IDENTIFIER by adding an offset of 0, 2, or 3, depending on the enum. The offset is indicated for each object in an ASN.1 comment. The bit-coded values are not algorithmically derived from the corresponding ISO DPA OBJECT IDENTIFIERS. JOB-MONITORING-TC DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, experimental FROM SNMPv2-SMI -- rfc 1442 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- rfc 1443 -- Upon publication as RFC, delete this comment and the line following -- this comment and change the reference of { printmib 103 } -- (above) to { mib-2 X }. -- This will result in changing: -- 1 3 6 1 3 54 jmJobMonTC(103) to: -- 1 3 6 1 2 1 jmJobMonTC(X) -- This will make it easier to translate prototypes to -- the standard namespace because the lengths of the OID's won't -- change. printmib OBJECT IDENTIFIER ::= { experimental 54 } jmJobMonTC MODULE-IDENTITY LAST-UPDATED "9510251230Z" ORGANIZATION "IETF/DMTF Printer Working Group (PWG)" CONTACT-INFO " Thomas N. Hastings Xerox Corporation, MS ES-AE 242 701 S. Aviation Blvd. El Segundo, CA 90245 Phone: 1+ (310)333-6413 FAX: 1+ (310)333-6342 E-Mail: hastings@cp10.es.xerox.com" DESCRIPTION "File: jobmontc.doc, .psr, .ps, .txt Version: 0.7 This textual-convention module defines textual- conventions for use with the job monitoring MIB, module: JOB-MONITORING-MIB. Also the explanatory material with this module explains the job monitoring MIB. These textual-conventions and explanations are in a separate module from the job monitoring MIB, so that they may be republished when additional enums are added or more explanatory material is added without needing to republish the job monitoring MIB, thus increasing the stability of the job monitoring MIB." ::= { printmib 103 } -- definitions of textual conventions DPAJobState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A job may be in any of the states defined by this textual- convention. When a job is in the processing or printing state, the state of the assigned printer(s) is needed to fully represent the state of the job. ISO DPA: Job-current-state Standard values are defined for the current-job-state and previous-job-state attributes of the DPA job object, as follows: unknown The job state is not known, or is indeterminate, or is not returned by the operation. (id-val-job-state-unknown) pre-processing The job has been created on the server by the create-job sub-operation of the Print request, but a Print request with a TRUE value for the job-submission-complete component of the PrintArgument has not yet been received and no document has started processing. The job maybe in the process of being checked by the server for attributes, defaults being applied, a printer being selected, etc. (id-val-job- state-pre-processing) held The job is waiting to be released for scheduling for any number of reasons as specified by the value of the job's job- state-reasons attribute. (id-val-job- state-held) pending The job's job-submission-complete attribute is TRUE since the server has received a Print request with the job-submission- complete parameter TRUE and the job is waiting to start processing on a printer. (id-val-job-state-pending) processing The server is processing the job, or 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. (id-val-job-state-processing) printing The server has completed processing the job and the output device is currently printing the job on at least one printer. That is, a print engine is either printing pages of the job, or failing in its attempt to print pages of the job because of some wait state, such as, start-wait, end-wait, needs-attention, etc. The complete job state includes the detailed status represented in the printers' printer-state attribute(s). (id-val-job-state-printing) paused The job has been paused as a result of a PauseJob operation. (id-val-job-state- paused) interrupted The job was interrupted by the InterruptJob request for an intervening job, and shall resume processing automatically once the intervening job has completed. (id-val- job-state-interrupted) terminating The job has been cancelled by a CancelJob request or aborted by the server and is in the process of terminating. The job's job- state-reasons attribute contains the reasons that the job is being terminated. (id-val-job-state-terminating) retained The job is being retained at the server as a result of the job's job-retention-period being non-zero. The job has (1) completed successfully or with warnings or errors, (2) been aborted while printing by the server, or (3) been cancelled by the CancelJob request before or during processing. The job's job-state-reasons attribute contains the reasons that the job has been retained. While in the retained state, all of the job's document data (and resources, if any) shall be retained by the server; thus a job in the retained state could be reprinted, using some means outside the scope of ISO/IEC 10175-Part 1. (id-val-job-state- retained) completed The job has: (1) completed successfully or with warnings or errors, (2) been aborted by the server while printing, or (3) been cancelled by the CancelJob request, AND the job's: (1) job-retention-period was zero or has expired, or (2) job-discard-time has arrived. The job's job-state-reasons attribute contains the reason(s) that the job has been completed. While in the completed state, a job's document data (and resources if any) need not be retained by the server; thus a job in the completed state could not be reprinted. The length of time that a job may be in this state, before transitioning to unknown, is implementation-dependent. However, servers that implement the completed job-state shall retain, as a minimum, the following attributes for any job in the completed state: job-identifier, job-owner, job-name, current-job-state, printers-assigned, and job-state-reasons. (id-val-job-state-completed) This is a type 2 enum." SYNTAX INTEGER { other(1), unknown(2), -- the following enum values are +2 pre-processing(3),-- of the final arc of the ISO DPA pending(6), -- id-val-job-state-xxx OID processing(7), interrupted(8), retained(11), held(12), paused(13), terminating(14), completed(17), printing(18) } DPAJobStateReasons ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This representation is bit-encoded, so that multiple reasons can occur at once. Each bit corresponds to an ISO DPA OID for the same reason. ISO DPA: Job-state-reasons This attribute identifies the reason or reasons that the job is in the held, terminating, retained, or completed state. The server shall indicate the particular reason(s) by setting the value of the job-state-reasons attribute. When the job is not in any of these states, the server shall set the value of the job-state-reasons attribute to the empty set. The following standard values are defined: documents- 0x1 The complete job has been accepted by the needed server (the value of the job-submission- complete element was TRUE in the last Print request for the job), but the server is waiting for its files to start and/or finish being transferred before the job can be scheduled to be printed. (id-val-reasons-documents-needed) job-hold-set 0x2 The value of the job's job-hold attribute is TRUE. (id-val-reasons-job-hold-set) job-print- 0x4 The value of the job's job-print-after after- attribute has specified a time specified specification that has not yet occurred. (id-val-reasons-job-print-after-specified) required- 0x8 At least one of the resources needed by resources- the job, such as media, fonts, resource not-ready objects, etc., is not ready on any of the physical printer's for which the job is a candidate. (id-val-reasons-required- resources-not-ready) successful- 0x10 The job completed successfully. (id-val- completion reasons-successful completion) completed- 0x20 The job completed with warnings. (id- with- val-reasons-completed-with-warnings) warnings completed- 0x40 The job completed with errors (and with-errors possibly warnings too). (id-val-reasons- completed-with-errors) cancelled- 0x80 The job was cancelled by the user using by-user the CancelJob request. (id-val-reasons- cancelled-by-user) cancelled- 0x100 The job was cancelled by the operator by-operator using the CancelJob request. (id-val- reasons-cancelled-by-operator) aborted-by- 0x200 The job was aborted by the system. (id- system val-reasons-aborted-by-system) logfile- 0x400 The job's logfile is pending file transfer. pending (id-val-reasons-logfile-pending) logfile- 0x800 The job's logfile is being transferred. transferring (id-val-reasons-logfile-transferring) This is the equivalent of a type 2 enum." SYNTAX INTEGER(0..4095) DPADeviceState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "States for other devices will be added to both this textual-convention and to ISO DPA. [NOTE - The name was changed from the ISO DPA printer-state to DPADeviceState, since it is anticipated to add any additional states that scanners, faxes, and other multifunction devices might need.] When a job is in the processing or printing state, the state of the assigned printer(s) is needed to fully represent the state of the job. ISO DPA: Printer-state Standard values are defined for the printer-state printer attribute, as follows: unknown The printer state is not known, or is indeterminate, or is not returned by the operation (id-val-printer-state-unknown) idle The printer is ready to accept jobs, but none have been scheduled on it. (id-val-printer- state-idle) printing The printer is currently printing a job (id- val-printer-state-printing) needs-attention The printer needs human attention (no special skills required). This state typically includes adding paper, clearing a jam, changing the medium, etc. (id-val-printer- state-needs-attention) paused The operator has (temporarily) paused the printer, by means outside the scope of this part of ISO/IEC 10175. (id-val-printer-state- paused) shutdown The printer has been taken out of service, (for a long time), whether for repairs or others reasons. The printer's message generic attribute may be used to record a reason and estimated time for return to service (id-val- printer-state-shutdown) job-start-wait The currently processing job was started with the job-start-wait attribute set, and is awaiting operator intervention or time-out. (id-val-printer-state-job-start-wait) job-end-wait The currently processing job was started with the job-end-wait attribute set, and is awaiting operator intervention or time-out. (id-val-printer-state-job-end-wait) job-password-wait The currently processing job was started with the job-password attribute set, and is awaiting the operator or user to enter the password supplied by the job-password attribute. (id-val-printer-state-job- password-wait) needs-key- The printer needs the attention of a key operator operator. Key operator functions are printer- specific, but typically include adding toner or developer, or attending to a hardware fault. (id-val-printer-state-needs-key- operator) connecting- The server has scheduled a job on the printer to-printer and is in the process of connecting to a shared network printer (and may not be able to actually start printing the job for an arbitrarily long time depending on the usage of the printer by other servers). (id-val- printer-state-connecting-to-printer) timed-out The server was able to connect to the printer (or is always connected), but was unable to get a response from the printer in the time specified by the printer's printer-timeout- period attribute. (id-val-printer-state- timed-out) This is a type 2 enum." SYNTAX INTEGER { other(1), unknown(2), -- the following enum values are +2 idle(3), -- of the final arc of the ISO DPA printing(4), -- id-val-printer-state-xxx OID needs-attention(5), paused(6), shutdown(7), job-start-wait(8), job-end-wait(9), needs-key-operator(10), job-password-wait(11), timed-out(12), connecting-to-printer(13) } DPADocType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Jobs contain documents. Documents may be printable, font, or resource objects. ISO DPA: Document-type The following standard values are defined: printable Specifies that this document is to be printed on the assigned printer. (id-val-document-type- printable) font Specifies that this document is a font resource which may be required by one or more of the printable documents associated with the print- job. See the font object class. (id-val- document-type-font) resource Specifies that this document contains resource data, of some type other than font, which may be required to print one or more of the printable documents associated with the print-job. See the resource object class. (id-val-document- type-resource) This is a type 2 enum." SYNTAX INTEGER { other(1), unknown(2), printable(3), -- the following enum values are +3 font(4), -- of the final arc of the ISO DPA resource(5) -- id-val-document-type-xxx OID } DPADocState ::=TEXTUAL-CONVENTION STATUS current DESCRIPTION "The following standard values are defined: transfer- The server has created the document object, but pending the data transfer of the document data has not started or completed (id-val-document-state- transfer-pending) pending The server has received the document data and the document is waiting for processing to begin. The job may already be in the processing state, if the job's job-scheduling attribute in not after-complete (see the current-job-state and job-scheduling job attributes. (id-val-document-state-pending) processing The server has started processing this document, or has made the document ready for printing, but the output device is not yet printing it, either because the document hasn't reached the output device or because the document is queued in the output device or some other spooler, awaiting the output device to print it. (id-val-document-state-processing) printing The server has completed processing the document and the output device is currently printing the document on at least one printer. That is, a print engine is either printing pages of the document, or failing in its attempt to print pages of the document because of some wait state, such as, start-wait, end- wait, needs-attention, etc. The complete document state includes the detailed status represented in the printers' printer-state attribute(s). (id-val-document-state-printing) completed The server has completed printing this document. The job may still be in the printing state, or may be in the retained state. (id- val-document-state-completed) This is a type 2 enum." SYNTAX INTEGER { other(1), unknown(2), transfer-pending(3), -- the following enum values pending(4), -- are +3 of the final arc of processing(5), -- the ISO DPA completed(6), -- id-val-document-state-xxx OID printing(7) } DPADocOutput ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This object is bit coded, so that multiple document output requests may be made for the document. Each bit corresponds to one of the ISO DPA output OIDs. ISO DPA: Output This attribute identifies the output processing for the media on which the document is to be printed. The following standard values are defined: Page-Collate 0x1 This value specifies that the pages of a document are to be in sequence, when multiple copies of the document are specified by the copy-count attribute (possibly up to some implementation- defined maximum number of copies). Whether this effect is achieved by placing copies of the document in multiple output bins or in the same output bin with implementation-defined document separation is implementation- dependent. Also whether it is achieved by making multiple passes over the document or by using an output sorter is implementation-dependent (id-val- output-page-collate) No Page-Collate 0x2 This value specifies that the copies of the pages of a document are to follow one another when multiple copies are specified by the copy-count attribute. That is, if 3 copies are specified, three copies of page 1 are printed then three copies of page 2, etc., and no collating of these pages is desired. This may be useful in some implementations where multiple copies requires re-interpretation of the document format and the document contains some compute intensive pages (such as images) (id-val-output-no page-collate) Decollate 0x4 The parts of a multi-part form are to be separated and sorted into stacks for each part (id-val-output- decollate) No Decollate 0x8 The parts of a multi-part form are to remain intact (id-val-output-no decollate) Burst 0x10 Continuous media is to be separated into individual sheets, generally by bursting along perforations (id-val- output-burst) No Burst 0x20 Continuous media is to remain continuous, no bursting is desired (id-val-output-no burst) Stacking-Default 0x40 A site-defined output-stacking operation is to be applied (id-val- output-stacking-default) This is the equivalent of a type 2 enum." SYNTAX INTEGER(0..255) END Change History The following changes were made from version 0.6, dated 15-Sep-1995 to make version 0.7, dated 18-Oct-1995: 1. Divided the textual conventions and the MIB into separate files: jobtc.doc, .psr, .ps, .txt and jobmon.doc, .psr, .ps, .txt, .mib, respectively. 2. Added the terms: attribute and object to the terminology section. 3. Indicated that this MIB is only for print jobs and that another MIB needs to be developed for scan jobs and multifunction jobs that augments this MIB. 4. Changed the emphasis of the goals from spooling system to printer, while still supporting both, as discussed at the September 18 IETF/DMTF PWG meeting. 5. Added a number of programs that could use the job monitoring MIB, besides a management station: co-located networked console, end-user job monitoring program, system accounting program, and system usage statistics gathering program. 6. Clarified implementation of ISO DPA is not required for using this MIB. 7. Clarified that multifunction needs to be added in the future, but as a separate MIB, not additions to this MIB. So this MIB is for monitoring of print jobs and is the base for other job monitoring MIBs. 8. Improved the Text Attributes section to discribe the three types of strings: DisplayString, InternatationDisplayString and CodeIndexedString. 9. Changed ASCIIName to DisplayString from SNMPv2 SMI. 10. Changed the name of the current localization index from jmGenCurrLocalization to jmGenCurrentLocalization Index, so that the word current is spelled out and to follow the convention that all index objects end in the word Index (even though RFC 1759 did not follow that convention). 11. Changed the textual convention from CodedStringIndex to CodeIndexedStringIndex and the table from CodedStringTable to CodeIndexedStringTable to be a more meaningful name, since each row has an coded character set (a code) index in it. So the table contains objects of type CodeIndexedString that are pointed to by objects of type CodeIndexedStringIndex. 12. Described how a management station could write new localized strings and add new locales, if supported by a (high end) agent (optional). 13. Explained how a high end management station could modify localized InternationalDisplayString objects, if a high end agent allows. Also how an even higher end management station could add a whole new localization by adding a row to the Localization table, changing the current localization to the new localization and then writing new values into all InternationDisplayString objects in any MIB, if the agent allows. 14. Added example of CodeIndexedStringTable. 15. Added more coded character sets to the list of coded character sets that agents may support: Shift JIS, EUC, GB 2312, and the other parts of ISO 8859. Also relaxed the requirement that the agent need support all four standard sets from ISO DPA (ASCII, T61String, ISO Latin1, and Unicode). Changed so that only ASCII and ISO Latin1 are required and the others are optional. 16. Clarified that the agent conformance requirement is that each string be in one of the list of coded character sets, but that all such strings don't have to be in the same set. 17. Specified the objects that a conforming agent shall return actual values for when the job enters the completed state, if the agent supports the completed state at all: jmJobIdentifier, jmJobOwner, jmJobName, jmJobCurrentState, jmPrintersAssigned, and jmJobStateReasons. 18. Clarified that implementation of logical printers is optional. 19. Changed description of how devices are identified from an enum to using new OIDs assigned to be used with hrDevicedType object from host resources MIB. 20. Added groups, so that each table is in a separate group, following SMI guidelines. Changed the group names so that they are the same as the tables. So added group Devices Assigned and moved the DevicesAssignedTable from the Job Information group into it. 21. Created a new table and conditionally mandatory group for print- specific attributes, called Print Job Information, so that the mandatory job attributes are entirely device-independent and do not require spooling. There are now a conditionally mandatory group for (spooling) print systems, as opposed to printer, and an optional group that is device-independent. Attributes that a spooling server needs are included only in the optional group. Then the job monitoring MIB can be used by another job MIB oriented towards, say, scan jobs. Indicated whether each group was general (G) or printer-specific (P) 22. Re-ordered the enum values for DPAJobState so that the values are +2 from the final arcs of the DPA id-val-job-state OIDs, even though the DPA OIDs are not consecutive. 23. Moved the description of the text objects and their groups (General Current Localization group, the General Localization groupo, the General Code Indexed String group and the General Coded Char Set group) from this specification to the general textual-conventions specification, since these textual conventions and objects are intended to be used by many MIBs. 24. Added ranges to INTEGER for DPAJobStateReasons and DPADocOutput bit vector. Used the same technique as RFC 1759. 26. Changed the name of the OptionalPrintJob and OptionalPrintDoc groups/tables to PrintJob and PrintDoc, and changed them to conditionally mandatory, i.e., mandatory if the agent is supporting a (spooling) print system (as opposed to a printer). [End of job monitoring textual-conventions and explanation]