rfc1759.txt

RFC 的详细文档！

                  the corresponding hrDeviceStatus should be
                  running(2) or warning(3).  When in the unknown
                  state, the corresponding hrDeviceStatus should be
                  unknown(1)."
          ::= { hrPrinterEntry 1 }

      hrPrinterDetectedErrorState OBJECT-TYPE
          SYNTAX OCTET STRING
          ACCESS read-only
          STATUS mandatory
          DESCRIPTION
                  "This object represents any error conditions
                  detected by the printer.  The error conditions are
                  encoded as bits in an octet string, with the
                  following definitions:

                       Condition         Bit #    hrDeviceStatus




Smith, Wright, Hastings, Zilles & Gyllenskog                   [Page 16]

RFC 1759                      Printer MIB                     March 1995


                       lowPaper          0        warning(3)
                       noPaper           1        down(5)
                       lowToner          2        warning(3)
                       noToner           3        down(5)
                       doorOpen          4        down(5)
                       jammed            5        down(5)
                       offline           6        down(5)
                       serviceRequested  7        warning(3)

                  If multiple conditions are currently detected and
                  the hrDeviceStatus would not otherwise be
                  unknown(1) or testing(4), the hrDeviceStatus shall
                  correspond to the worst state of those indicated,
                  where down(5) is worse than warning(3) which is
                  worse than running(2).

                  Bits are numbered starting with the most
                  significant bit of the first byte being bit 0, the
                  least significant bit of the first byte being bit
                  7, the most significant bit of the second byte
                  being bit 8, and so on.  A one bit encodes that
                  the condition was detected, while a zero bit
                  encodes that the condition was not detected.

                  This object is useful for alerting an operator to
                  specific warning or error conditions that may
                  occur, especially those requiring human
                  intervention."
          ::= { hrPrinterEntry 2 }

2.2.13.2.2.  Sub-unit Status

   Sub-unit status is reported in the entries of the principle table in
   the Group that represents the sub-unit. For sub-units that report a
   status, there is a status column in the table and the value of this
   column is always an integer formed in the following way.

   The SubUnitStatus is an integer that is the sum of 5 distinct values,
   Availability, Non-Critical, Critical, On-line, and Transitioning.
   These values are:

     Availability                           value

            Available and Idle              0       000'b
            Available and Standby           2       010'b
            Available and Active            4       100'b
            Available and Busy              6       110'b
            Unavailable and OnRequest       1       001'b



Smith, Wright, Hastings, Zilles & Gyllenskog                   [Page 17]

RFC 1759                      Printer MIB                     March 1995


            Unavailable because Broken      3       011'b
            Unknown                         5       101'b

    Non-Critical

            No Non-Critical Alerts          0
            Non-Critical Alerts             8

    Critical

            No Critical Alerts              0
            Critical Alerts                 16

    On-Line

            Intended state is On-Line       0
            Intended state is Off-Line      32

    Transitioning

            At intended state               0
            Transitioning to intended state 64

   For example, an input (tray) that jammed on the next to the last page
   may show a status of 27 (unavailable because broken (3) + a critical
   state (16), jammed, and a noncritical state (8), low paper).

2.2.13.3.  Alert Tables

   The Alert Group consists of a single table in which all active alerts
   are represented.  This section provides and overview of the table and
   a description of how it is managed.  The basic content of the alert
   table is the severity (critical or non-critical) of the alert, the
   Group and entry where a state change caused the alert, additional
   information about the alert (a more detailed location, an alert code,
   and a description), and an indication of the level of training needed
   to service the alert.

   The Alert Table contains some information that is redundant, for
   example that an event has occurred, and some information that is only
   represented in the Alert Table, for example the additional
   information.  A single table was used because a single entry in a
   Group could cause more than one alert, for example paper jams in more
   than one place in a media path. Associating the additional
   information with the entry in the affected group would only allow one
   report where associating the additional information with the alert
   makes multiple reports possible.




Smith, Wright, Hastings, Zilles & Gyllenskog                   [Page 18]

RFC 1759                      Printer MIB                     March 1995


   Every time an alert occurs in the printer, the printer makes one or
   more entries into the Alert Table. The printer determines if an event
   is to be classified as critical or non-critical. If the severity of
   the Alert is "critical", the printer sends a trap or event
   notification to the host indicating that the table has changed.
   Whether or not a trap is sent, the management application is expected
   to poll the printer on a regular basis and to read and parse the
   table to determine what conditions have changed, in order to provide
   reliable information to the management application user.

2.2.13.4.  Alert Table Management

   The alert tables are sparsely populated tables. This means the tables
   will only contain entries of the alerts that are currently active and
   the number of rows, or entries in the table will be dynamic. More
   than one event can be added or removed from the event tables at a
   time depending on the implementation of the printer.

   There are basically two kinds of events that produce alerts: binary
   change events and simple change events. Binary change events come in
   pairs: the leading edge event and the trailing edge event. The
   leading edge event enters a state from which there is only one exit;
   for example, going from running to stopped with a paper jam. The only
   exit from this state is fixing the paper jam and it is clear when
   that is accomplished.  The trailing edge event is the event which
   exits the state the was entered by the leading edge event; in the
   example above fixing the paper jam is the trailing edge event.

   It is relatively straightforward to manage binary change events in
   the Alert Table. Only the leading edge event makes an entry in the
   alert table.  This entry persists in the Alert Table until the
   trailing edge event occurs at which point this event is signal by the
   removal of the leading edge event entry in the Alert Table.  That is,
   a trailing edge event does not create an entry; it removes the
   corresponding leading edge event. With binary events it is possible
   to compute the maximum number that can occur at the same time and
   construct an Alert Table that would hold that many events. There
   would be no possibility of table overflow and no information about
   outstanding events would be lost.

   Unfortunately, there are some events that are not binary changes.
   This other category of event, the simple change event,  is
   illustrated by the configuration change event. With this kind of
   event the state of the machine has changed, but to a state which is
   (often) just as valid as the state that was left and from which no
   return is necessary.  For example, an operator may change the paper
   that is in the primary input source from letter to legal. At some
   time in the future the paper may be changed back to letter, but it



Smith, Wright, Hastings, Zilles & Gyllenskog                   [Page 19]

RFC 1759                      Printer MIB                     March 1995


   might be changed to executive instead.  This is where the problem
   occurs. It is not obvious how long to keep simple change event
   entries in the Alert Table. It they were never removed, the Alert
   Table would continue to grow indefinitely.

   The agent needs to have an algorithm implemented for the management
   of the alert table, especially in the face of combinations of binary
   and simple alerts that would overflow the storage capaciity of the
   table.  When the table is full and a new alert needs to be added, an
   old alert needs to be deleted.  The alert to be deleted should be
   chosen using the following rules:

    1. Find a non-critical simple alert and delete it.  If there are
       multiple non-critical simple alerts, it is suggested that the
       oldest one be chosen.  If there are no non-critical simple
       alerts, then,

    2. Find a non-critical binary alert and delete it.  If there are
       multiple non-critical binary alerts, it is suggested that the
       oldest one be chosen.  If there are no non-critical binary
       alerts, then,

    3. Find a critical (binary) alert and delete it.  If there are
       multiple critical alerts, it is suggested that the
       oldest one be chosen.  Agent implementors are encouraged to
       provide at least enough storage space for the maximum number
       of critical alerts that could occur simultaneously.  Note that
       all critical alerts are binary.

   Note that because the Alert Index is a monotonically increasing
   integer there will be gaps in the values in the table when an alert
   is deleted.  Such gaps can be detected by the management application
   to indicate that the management application may want to re-acquire
   the Printer state and check for state changes it did not observe in
   the Alert Table.

2.3.  Read-Write Objects

   Some of the objects in the printer MIB report on the existence of or
   amount of a given resource used with the printer.  Some examples of
   such resources are the size and number of sheets of paper in a paper
   tray or the existence of certain output options.  On some printers
   there are sensors that allow these resources to be sensed.  Other
   printers, however, lack sensors that can detect (all of) the
   properties of the resource.  Because the printer needs to know of the
   existence or properties of these resources for the printer to
   function properly some other way of providing this information is
   needed.  The chosen way to solve this problem is to allow a



Smith, Wright, Hastings, Zilles & Gyllenskog                   [Page 20]

RFC 1759                      Printer MIB                     March 1995


   management application to write into objects which hold the
   descriptive or existence values for printers that cannot sense the
   values.  Thus many of the objects in the MIB are given read-write
   access, but a printer implementation might only permit a management
   operation to change the value if the printer could not sense the
   value itself.  Therefore, the ability to change the value of a read-
   write object may depend on the implementation of the agent.  Note
   that even though some objects explicitely state the behaviour of
   conditional ability to change values, any read-write object may act
   that way.

   Generally, an object is given read-write access in the Printer MIB
   specification if:

  1.The object involves installation of a resource that some
    printers cannot themselves detect.  Therefore, external means are
    needed to inform the printer of the installation.  (Here external
    means include using the operator console, or remote management
    application) and

  2.The printer will behave differently if the installation of the
    resource is reported than the printer would if the installation
    were not reported; that is, the object is not to be used
    as a place to put information not used by the printer, i.e., not a
    "PostIt".  Another way of saying this is that the printer believes
    that information given it and acts as if the information were
    true.  For example, on a printer that cannot sense the size, if
    one paper size is loaded, but another size is set into the paper
    size object, then the printer will use the size that was
    set as its current paper size in its imaging and paper handling.

   The printer may get hints that it may not know about the existence or
   properties of certain resources.  For example, a paper tray may be
   removed and re-inserted.  When this removal and insertion happens,
   the printer may either assume that a property, such as the size of
   paper in the tray, has not changed or the printer may change the
   value of the associated object to "unknown", as might be done for the
   amount of paper in the tray.  As long as the printer acts according
   to the value in  the object either strategy is acceptable.

   It is an implementation-specific matter as to whether or not MIB
   object values are persistent across power cycles or cold starts.  It