tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2707

Informational
Pages: 114
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: PRINTMIB

Job Monitoring MIB - V1.0

Part 1 of 5, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          R. Bergman
Request for Comments: 2707                             Dataproducts Corp.
Category: Informational                                  T. Hastings, Ed.
                                                        Xerox Corporation
                                                              S. Isaacson
                                                             Novell, Inc.
                                                                 H. Lewis
                                                                IBM Corp.
                                                            November 1999


                       Job Monitoring MIB - V1.0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   This MIB module uses an unconventional scheme for modeling management
   information (on top of the SNMP model) which is unique to this MIB.
   The IESG recommends against using this document as an example for the
   design of future MIBs.

   The "Printer Working Group" industry consortium is not an IETF
   working group, and the IETF does not recognize the Printer Working
   Group as a standards-setting body.  This document is being published
   solely to provide information to the Internet community regarding a
   MIB that might be deployed in the marketplace. Publication of this
   document as an RFC is not an endorsement of this MIB.

Abstract

   This document provides a printer industry standard SNMP MIB for (1)
   monitoring the status and progress of print jobs (2) obtaining
   resource requirements before a job is processed, (3) monitoring
   resource consumption while a job is being processed and (4)
   collecting resource accounting data after the completion of a job.
   This MIB is intended to be implemented (1) in a printer or (2) in a
   server that supports one or more printers.  Use of the object set is
   not limited to printing.  However, support for services other than
   printing is outside the scope of this Job Monitoring MIB.  Future

Page 2 
   extensions to this MIB may include, but are not limited to, fax
   machines and scanners.

Table of Contents

   1   INTRODUCTION                                                    4
     1.1 Types of Information in the MIB                               5
     1.2 Types of Job Monitoring Applications                          6
   2   TERMINOLOGY AND JOB MODEL                                       7
     2.1 System Configurations for the Job Monitoring MIB             11
       2.1.1   Configuration 1 - client-printer                       11
       2.1.2   Configuration 2 - client-server-printer - agent in the
               server                                                 12
       2.1.3   Configuration 3 - client-server-printer - client
               monitors printer agent and server                      14
   3   MANAGED OBJECT USAGE                                           15
     3.1 Conformance Considerations                                   15
       3.1.1   Conformance Terminology                                16
       3.1.2   Agent Conformance Requirements                         16
         3.1.2.1   MIB II System Group objects                        17
         3.1.2.2   MIB II Interface Group objects                     17
         3.1.2.3   Printer MIB objects                                17
       3.1.3   Job Monitoring Application Conformance Requirements    17
     3.2 The Job Tables and the Oldest Active and Newest Active
         Indexes                                                      18
     3.3 The Attribute Mechanism and the Attribute Table(s)           20
       3.3.1   Conformance of Attribute Implementation                21
       3.3.2   Useful, 'Unknown', and 'Other' Values for Objects and
               Attributes                                             21
       3.3.3   Index Value Attributes                                 22
       3.3.4   Data Sub-types and Attribute Naming Conventions        22
       3.3.5   Single-Value (Row) Versus Multi-Value (MULTI-ROW)
               Attributes                                             23
       3.3.6   Requested Objects and Attributes                       23
       3.3.7   Consumption Attributes                                 24
       3.3.8   Attribute Specifications                               24
       3.3.9   Job State Reason bit definitions                       43
         3.3.9.1   JmJobStateReasons1TC specification                 44
         3.3.9.2   JmJobStateReasons2TC specification                 47
         3.3.9.3   JmJobStateReasons3TC specification                 51
         3.3.9.4   JmJobStateReasons4TC specification                 51
     3.4 Monitoring Job Progress                                      51
     3.5 Job Identification                                           55
       3.5.1   The Job Submission ID specifications                   56
     3.6 Internationalization Considerations                          60
       3.6.1   Text generated by the server or device                 61
       3.6.2   Text supplied by the job submitter                     61
       3.6.3   'DateAndTime' for representing the date and time       63

Top      ToC       Page 3 
     3.7 IANA and PWG Registration Considerations                     63
       3.7.1   PWG Registration of enums                              63
         3.7.1.1   Type 1 enumerations                                64
         3.7.1.2   Type 2 enumerations                                64
         3.7.1.3   Type 3 enumeration                                 64
       3.7.2   PWG Registration of type 2 bit values                  65
       3.7.3   PWG Registration of Job Submission Id Formats          65
       3.7.4   PWG Registration of MIME types/sub-types for document-
               formats                                                65
     3.8 Security Considerations                                      65
       3.8.1   Read-Write objects                                     65
       3.8.2   Read-Only Objects In Other User's Jobs                 66
     3.9 Notifications                                                66
   4   MIB SPECIFICATION                                              67
     Textual conventions for this MIB module                          68
       JmUTF8StringTC                                                 68
       JmJobStringTC                                                  68
       JmNaturalLanguageTagTC                                         68
       JmTimeStampTC                                                  69
       JmJobSourcePlatformTypeTC                                      69
       JmFinishingTC                                                  70
       JmPrintQualityTC                                               71
       JmPrinterResolutionTC                                          71
       JmTonerEconomyTC                                               72
       JmBooleanTC                                                    72
       JmMediumTypeTC                                                 72
       JmJobCollationTypeTC                                           74
       JmJobSubmissionIDTypeTC                                        74
       JmJobStateTC                                                   75
       JmAttributeTypeTC                                              78
       JmJobServiceTypesTC                                            81
       JmJobStateReasons1TC                                           83
       JmJobStateReasons2TC                                           83
       JmJobStateReasons3TC                                           83
       JmJobStateReasons4TC                                           84
     The General Group (MANDATORY)                                    84
       jmGeneralJobSetIndex   (Int32(1..32767))                       85
       jmGeneralNumberOfActiveJobs   (Int32(0..))                     86
       jmGeneralOldestActiveJobIndex   (Int32(0..))                   86
       jmGeneralNewestActiveJobIndex   (Int32(0..))                   86
       jmGeneralJobPersistence   (Int32(15..))                        87
       jmGeneralAttributePersistence   (Int32(15..))                  87
       jmGeneralJobSetName   (UTF8String63)                           88
     The Job ID Group (MANDATORY)                                     88
       jmJobSubmissionID   (OCTET STRING(SIZE(48)))                   89
       jmJobIDJobSetIndex   (Int32(0..32767))                         90
       jmJobIDJobIndex   (Int32(0..))                                 91
     The Job Group (MANDATORY)                                        91

Top      ToC       Page 4 
       jmJobIndex   (Int32(1..))                                      92
       jmJobState   (JmJobStateTC)                                    92
       jmJobStateReasons1   (JmJobStateReasons1TC)                    93
       jmNumberOfInterveningJobs   (Int32(-2..))                      93
       jmJobKOctetsPerCopyRequested   (Int32(-2..))                   94
       jmJobKOctetsProcessed   (Int32(-2..))                          94
       jmJobImpressionsPerCopyRequested   (Int32(-2..))               95
       jmJobImpressionsCompleted   (Int32(-2..))                      96
       jmJobOwner   (JobString63)                                     96
     The Attribute Group (MANDATORY)                                  97
       jmAttributeTypeIndex   (JmAttributeTypeTC)                     98
       jmAttributeInstanceIndex   (Int32(1..32767))                   99
       jmAttributeValueAsInteger   (Int32(-2..))                      99
       jmAttributeValueAsOctets   (Octets63)                         100
   5   APPENDIX A - IMPLEMENTING THE JOB LIFE CYCLE                  104
   6   APPENDIX B - SUPPORT OF JOB SUBMISSION PROTOCOLS              105
   7   REFERENCES                                                    105
   8   NOTICES                                                       108
   9   AUTHORS' ADDRESSES                                            109
   10  INDEX                                                         111
   11  Full Copyright Statement                                      114

1  Introduction

   This specification defines an official Printer Working Group (PWG)
   [PWG] standard SNMP MIB for the monitoring of jobs on network
   printers.  This specification is being published as an IETF
   Information Document for the convenience of the Internet community.
   In consultation with the IETF Application Area Directors, it was
   concluded that this MIB specification properly belongs as an
   Information document, because this MIB monitors a service node on the
   network, rather than a network node proper.

   The Job Monitoring MIB is intended to be implemented by an agent
   within a printer or the first server closest to the printer, where
   the printer is either directly connected to the server only or the
   printer does not contain the job monitoring MIB agent.  It is
   recommended that implementations place the SNMP agent as close as
   possible to the processing of the print job.  This MIB applies to
   printers with and without spooling capabilities.  This MIB is
   designed to be compatible with most current commonly-used job
   submission protocols.  In most environments that support high
   function job submission/job control protocols, like ISO DPA [iso-
   dpa], those protocols would be used to monitor and manage print jobs
   rather than using the Job Monitoring MIB.

Top      ToC       Page 5 
   The Job Monitoring MIB consists of a General Group, a Job Submission
   ID Group, a Job Group, and an Attribute Group.  Each group is a
   table.  All accessible objects are read-only.  The General Group
   contains general information that applies to all jobs in a job set.
   The Job Submission ID table maps the job submission ID that the
   client uses to identify a job to the jmJobIndex that the Job
   Monitoring Agent uses to identify jobs in the Job and Attribute
   tables.  The Job table contains the MANDATORY integer job state and
   status objects.  The Attribute table consists of multiple entries per
   job that specify (1) job and document identification and parameters,
   (2) requested resources, and (3) consumed resources during and after
   job processing/printing.  A larger number of job attributes are
   defined as textual conventions that an agent SHALL return if the
   server or device implements the functionality so represented and the
   agent has access to the information.

1.1 Types of Information in the MIB

   The job MIB is intended to provide the following information for the
   indicated Role Models in the Printer MIB [print-mib] (Appendix D -
   Roles of Users).

      User:

         Provide the ability to identify the least busy printer.  The
         user will be able to determine the number and size of jobs
         waiting for each printer.  No attempt is made to actually
         predict the length of time that jobs will take.

         Provide the ability to identify the current status of the
         user's job (user queries).

         Provide a timely indication that the job has completed and
         where it can be found.

         Provide error and diagnostic information for jobs that did not
         successfully complete.

      Operator:

         Provide a presentation of the state of all the jobs in the
         print system.

         Provide the ability to identify the user that submitted the
         print job.

         Provide the ability to identify the resources required by each
         job.

Top      ToC       Page 6 
         Provide the ability to define which physical printers are
         candidates for the print job.

         Provide some idea of how long each job will take.  However,
         exact estimates of time to process a job is not being
         attempted.  Instead, objects are included that allow the
         operator to be able to make gross estimates.

      Capacity Planner:

         Provide the ability to determine printer utilization as a
         function of time.

         Provide the ability to determine how long jobs wait before
         starting to print.

      Accountant:

         Provide information to allow the creation of a record of
         resources consumed and printer usage data for charging users or
         groups for resources consumed.

         Provide information to allow the prediction of consumable usage
         and resource need.

   The MIB supports printers that can contain more than one job at a
   time, but still be usable for low end printers that only contain a
   single job at a time.  In particular, the MIB supports the needs of
   Windows and other PC environments for managing low-end direct-connect
   (serial or parallel) and networked devices without unnecessary
   overhead or complexity, while also providing for higher end systems
   and devices.

1.2 Types of Job Monitoring Applications

   The Job Monitoring MIB is designed for the following types of
   monitoring applications:

        1. Monitor a single job starting when the job is submitted and
           ending a defined period after the job completes.  The Job
           Submission ID table provides the map to find the specific job
           to be monitored.

        2. Monitor all 'active' jobs in a queue, which this
           specification generalizes to a "job set".  End users may use
           such a program when selecting a least busy printer, so the
           MIB is designed for such a program to start up quickly and
           find the information needed quickly without having to read

Top      ToC       Page 7 
           all (completed) jobs in order to find the active jobs.
           System operators may also use such a program, in which case
           it would be running for a long period of time and may also be
           interested in the jobs that have completed.  Finally such a
           program may be used to provide an enhanced console and
           logging capability.

        3. Collect resource usage for accounting or system utilization
           purposes that copy the completed job statistics to an
           accounting system. It is recognized that depending on
           accounting programs to copy MIB data during the job-retention
           period is somewhat unreliable, since the accounting program
           may not be running (or may have crashed).  Such a program is
           also expected to keep a shadow copy of the entire Job
           Attribute table including completed, canceled, and aborted
           jobs which the program updates on each polling cycle.  Such a
           program polls at the rate of the persistence of the Attribute
           table.  The design is not optimized to help such an
           application determine which jobs are completed, canceled, or
           aborted.  Instead, the application SHOULD query each job that
           the application's shadow copy shows was not complete,
           canceled, or aborted at the previous poll cycle to see if it
           is now complete or canceled, plus any new jobs that have been
           submitted.

   The MIB provides a set of objects that represent a compatible subset
   of job and document attributes of the ISO DPA standard [iso-dpa] and
   the Internet Printing Protocol (IPP) [ipp-model], so that coherence
   is maintained between these two protocols and the information
   presented to end users and system operators by monitoring
   applications.  However, the job monitoring MIB is intended to be used
   with printers that implement other job submitting and management
   protocols, such as IEEE 1284.1 (TIPSI) [tipsi], as well as with ones
   that do implement ISO DPA.  Thus the job monitoring MIB does not
   require implementation of either the ISO DPA or IPP protocols.

   The MIB is designed so that an additional MIB(s) can be specified in
   the future for monitoring multi-function (scan, FAX, copy) jobs as an
   augmentation to this MIB.

2  Terminology and Job Model

   This section defines the terms that are used in this specification
   and the general model for jobs in alphabetical order.

Top      ToC       Page 8 
      NOTE - Existing systems use conflicting terms, so these terms are
      drawn from the ISO 10175 Document Printing Application (DPA)
      standard [iso-dpa].  For example, PostScript systems use the term
      session for what is called a job in this specification and the
      term job to mean what is called a document in this specification.

   Accounting Application:  The SNMP management application that copies
   job information to some more permanent medium so that another
   application can perform accounting on the data for Accountants, Asset
   Managers, and Capacity Planners use.

   Agent:  The network entity that accepts SNMP requests from a monitor
   or accounting application and provides access to the instrumentation
   for managing jobs modeled by the management objects defined in the
   Job Monitoring MIB module for a server or a device.

   Attribute:  A name, value-pair that specifies a job or document
   instruction, a status, or a condition of a job or a document that has
   been submitted to a server or device.  A particular attribute NEED
   NOT be present in each job instance.  In other words, attributes are
   present in a job instance only when there is a need to express the
   value, either because (1) the client supplied a value in the job
   submission protocol, (2) the document data contained an embedded
   attribute, or (3) the server or device supplied a default value.  An
   agent MAY represent an attribute as an entry (row) in the Attribute
   table in this MIB in which entries are present only when necessary.
   Attributes are identified in this MIB by an enum.

   Client:  The network entity that end users use to submit jobs to
   spoolers, servers, or printers and other devices, depending on the
   configuration, using any job submission protocol over a serial or
   parallel port to a directly-connected device or over the network to a
   networked-connected device.

   Device:  A hardware entity that (1) interfaces to humans, such as a
   device that produces marks on paper or scans marks on paper to
   produce an electronic representation, (2) accesses digital media,
   such as CD-ROMs, or (3) interfaces electronically to another device,
   such as sends FAX data to another FAX device.

   Document:  A sub-section within a job that contains print data and
   document instructions that apply to just the document.

   Document Instruction:  An instruction specifying how to process the
   document.  Document instructions MAY be passed in the job submission
   protocol separate from the actual document data, or MAY be embedded
   in the document data or a combination, depending on the job
   submission protocol and implementation.

Top      ToC       Page 9 
   End User:  A user that uses a client to submit a print job.  See
   "user".

   Impression:  For a print job, an impression is the passage of the
   entire side of a sheet by the marker, whether or not any marks are
   made and independent of the number of passes that the side makes past
   the marker.  Thus a four pass color process counts as a single
   impression, as does highlight color.  Impression counters count all
   kinds:  monochrome, highlight color, and full process color, while
   full color counters only count full color impressions, and high light
   color counters only count high light color impressions.

   One-sided processing involves one impression per sheet.  Two-sided
   processing involves two impressions per sheet.  If a two-sided
   document has an odd number of pages, the last sheet still counts as
   two impressions, if that sheet makes two passes through the marker or
   the marker marks on both sides of a sheet in a single pass.  Two-up
   printing is the placement of two logical pages on one side of a sheet
   and so is still a single impression.  See "page" and "sheet".

   NOTE - Since impressions include blank sides, it is suggested that
   accounting application implementers consider charging for sheets,
   rather than impressions, possibly using the value of the sides
   attribute to select different charges for one-sided versus two-sided
   printing, since some users may think that impressions don't include
   blank sides.

   Internal Collation: The production of the sheets for each document
   copy performed within the printing device by making multiple passes
   over either the source or an intermediate representation of the
   document.

   Job:  A unit of work whose results are expected together without
   interjection of unrelated results.  A job contains one or more
   documents.

   Job Accounting:  The activity of a management application of
   accessing the MIB and recording what happens to the job during and
   after the processing of the job.

   Job Instruction:  An instruction specifying how, when, or where the
   job is to be processed.  Job instructions MAY be passed in the job
   submission protocol or MAY be embedded in the document data or a
   combination depending on the job submission protocol and
   implementation.

Top      ToC       Page 10 
   Job Monitoring (using SNMP):  The activity of a management
   application of accessing the MIB and (1) identifying jobs in the job
   tables being processed by the server, printer or other devices, and
   (2) displaying information to the user about the processing of the
   job.

   Job Monitoring Application:  The SNMP management application that End
   Users, and System Operators use to monitor jobs using SNMP.  A
   monitor MAY be either a separate application or MAY be part of the
   client that also submits jobs.  See "monitor".

   Job Set:  A group of jobs that are queued and scheduled together
   according to a specified scheduling algorithm for a specified device
   or set of devices.  For implementations that embed the SNMP agent in
   the device, the MIB job set normally represents all the jobs known to
   the device, so that the implementation only implements a single job
   set.  If the SNMP agent is implemented in a server that controls one
   or more devices, each MIB job set represents a job queue for (1) a
   specific device or (2) set of devices, if the server uses a single
   queue to load balance between several devices.  Each job set is
   disjoint; no job SHALL be represented in more than one MIB job set.

   Monitor:  Short for Job Monitoring Application.

   Page:  A page is a logical division of the original source document.
   Number up is the imposition of more than one page on a single side of
   a sheet.  See "impression" and "sheet" and "two-up".

   Proxy:  An agent that acts as a concentrator for one or more other
   agents by accepting SNMP operations on the behalf of one or more
   other agents, forwarding them on to those other agents, gathering
   responses from those other agents and returning them to the original
   requesting monitor.

   Queuing:  The act of a device or server of ordering (queuing) the
   jobs for the purposes of scheduling the jobs to be processed.

   Printer:  A device that puts marks on media.

   Server:  A network entity that accepts jobs from clients and in turn
   submits the jobs to printers and other devices that may be directly
   connected to the server via a serial or parallel port or may be on
   the network.  A server MAY be a printer supervisor control program,
   or a print spooler.

   Sheet:  A sheet is a single instance of a medium, whether printing on
   one or both sides of the medium.  See "impression" and "page".

Top      ToC       Page 11 
   SNMP Information Object:  A name, value-pair that specifies an
   action, a status, or a condition in an SNMP MIB.  Objects are
   identified in SNMP by an OBJECT IDENTIFIER.

   Spooler:  A server that accepts jobs, spools the data, and decides
   when and on which printer to print the job.  A spooler is a client to
   a printer or a printer supervisor, depending on implementation.

   Spooling:  The act of a device or server of (1) accepting jobs and
   (2) writing the job's attributes and document data on to secondary
   storage.

   Stacked:  When a media sheet is placed in an output bin of a device.

   Supervisor:  A server that contains a control program that controls a
   printer or other device.  A supervisor is a client to the printer or
   other device.

   System Operator:  A user that uses a monitor to monitor the system
   and carries out tasks to keep the system running.

   System Administrator:  A user that specifies policy for the system.

   Two-up:  The placement of two pages on one side of a sheet so that
   each side or impressions counts as two pages.  See "page" and
   "sheet".

   User:  A person that uses a client or a monitor.  See "end user".

2.1 System Configurations for the Job Monitoring MIB

   This section enumerates the three configurations in which the Job
   Monitoring MIB is intended to be used.  To simplify the pictures, the
   devices are shown as printers.  See section 1.1 entitled "Types of
   Information in the MIB".

   The diagram in the Printer MIB [print-mib] entitled: "One Printer's
   View of the Network" is assumed for this MIB as well.  Please refer
   to that diagram to aid in understanding the following system
   configurations.

2.1.1 Configuration 1 - client-printer

   In the client-printer configuration 1, the client(s) submit jobs
   directly to the printer, either by some direct connect, or by network
   connection.

Top      ToC       Page 12 
   The job submitting client and/or monitoring application monitor jobs
   by communicating directly with an agent that is part of the printer.
   The agent in the printer SHALL keep the job in the Job Monitoring MIB
   as long as the job is in the printer, plus a defined time period
   after the job enters the completed state in which accounting programs
   can copy out the accounting data from the Job Monitoring MIB.

                  all         end-user     ######## SNMP query
               +-------+     +--------+    ---- job submission
               |monitor|     | client |
               +---#---+     +--#--+--+
                   #            #  |
                   # ############  |
                   # #             |
            +==+===#=#=+==+        |
            |  | agent |  |        |
            |  +-------+  |        |
            |   PRINTER   <--------+
            |             | Print Job Delivery Channel
            |             |
            +=============+

   Figure 2-1 - Configuration 1 - client-printer - agent in the printer

   The Job Monitoring MIB is designed to support the following
   relationships (not shown in Figure 2-1):
        1. Multiple clients MAY submit jobs to a printer.
        2. Multiple clients MAY monitor a printer.
        3. Multiple monitors MAY monitor a printer.
        4. A client MAY submit jobs to multiple printers.
        5. A monitor MAY monitor multiple printers.

2.1.2 Configuration 2 - client-server-printer - agent in the server

   In the client-server-printer configuration 2, the client(s) submit
   jobs to an intermediate server by some network connection, not
   directly to the printer.  While configuration 2 is included, the
   design center for this MIB is configurations 1 and 3.

   The job submitting client and/or monitoring application monitor jobs
   by communicating directly with:

      A Job Monitoring MIB agent that is part of the server (or a front
      for the server)

Top      ToC       Page 13 
   There is no SNMP Job Monitoring MIB agent in the printer in
   configuration 2, at least that the client or monitor are aware.  In
   this configuration, the agent SHALL return the current values of the
   objects in the Job Monitoring MIB both for jobs the server keeps and
   jobs that the server has submitted to the printer.  The Job
   Monitoring MIB agent obtains the required information from the
   printer by a method that is beyond the scope of this document.  The
   agent in the server SHALL keep the job in the Job Monitoring MIB in
   the server as long as the job is in the printer, plus a defined time
   period after the job enters the completed state in which accounting
   programs can copy out the accounting data from the Job Monitoring
   MIB.

                all          end-user
             +-------+     +----------+
             |monitor|     |  client  |     ######## SNMP query
             +---+---#     +---#----+-+     **** non-SNMP cntrl
                      #        #    |       ---- job submission
                       #       #    |
                        #      #    |
                         #=====#=+==v==+
                         | agent |     |
                         +-------+     |
                         |    server   |
                         +----+-----+--+
                      control *     |
                     **********     |
                     *              |
            +========v====+         |
            |             |         |
            |             |         |
            |   PRINTER   <---------+
            |             | Print Job Delivery Channel
            |             |
            +=============+

   Figure 2-2 - Configuration 2 - client-server-printer - agent in the
   server

   The Job Monitoring MIB is designed to support the following
   relationships (not shown in Figure 2-2):
        1. Multiple clients MAY submit jobs to a server.
        2. Multiple clients MAY monitor a server.
        3. Multiple monitors MAY monitor a server.
        4. A client MAY submit jobs to multiple servers.
        5. A monitor MAY monitor multiple servers.
        6. Multiple servers MAY submit jobs to a printer.
        7. Multiple servers MAY control a printer.

Top      ToC       Page 14 
2.1.3 Configuration 3 - client-server-printer - client monitors printer
      agent and server

   In the client-server-printer configuration 3, the client(s) submit
   jobs to an intermediate server by some network connection, not
   directly to the printer.  That server does not contain a Job
   Monitoring MIB agent.

   The job submitting client and/or monitoring application monitor jobs
   by communicating directly with:

        1. The server using some undefined protocol to monitor jobs in
           the server (that does not contain the Job Monitoring MIB) AND

        2. A Job Monitoring MIB agent that is part of the printer to
           monitor jobs after the server passes the jobs to the printer.

           In such configurations, the server deletes its copy of the
           job from the server after submitting the job to the printer
           usually almost immediately (before the job does much
           processing, if any).

   In configuration 3, the agent (in the printer) SHALL keep the values
   of the objects in the Job Monitoring MIB that the agent implements
   updated for a job that the server has submitted to the printer.  The
   agent SHALL obtain information about the jobs submitted to the
   printer from the server (either in the job submission protocol, in
   the document data, or by direct query of the server), in order to
   populate some of the objects the Job Monitoring MIB in the printer.
   The agent in the printer SHALL keep the job in the Job Monitoring MIB
   as long as the job is in the Printer, and longer in order to
   implement the completed state in which monitoring programs can copy
   out the accounting data from the Job Monitoring MIB.

Top      ToC       Page 15 
                all          end-user
             +-------+     +----------+
             |monitor|     |  client  |     ######## SNMP query
             +---+---*     +---*----+-+     **** non-SNMP query
                 #    *        *    |       ---- job submission
                 #     *       *    |
                 #      *      *    |
                 #       *=====v====v==+
                 #       |             |
                 #       |    server   |
                 #       |             |
                 #       +----#-----+--+
                 #    optional#     |
                 #   ##########     |
                 #   #              |
            +==+=v===v=+==+         |
            |  | agent |  |         |
            |  +-------+  |         |
            |   PRINTER   <---------+
            |             | Print Job Delivery Channel
            |             |
            +=============+

   Figure 2-3 - Configuration 3 - client-server-printer - client
   monitors printer agent and server

   The Job Monitoring MIB is designed to support the following
   relationships (not shown in Figure 2-3):
        1. Multiple clients MAY submit jobs to a server.
        2. Multiple clients MAY monitor a server.
        3. Multiple monitors MAY monitor a server.
        4. A client MAY submit jobs to multiple servers.
        5. A monitor MAY monitor multiple servers.
        6. Multiple servers MAY submit jobs to a printer.
        7. Multiple servers MAY control a printer.

3  Managed Object Usage

   This section describes the usage of the objects in the MIB.

3.1 Conformance Considerations

   In order to achieve interoperability between job monitoring
   applications and job monitoring agents, this specification includes
   the conformance requirements for both monitoring applications and
   agents.

Top      ToC       Page 16 
3.1.1 Conformance Terminology

   This specification uses the verbs: "SHALL", "SHOULD", "MAY", and
   "NEED NOT" to specify conformance requirements according to RFC 2119
   [RFC2119] as follows:

      "SHALL":  indicates an action that the subject of the sentence
      must implement in order to claim conformance to this specification

      "MAY":  indicates an action that the subject of the sentence does
      not have to implement in order to claim conformance to this
      specification, in other words that action is an implementation
      option

      "NEED NOT":  indicates an action that the subject of the sentence
      does not have to implement in order to claim conformance to this
      specification.  The verb "NEED NOT" is used instead of "may not",
      since "may not" sounds like a prohibition.

      "SHOULD":  indicates an action that is recommended for the subject
      of the sentence to implement, but is not required, in order to
      claim conformance to this specification.

3.1.2 Agent Conformance Requirements

   A conforming agent:

      1. SHALL implement all MANDATORY groups in this specification.

      2. SHALL implement any attributes if (1) the server or device
         supports the functionality represented by the attribute and (2)
         the information is available to the agent.

      3. SHOULD implement both forms of an attribute if it implements an
         attribute that permits a choice of INTEGER and OCTET STRING
         forms, since implementing both forms may help management
         applications by giving them a choice of representations, since
         the representation are equivalent.  See the JmAttributeTypeTC
         textual-convention.

   NOTE - This MIB, like the Printer MIB, is written following the
   subset of SMIv2 that can be supported by SMIv1 and SNMPv1
   implementations.

Top      ToC       Page 17 
3.1.2.1 MIB II System Group objects

   The Job Monitoring MIB agent SHALL implement all objects in the
   System Group of MIB-II [mib-II], whether the Printer MIB [print-mib]
   is implemented or not.

3.1.2.2 MIB II Interface Group objects

   The Job Monitoring MIB agent SHALL implement all objects in the
   Interfaces Group of MIB-II [mib-II], whether the Printer MIB [print-
   mib] is implemented or not.

3.1.2.3 Printer MIB objects

   If the agent is providing access to a device that is a printer, the
   agent SHALL implement all of the MANDATORY objects in the Printer MIB
   [print-mib] and all the objects in other MIBs that conformance to the
   Printer MIB requires, such as the Host Resources MIB [hr-mib].  If
   the agent is providing access to a server that controls one or more
   direct-connect or networked printers, the agent NEED NOT implement
   the Printer MIB and NEED NOT implement the Host Resources MIB.

3.1.3 Job Monitoring Application Conformance Requirements

   A conforming job monitoring application:

        1. SHALL accept the full syntactic range for all objects in all
           MANDATORY groups and all MANDATORY attributes that are
           required to be implemented by an agent according to Section
           3.1.2 and SHALL either present them to the user or ignore
           them.

        2. SHALL accept the full syntactic range for all attributes,
           including enum and bit values specified in this specification
           and additional ones that may be registered with the PWG and
           SHALL either present them to the user or ignore them.  In
           particular, a conforming job monitoring application SHALL not
           malfunction when receiving any standard or registered enum or
           bit values.  See Section 3.7 entitled "IANA and PWG
           Registration Considerations".

        3. SHALL NOT fail when operating with agents that materialize
           attributes after the job has been submitted, as opposed to
           when the job is submitted.

        4. SHALL, if it supports a time attribute, accept either form of
           the time attribute, since agents are free to implement either
           time form.

Top      ToC       Page 18 
3.2 The Job Tables and the Oldest Active and Newest Active Indexes

   The jmJobTable and jmAttributeTable contain objects and attributes,
   respectively, for each job in a job set.  These first two indexes
   are:
        1. jmGeneralJobSetIndex - which job set
        2. jmJobIndex - which job in the job set

   In order for a monitoring application to quickly find that active
   jobs (jobs in the pending, processing, or processingStopped states),
   the MIB contains two indexes:

        1. jmGeneralOldestActiveJobIndex - the index of the active job
           that has been in the tables the longest.

        2. jmGeneralNewestActiveJobIndex - the index of the active job
           that has been most recently added to the tables.

   The agent SHALL assign the next incremental value of jmJobIndex to
   the job, when a new job is accepted by the server or device to which
   the agent is providing access.  If the incremented value of
   jmJobIndex would exceed the implementation-defined maximum value for
   jmJobIndex, the agent SHALL 'wrap' back to 1.  An agent uses the
   resulting value of jmJobIndex for storing information in the
   jmJobTable and the jmAttributeTable about the job.

   It is recommended that the largest value for jmJobIndex be much
   larger than the maximum number of jobs that the implementation can
   contain at a single time, so as to minimize the premature re-use of a
   jmJobIndex value for a newer job while clients retain the same '
   stale' value for an older job.

   It is recommended that agents that are providing access to
   servers/devices that already allocate job-identifiers for jobs as
   integers use the same integer value for the jmJobIndex.  Then
   management applications using this MIB and applications using other
   protocols will see the same job identifiers for the same jobs.
   Agents providing access to systems that contain jobs with a job
   identifier of 0 SHALL map the job identifier value 0 to a jmJobIndex
   value that is one higher than the highest job identifier value that
   any job can have on that system.  Then only job 0 will have a
   different job-identifier value than the job's jmJobIndex value.

   NOTE - If a server or device accepts jobs using multiple job
   submission protocols, it may be difficult for the agent to meet the
   recommendation to use the job-identifier values that the server or

Top      ToC       Page 19 
   device assigns as the jmJobIndex value, unless the server/device
   assigns job-identifiers for each of its job submission protocols from
   the same job-identifier number space.

   Each time a new job is accepted by the server or device that the
   agent is providing access to AND that job is to be 'active' (pending,
   processing, or processingStopped, but not pendingHeld), the agent
   SHALL copy the value of the job's jmJobIndex to the
   jmGeneralNewestActiveJobIndex object.  If the new job is to be '
   inactive' (pendingHeld state), the agent SHALL not change the value
   of jmGeneralNewestActiveJobIndex object (though the agent SHALL
   assign the next incremental jmJobIndex value to the job).

   When a job transitions from one of the 'active' job states (pending,
   processing, processingStopped) to one of the 'inactive' job states
   (pendingHeld, completed, canceled, or aborted), with a jmJobIndex
   value that matches the jmGeneralOldestActiveJobIndex object, the
   agent SHALL advance (or wrap) the value to the next oldest 'active'
   job, if any.  See the JmJobStateTC textual-convention for a
   definition of the job states.

   Whenever a job transitions from one of the 'inactive' job states to
   one of the 'active' job states (from pendingHeld to pending or
   processing), the agent SHALL update the value of either the
   jmGeneralOldestActiveJobIndex or the jmGeneralNewestActiveJobIndex
   objects, or both, if the job's jmJobIndex value is outside the range
   between jmGeneralOldestActiveJobIndex and
   jmGeneralNewestActiveJobIndex.

   When all jobs become 'inactive', i.e., enter the pendingHeld,
   completed, canceled, or aborted states, the agent SHALL set the value
   of both the jmGeneralOldestActiveJobIndex and
   jmGeneralNewestActiveJobIndex objects to 0.

   NOTE - Applications that wish to efficiently access all of the active
   jobs MAY use jmGeneralOldestActiveJobIndex value to start with the
   oldest active job and continue until they reach the index value equal
   to jmGeneralNewestActiveJobIndex, skipping over any pendingHeld,
   completed, canceled, or aborted jobs that might intervene.

   If an application detects that the jmGeneralNewestActiveJobIndex is
   smaller than jmGeneralOldestActiveJobIndex, the job index has
   wrapped.  In this case, the application SHALL reset the index to 1
   when the end of the table is reached and continue the GetNext
   operations to find the rest of the active jobs.

Top      ToC       Page 20 
   NOTE - Applications detect the end of the jmAttributeTable table when
   the OID returned by the GetNext operation is an OID in a different
   MIB.  There is no object in this MIB that specifies the maximum value
   for the jmJobIndex supported by the implementation.

   When the server or device is power-cycled, the agent SHALL remember
   the next jmJobIndex value to be assigned, so that new jobs are not
   assigned the same jmJobIndex as recent jobs before the power cycle.



(page 20 continued on part 2)

Next RFC Part