rfc2707.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         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.








Bergman, et al.              Informational                     [Page 16]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


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.



Bergman, et al.              Informational                     [Page 17]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


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





Bergman, et al.              Informational                     [Page 18]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


   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.






Bergman, et al.              Informational                     [Page 19]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


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

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

3.3 The Attribute Mechanism and the Attribute Table(s)

   Attributes are similar to information objects, except that attributes
   are identified by an enum, instead of an OID, so that attributes may
   be registered without requiring a new MIB.  Also an implementation
   that does not have the functionality represented by the attribute can
   omit the attribute entirely, rather than having to return a
   distinguished value.  The agent is free to materialize an attribute
   in the jmAttributeTable as soon as the agent is aware of the value of
   the attribute.

   The agent materializes job attributes in a four-indexed
   jmAttributeTable:

        1. jmGeneralJobSetIndex - which job set

        2. jmJobIndex - which job in the job set

        3. jmAttributeTypeIndex - which attribute

        4. jmAttributeInstanceIndex - which attribute instance for those
           attributes that can have multiple values per job.

   Some attributes represent information about a job, such as a file-
   name, a document-name, a submission-time or a completion time.  Other
   attributes represent resources required, e.g., a medium or a
   colorant, etc. to process the job before the job starts processing OR
   to indicate the amount of the resource consumed during and after
   processing, e.g., pages completed or impressions completed.  If both
   a required and a consumed value of a resource is needed, this
   specification assigns two separate attribute enums in the textual
   convention.

   NOTE - The table of contents lists all the attributes in order.  This
   order is the order of enum assignments which is the order that the
   SNMP GetNext operation returns attributes.  Most attributes apply to
   all three configurations covered by this MIB specification (see





Bergman, et al.              Informational                     [Page 20]

RFC 2707               Job Monitoring MIB - V1.0           November 1999


   section 2.1 entitled "System Configurations for the Job Monitoring
   MIB").  Those attributes that apply to a particular configuration are
   indicated as 'Configuration n:' and SHALL NOT be used with other
   configurations.

3.3.1 Conformance of Attribute Implementation

   An agent SHALL implement any attribute if (1) the server or device
   supports the functionality represented by the attribute and (2) the
   information is available to the agent.  The agent MAY create the
   attribute row in the jmAttributeTable when the information is
   available or MAY create the row earlier with the designated 'unknown'
   value appropriate for that attribute.  See next section.

   If the server or device does not implement or does not provide access
   to the information about an attribute, the agent SHOULD NOT create
   the corresponding row in the jmAttributeTable.

3.3.2 Useful, 'Unknown', and 'Other' Values for Objects and Attributes

   Some attributes have a 'useful' Integer32 value, some have a 'useful'
   OCTET STRING value, some MAY have either or both depending on
   implementation, and some MUST have both.  See the JmAttributeTypeTC
   textual convention for the specification of each attribute.

   SNMP requires that if an object cannot be implemented because its
   values cannot be accessed, then a compliant agent SHALL return an
   SNMP error in SNMPv1 or an exception value in SNMPv2.  However, this
   MIB has been designed so that 'all' objects can and SHALL be
   implemented by an agent, so that neither the SNMPv1 error nor the
   SNMPv2 exception value SHALL be generated by the agent.  This MIB has
   also been designed so that when an agent materializes an attribute,
   the agent SHALL materialize a row consisting of both the
   jmAttributeValueAsInteger and jmAttributeValueAsOctets objects.

   In general, values for objects and attributes have been chosen so
   that a management application will be able to determine whether a '
   useful', 'unknown', or 'other' value is available.  When a useful
   value is not available for an object, that agent SHALL return a
   zero-length string for octet strings, the value 'unknown(2)' for
   enums, a '0' value for an object that represents an index in another
   table, and a value '-2' for counting integers.