Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1759

Printer MIB

Pages: 113
Obsoleted by:  3805
Part 1 of 4 – Pages 1 to 22
None   None   Next

ToP   noToC   RFC1759 - Page 1
Network Working Group                                           R. Smith
Request for Comments: 1759                             Texas Instruments
Category: Standards Track                                      F. Wright
                                                   Lexmark International
                                                             T. Hastings
                                                       Xerox Corporation
                                                               S. Zilles
                                                     Adobe Systems, Inc.
                                                           J. Gyllenskog
                                                 Hewlett-Packard Company
                                                              March 1995

                              Printer MIB

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Introduction ................................................    3
   1.1 Network Printing Environment ...............................    3
   1.2 Printer Device Overview ....................................    4
   1.3 Categories of Printer Information ..........................    5
   1.3.1 Descriptions .............................................    5
   1.3.2 Status ...................................................    5
   1.3.3 Alerts ...................................................    5
   2. Printer Model ...............................................    6
   2.1 Overview of the Printer Model ..............................    8
   2.2 Printer Sub-Units ..........................................    8
   2.2.1 General Printer ..........................................    8
   2.2.2 Inputs ...................................................    9
   2.2.3 Media ....................................................    9
   2.2.4 Outputs ..................................................    9
   2.2.5 Finishers ................................................   10
   2.2.6 Markers ..................................................   10
   2.2.7 Media Paths ..............................................   11
   2.2.8 System Controller ........................................   11
   2.2.9 Interfaces ...............................................   11
   2.2.10 Channels ................................................   12
   2.2.11 Interpreters ............................................   12
   2.2.12 Console .................................................   12
   2.2.13 Alerts ..................................................   13
   2.2.13.1 Status and Alerts .....................................   13
ToP   noToC   RFC1759 - Page 2
   2.2.13.2 Overall Printer Status ................................   13
   2.2.13.2.1 Host MIB Printer Status .............................   15
   2.2.13.2.2 Sub-unit Status .....................................   17
   2.2.13.3 Alert Tables ..........................................   18
   2.2.13.4 Alert Table Management ................................   19
   2.3 Read-Write Objects .........................................   20
   2.4 Enumerations ...............................................   22
   2.4.1 Registering Additional Enumerated Values .................   22
   3. Objects from other MIB Specifications .......................   22
   3.1 System Group objects .......................................   22
   3.2 System Controller ..........................................   23
   3.3 Interface Group objects ....................................   23
   4. Textual Conventions .........................................   23
   5. The General Printer Group ...................................   27
   5.1 The Cover Table ............................................   30
   5.2 The Localization Table .....................................   31
   5.3 The System Resources Tables ................................   33
   6. The Responsible Party group .................................   35
   7. The Input Group .............................................   35
   8. The Extended Input Group ....................................   41
   9. The Input Media Group .......................................   42
   10. The Output Group ...........................................   44
   11. The Extended Output Group ..................................   48
   12. The Output Dimensions Group ................................   49
   13. The Output Features Group ..................................   51
   14. The Marker Group ...........................................   52
   15. The Marker Supplies Group ..................................   58
   16. The Marker Colorant Group ..................................   62
   17. The Media Path Group .......................................   64
   18. The Channel Group ..........................................   68
   18.1 The Channel Table and its underlying structure ............   69
   18.2 The Channel Table .........................................   70
   19. The Interpreter Group ......................................   73
   20. The Console Group ..........................................   81
   20.1 The Display Buffer Table ..................................   82
   20.2 The Console Light Table ...................................   83
   21. The Alerts Group ...........................................   85
   21.1 The Alert Time Group ......................................   92
   22. Appendix A - Glossary of Terms .............................   98
   23. Appendix B - Media Size Names ..............................  101
   24. Appendix C - Media Names ...................................  103
   25. Appendix D - Roles of Users ................................  107
   26. Appendix E - Participants ..................................  111
   27. Security Considerations ....................................  113
   28. Authors' Addresses .........................................  113
ToP   noToC   RFC1759 - Page 3
1.  Introduction

1.1.  Network Printing Environment

   The management of producing a printed document, in any computer
   environment, is a complex subject. Basically, the task can be divided
   into two overlapping pieces, the management of printing and the
   management of the printer. Printing encompasses the entire process of
   producing a printed document from generation of the file to be
   printed, selection of a printer, choosing printing properties,
   routing, queuing, resource management, scheduling, and final printing
   including notifying the user.  Most of the printing process is outside
   the scope of the model presented here; only the management of the
   printer is covered.
ToP   noToC   RFC1759 - Page 4
               Figure 1 - One Printer's View of the Network

    system   printer    asset     user          user           user
    manager  operator   manager
      O         O         O         O             O              O
     /|\       /|\       /|\       /|\           /|\            /|\
     / \       / \       / \       / \           / \            / \
      |         |         |         |             |              |
+---------+ +-------+ +-------+ +-------+   +-----------+ +-----------+
|configur-| |printer| | asset | |printer|   |   user    | |   user    |
|ator     | |manager| |manager| |browser|   |application| |application|
+---------+ +-------+ +-------+ +-------+   +-----------+ +-----------+
   ^            ^         ^         ^             |             |
   |R/W         |R/W      |R        |R      +-----------+ +-----------+
   |            |         |         |       |  spooler  | |  spooler  |
   |            |         |         |       +-----------+ +-----------+
   |            |         |         |             |             |
   |            |         |         |       +-----------+ +-----------+
   |            |         |         |       |supervisor | |supervisor |
   |            |         |         |       +-----------+ +-----------+
   |            |         |         |        ^       ^     ^       ^
   |            |         |         |        |R      |R/W  |R      |R/W
   v            v         |         |        |       |     |       |
==================================================   |   =====     |
                     |                          print|        print|
                     |SNMP                       data|         data|
  +-----+        +-------+                        PCL|          PCL|
  | MIB |<------>| agent |                 PostScript|   PostScript|
  +-----+        +-------+                       NPAP|         NPAP|
                     |unspecified                etc.|         etc.|
              +=============+  +-----------------+   |             |
              |             |--|channel/interface|<--+             |
              |             |  +-----------------+                 |
              |   PRINTER   |                                      |
              |             |  +-----------------+                 |
              |             |--|channel/interface|<----------------+
              +=============+  +-----------------+

1.2.  Printer Device Overview

   A printer is the physical device that takes media from an input
   source, produces marks on that media according to some page
   description or page control language and puts the result in some
   output destination, possibly with finishing applied. Printers are
   complex devices that consume supplies, produce waste and have
   mechanical problems. In the management of the physical printing
   device the description, status and alert information concerning the
   printer and its various subparts has to be made available to the
ToP   noToC   RFC1759 - Page 5
   management application so that it can be reported to the end user,
   key operators for the replenishment of supplies or the repair or
   maintenance of the device. The information needed in the management
   of the physical printer and the management of a printing job overlap
   highly and many of the tasks in each management area require the same
   or similar information.

1.3.  Categories of Printer Information

   Information about printers is classified into three basic categories,
   descriptions, status and alerts.

1.3.1.  Descriptions

   Descriptions convey information about the configuration and
   capabilities of the printer and its various sub-units. This
   information is largely static information and does not generally
   change during the operation of the system but may change as the
   printer is repaired, reconfigured or upgraded. The descriptions are
   one part of the visible state of the printer where state means the
   condition of being of the printer at any point in time.

1.3.2.  Status

   Status is the information regarding the current operating state of
   the printer and its various sub-units. Status is the rest of the
   visible state of the printer. As an example of the use of status, a
   management application must be able to determine if the various sub-
   units are ready to print or are in some state that prevents printing
   or may prevent printing in the future.

1.3.3.  Alerts

   An Alert is the representation of a reportable event in the printer.
   An event is a change in the state of the printer. Some of those state
   changes are of interest to a management application and are therefore
   reportable. Typically, these are the events that affect the printer's
   ability to print. Alerts usually occur asynchronously to the
   operation of the computer system(s) to which the printer is attached.
   For convenience below, "alert" will be used for both the event caused
   by a change in the printer's state and for the representation of that
   event.

   Alerts can be classified into two basic categories, critical and
   non-critical.  A critical alert is one that is triggered by entry
   into a state in which the printer is stopped and printing can not
   continue until the condition that caused critical alert is
   eliminated. "Out of paper", "toner empty" and "output bin full" are
ToP   noToC   RFC1759 - Page 6
   examples of critical alerts. Non-critical alerts are triggered by
   those events that enter a state in which printing is not stopped.
   Such a non-critical state may, at some future time, lead to a state
   in which printing may be stopped.  Examples of this kind of non-
   critical alerts are "input media low", "toner low" and "output bin
   nearly full". Or, a non-critical alert may simply provide
   information, such as signaling a configuration changed in the
   printer.

   Description, status and alert information about printer can be
   thought of as a data base describing the printer. The management
   application for a printer will want to view the printer data base
   differently depending on how and for what purposes the information in
   the data base is needed.

2.  Printer Model

   In order to accomplish the management of the printer, an abstract
   model of the printer is needed to represent the sub-units from which
   the printer is composed. A printer can be described as consisting of
   13 types of sub-units. It is important to note that the sub-units of
   a printer do not necessarily relate directly to any physically
   identifiable mechanism. Sub-units can also be a set of definable
   logical processes, such as interpreters for page description
   languages or command processors that set various operating modes of
   the printer.
ToP   noToC   RFC1759 - Page 7
   Figure 2 shows a block diagram of the printer and its basic 13 sub-
   units.

                     Figure 2 - Printer  Block Diagram

                           Physical Connections
                                   |
                                +-----------+
                                |           |
                            +-------------+ |
                            | Interface   |-+
                            | (RFC1213)   |
                            +-------------+
                                   |
                                +-----------+
                                |           |
                            +-------------+ |    +-----------+
                            | Channel     |-+    | Operator  |
                            |             |      |  Console  |
                            +-------------+      +-----------+
                                   |
                                +-----------+        +---------+
                                |           |        |         |
        +-----------+       +-------------+ |    +-----------+ |
        |  General  |       | Interpreter |-+    |  Alerts   |-+
        |  Printer  |       |             |      |           |
        +-----------+       +-------------+      +-----------+
                                   |
                   +-------------------------------+
                   |        System Controller      |
                   |     (This is the Host MIB)    |
                   +-------------------------------+

   +------+                    +--------+                  +--------+
   |      |                    |        |                  |        |
+-------+ |    +-------+    +---------+ |    +-------+   +--------+ |
| Input |-+  +--------+|    |  Marker |-+  +--------+|   | Output |-+
|       |===>|        |+<==>|         |<==>|        |+==>|        |
+-------+    +--+  +--+     +---------+    +--+  +--+    +--------+
   \            |  ||                         |  ||         \
    \           |  ||                         |  ||          \
     \          |  ||                         |  ||           \
    +--------+  |  |+-------------------------|  ||         +---------+
    |        |  |  +--------------------------+  ||         |         |
+----------+ |  |            Media Path          |+      +----------+ |
|  Media   |-+  +--------------------------------+       | Finisher |-+
|(optional)|                                             |(optional)|
+----------+                                             +----------+
ToP   noToC   RFC1759 - Page 8
2.1.  Overview of the Printer Model

   The model has three basic parts: (1) the flow of a print file into an
   interpreter and onto the marker, (2) the flow of media through the
   marker and (3) the auxiliary sub-units that control and facilitate
   the two prior flows.  The flow of the print data comes through a
   physical connection on which some form of transport protocol stack is
   running.  The data provided by the transport protocol (interface)
   appears on a channel which is the input to an interpreter. The
   interpreter converts the print data into a form suitable for marking
   on the media.

   The media resides in Input sub-units from which the media is selected
   and then transported via a Media Path first to a Marking sub-unit and
   then onto an Output sub-unit with (optionally) some finishing
   operations being performed.  The auxiliary sub-units facilitate
   control of the printer, inquiry/control of the operator panel,
   reporting of alerts, and the adaptation of the printer to various
   natural languages and characters sets. All the software sub-units run
   on the System Controller which represents the processor, memory and
   storage systems of the Printer.  Each of the sub-units is discussed
   in more detail below.

   All of the sub-units other than the Alerts report only state
   information, either a description or a status. The Alerts sub-unit
   reports event information.

2.2.  Printer Sub-Units

   A printer is composed of 13 types of sub-units, called groups.  The
   following sections describe the different types of sub-units.

2.2.1.  General Printer

   The general printer sub-unit is responsible for the overall control
   and status of the printer. There is exactly one general printer sub-
   unit in a printer. The general printer sub-unit is represented by the
   General Printer Group in the model. In addition to the providing the
   status of the whole printer and allowing the printer to be reset,
   this Group provides information on the status of the packaging of the
   printer, in particular, the covers. The general printer sub-unit is
   usually implemented on the system controller.

   The localization portion of the general printer sub-unit is
   responsible for identifying the natural language, country, and
   character set in which character strings are expressed. There may be
   one or more localizations supported per printer. The available
   localizations are represented by the Localization table.
ToP   noToC   RFC1759 - Page 9
   Localization is only performed on those strings in the MIB that are
   explicitely marked as being localized.  All other character strings
   are returned in ASCII.

   The character set portion of the general printer sub-unit is
   responsible for identifying the possible character sets that are used
   by the interpreters, the operator console, and in network management
   requests for display objects. There may be one or more character sets
   per printer.  The understood character sets are represented by the
   Character Set Table.

2.2.2.  Inputs

   Input sub-units are mechanisms that feed media to be marked on into
   the printer. A printer contains one or more input sub-units. These
   are represented by the Input Group in the model. The model does not
   distinguish fixed input bins from removable trays, except to report
   when a removable tray has been removed.

   There are as many input sub-units as there are distinctly selectable
   input "addresses".  For example, if a tray has an option for manually
   feeding paper as well as automatically feeding from the tray, then
   this is two input sub-units if these two sources can be (must be)
   separately selected and is one input sub-unit if putting a sheet in
   the manual feed slot overrides feeding from the contents of the tray;
   that is, in the second case there is no way to separately select or
   address the manual feed slot.

2.2.3.  Media

   An input sub-unit can hold one or more instances of the media on
   which marking is to be done. Typically, there is a large set of
   possible media that can be associated with an input. The Media Group
   is an extension of the Input Group which represents that media that
   is in an input sub-unit. The Media Group only describes the current
   contents of each input and not the possible content of the input
   sub-unit.

2.2.4.  Outputs

   Output sub-units are mechanisms that receive media that has been
   marked on. A printer contains one or more output mechanisms. These
   are represented by the Output Group in the model. The model does not
   distinguish fixed output bins from removable output bins, except to
   report when a removable bin has been removed.

   There are as many output sub-units as there are distinctly selectable
   output "addresses".  Output sub-units can be addressed in two
ToP   noToC   RFC1759 - Page 10
   different ways: (1) as a set of "mailboxes" which are addressed by a
   specific mailbox selector such as a bin number or a bin name, or (2)
   as a set of "slots" into which multiple copies are collated.
   Sometimes both modes of using the output sub-units can be used on the
   same printer.  All that is important from the viewpoint of the model
   is that the output units can be separately selected.

2.2.5.  Finishers

   A finisher is a sub-unit that performs some operations on the media
   other than marking.  The finisher sub-units are represented by the
   Finisher Group in the model.  Some examples of finishing processes
   are stapling, punching, binding, inserting, or folding.  Finishing
   processes may have supplies asssociated with the process.  Stapling,
   binding, and punching are examples of processes that have supplies. A
   printer may have more than one finishing sub-unit and each finishing
   sub-unit may be associated with one or more output sub-units.
   Finishers are not described in this MIB.

   The exact interaction and sequencing between an output device and its
   associated finisher is not specified by the model. It depends on the
   type of finishing process and the exact implementation of the printer
   system. This standard allows for the logical association of a
   finishing process with an output device but does not put any
   restrictions on the exact sequence or interaction with the associated
   output device. The output and finisher sub-units may or may not be
   separate identifiable physical mechanisms depending on the exact
   implementation of a printer.  In addition, a single output device may
   be associated with multiple finishing sub-units and a single
   finishing sub-unit may be associated with multiple output devices.

2.2.6.  Markers

   A marker is the mechanism that produces marks on the print media. The
   marker sub-units and their associated supplies are represented by the
   Marker Group in the model. A printer can contain one or more marking
   mechanisms.  Some examples of multiple marker sub-units are: a
   printer with separate markers for normal and magnetic ink or an
   imagesetter that can output to both a proofing device and final film.
   Each marking device can have its own set of  characteristics
   associated with it, such as marking technology and resolution.

   In this model the marker sub-unit is viewed as very generalized and
   encompasses all aspects of a marking process. For example, in a
   xero-graphic process, the marking process as well as the fusing
   process would be included in the generalized concept of the marker.
   With the generalized concept of a marking process, the concept of
   multiple marking supplies associated with a single marking sub-unit
ToP   noToC   RFC1759 - Page 11
   results. For example, in the xerographic process, there is not only a
   supply of toner, but there can also be other supplies such as a fuser
   supply that can be consumed and replaced separately. In addition
   there can be multiple supplies of toner for a single marker device,
   as in a color process.

2.2.7.  Media Paths

   The media paths encompass the mechanisms in the printer that move the
   media through the printer and connect all other media related sub-
   units: inputs, outputs, markers and finishers. A printer contains one
   or more media paths. These are represented by the Media Path Group in
   the model.  The Media Path group has some objects that apply to all
   paths plus a table of the separate media paths.

   In general, the design of the media paths determines the maximum
   speed of the printer as well as the maximum media size that the
   printer can handle. Media paths are complex mechanisms and can
   contain many different identifiable sub-mechanisms such as media
   movement devices, media buffers, duplexing units and interlocks. Not
   all of the various sub-mechanisms reside on every media path.  For
   example, one media path may provide printing only on one surface of
   the media (a simplex path) and another media path may have a sub-
   mechanism that turns the media over and feeds it a second time
   through the marker sub-unit (a duplex path).  The duplex path may
   even have a buffer sub-mechanism that allows multiple copies of the
   obverse side to be held before the reverse side of all the copies are
   marked.

2.2.8.  System Controller

   The System Controller is the sub-unit upon which the software
   components of the Printer run. The System Controller is represented
   in the model by the Host MIB. This MIB allows for the specification
   of the processor(s), memory, disk storage, file system and other
   underlying sub-mechanisms of the printer. The controller can range
   from simple single processor systems to multiprocessor systems. In
   addition, controllers can have a full range of resources such as hard
   disks. The printer is modeled to have one system controller even
   though it may have more than one processor and multiple other
   resources associated with it.

2.2.9.  Interfaces

   An interface is the communications port and associated protocols that
   are responsible for the transport of data to the printer. A printer
   has one or more interface sub-units. The interfaces are represented
   by the Interfaces Group of MIB-II (RFC 1213). Some examples of
ToP   noToC   RFC1759 - Page 12
   interfaces are serial ports (with little or no protocol) and EtherNet
   ports on which one might run InterNet IP, Novell IPX, etc.

2.2.10.  Channels

   The channel sub-units identify the independent sources of print data
   (here print data is the information that is used to construct printed
   pages and may have both data and control aspects).  A printer may
   have one or more channels. The channel sub-units are represented by
   the Channel Group in the Model. Each channel is typically identified
   by the electronic path and service protocol used to deliver print
   data to the printer. A channel sub-unit may be independently enabled
   (allowing print data to flow) or disabled (stopping the flow of print
   data). It has a current Control Language which can be used to specify
   which interpreter is to be used for the print data and to query and
   change environment variables used by the interpreters (and SNMP).
   There is also a default interpreter that is to be used if an
   interpreter is not explicitly specified using the Control Language.
   Channel sub-units are based on an underlying interface.

2.2.11.  Interpreters

   The interpreter sub-units are responsible for the conversion of a
   description of intended print instances into images that are to be
   marked on the media. A printer may have one or more interpreters. The
   interpreter sub-units are represented by the Interpreter Group in the
   Model. Each interpreter is generally implemented with software
   running on the System Controller sub-unit. The Interpreter Table has
   one entry per interpreter where the interpreters include both Page
   Description Language (PDL) Interpreters and Control Language
   Interpreters.

2.2.12.  Console

   Many printers have a console on the printer, the operator console,
   that is used to display and modify the state of the printer.  The
   console can be as simple as a few indicators and switches or as
   complicated as full screen displays and keyboards. There can be at
   most one such console.  This console sub-unit is represented by the
   Console Group in the model.  Although most of the information
   displayed there is also available in the state of the printer as
   represented by the various Groups, it is useful to be able to query
   and modify the operator console remotely.  For example, a management
   application might like to display to its user the current message on
   the operator console of the remote printer or the management
   application user might like to modify the current message on the
   operators console of the remote printer.  As another example, one
   might have a remote application that puts up a pseudo console on a
ToP   noToC   RFC1759 - Page 13
   workstation screen. Since the rules by which the printer state is
   mapped onto the console and vice versa are not standardized, it is
   not possible to reproduce the console state or the action of console
   buttons and menus. Therefore, the Console Group provides access to
   the console. The operator console is usually implemented on the
   system controller with additional hardware for input and display.

2.2.13.  Alerts

   The alert sub-unit is responsible for detecting reportable events,
   making an entry in the alert table and, if and only if the event is a
   critical event, initiating a trap. The alert sub-unit is represented
   by the Alerts Group and, in particular, the Alert Table. This table
   contains information on the severity, sub-unit, detailed location
   within the sub-unit, alert code and description of each critical
   alert that is currently active within the printer. Each reportable
   event causes an entry to be made in the Alert Table.

2.2.13.1.  Status and Alerts

   Summary information about the state of the printer is reported at
   three separate levels: (1) there is the status of the printer as a
   whole reported in the Host MIB, (2) there is the status of various
   sub-units reported in the principle table of the Group that
   represents the sub-unit, and (3) there are alert codes reported in
   the Alert Table.

2.2.13.2.  Overall Printer Status

   Of the many states a printer can be in, certain states are more
   "interesting" because of the distinct actions they are likely to
   provoke in the administrator.  These states may be applied to the
   printer as a whole, or to a particular sub-unit of the printer.
   These named states are:

   Non Critical Alert Active - For the printer this means that one or
   more sub-units have a non-critical alert active.  For a sub-unit,
   this means that the sub-unit has a non-critical alert active.

   Critical Alert Active - For the printer this means that one or more
   sub-units have a critical alert active.  For a sub-unit, this means
   that the sub-unit has a critical alert active.

   Unavailable - The printer or sub-unit is unavailable for use (this is
   the same as "broken" or "down" in other terminologies).  A trained
   service person is typically necessary to make it available.
ToP   noToC   RFC1759 - Page 14
   Busy / Temporarily Unavailable - The printer or sub-unit is
   operational but currently occupied with a request for activity. The
   sub-unit will become available without the need of human interaction.

   Moving on-line or off-line - The printer is either off-line, in the
   process of moving off-line or in the process of moving back on-line;
   for example on high end printers reloading paper involves a
   transition to off-line to open the paper bin, it is then filled and,
   finally, there is a transition back to on-line as the paper bin is
   repositioned for printing.

   Standby - The printer or sub-unit is unavailable for use because it
   is partially powered down and may need some period of time to become
   fully operational again.  A unit in Standby state shall respond to
   network management requests.

   The Host MIB provides three status objects that can be used to
   describe the status of a printer: (1) hrDeviceStatus in the entry in
   the Host MIB hrDeviceTable; (2) hrPrinterStatus in the
   hrPrinterTable; and (3) hrPrinterDetectedErrorState in the
   hrPrinterTable.  These objects describe many of the states that a
   printer can be in.  The following table shows how the "interesting"
   states named above can be recognized by inspecting the values of the
   three printer-related objects in the Host MIB:

Printer     hrDeviceStatus  hrPrinterStatus  hrPrinterDetectedErrorState
Status

Normal         running(2)     idle(3)        none set

Busy/          running(2)     printing(4)
Temporarily
Unavailable

Non Critical   warning(3)     idle(3) or     could be: lowPaper,
Alert Active                  printing(4)    lowToner, or
                                             serviceRequested

Critical       down(5)        other(1)       could be: jammed,
Alert Active                                 noPaper, noToner,
                                             coverOpen, or
                                             serviceRequested

Unavailable    down(5)        other(1)

Moving off-    warning(3)     idle(3) or     offline
line                          printing(4)
ToP   noToC   RFC1759 - Page 15
Off-line       down(5)        other(1)       offline

Moving         down(5)        warmup(5)
on-line

Standby        running(2)     other(1)

   These named states are only a subset of the possible states - they
   are not an exhaustive list of the possible states.  Nevertheless,
   several things should be noted.  When using these states, it is not
   possible to detect when both critical and non-critical alerts are
   pending - if both are pending, the Critical Alert Active state will
   prevail.  In addition, a printer in the Standby state will be
   represented in the Host MIB with a device status of running(2) and a
   printer status of other(1), a set of states that don't uniquely
   distinguish this important printer state.

   Although the above mapping is workable, it would be improved with a
   few additions to hrDeviceStatus and hrPrinterStatus in the Host
   Resources MIB. In particular, it would be appropriate to add a
   "standby" enumeration to hrDeviceStatus.  Similarly, it would be
   useful to add the following states to hrPrinterStatus: "offline" to
   indicate that reason for the printer being down (instead of having to
   use "other") which allows both "warning" and "offline" to indicate
   going offline and "down" and "offline" to indicate offline and
   "notApplicable" to cover cases, such as "standby", where the device
   state completely describes the state of the device.

   Detailed status per sub-unit is reported in the sub-unit status
   fields.

2.2.13.2.1.  Host MIB Printer Status

   For completeness, the definitions of the Printer Status objects of
   the Host MIB are given below:

      hrDeviceStatus OBJECT-TYPE
           SYNTAX  INTEGER {
                unknown(1),
                running(2),
                warning(3),
                testing(4),
                down(5)
           }
           ACCESS  read-only
           STATUS  mandatory
           DESCRIPTION
                 "The current operational state of the device
ToP   noToC   RFC1759 - Page 16
                 described by this row of the table.  A value
                 unknown(1) indicates that the current state of the
                 device is unknown.  running(2) indicates that the
                 device is up and running and that no unusual error
                 conditions are known.  The warning(3) state
                 indicates that agent has been informed of an
                 unusual error condition by the operational software
                 (e.g., a disk device driver) but that the device is
                 still 'operational'.  An example would be high
                 number of soft errors on a disk.  A value of
                 testing(4), indicates that the device is not
                 available for use because it is in the testing
                 state.  The state of down(5) is used only when the
                 agent has been informed that the device is not
                 available for any use."
           ::= { hrDeviceEntry 5 }

   hrPrinterStatus OBJECT-TYPE
          SYNTAX INTEGER {
              other(1),
              unknown(2),
              idle(3),
              printing(4),
              warmup(5)
          }
          ACCESS read-only
          STATUS mandatory
          DESCRIPTION
                  "The current status of this printer device.  When
                  in the idle(1), printing(2), or warmup(3) state,
                  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
ToP   noToC   RFC1759 - Page 17
                       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
ToP   noToC   RFC1759 - Page 18
            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.
ToP   noToC   RFC1759 - Page 19
   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
ToP   noToC   RFC1759 - Page 20
   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
ToP   noToC   RFC1759 - Page 21
   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
   is particularly important that the values of the prtMarkerLifeCount
   object persist throughout the lifetime of the printer.  Therefore, if
   the value of any MIB object persists across power cycles, then the
   prtMarkerLifeCount object must also persist.
ToP   noToC   RFC1759 - Page 22
2.4.  Enumerations

   Enumerations (enums) are sets of symbolic values defined for use with
   one or more objects.  Some common enumeration sets are assigned a
   symbolic data type name (textual convention).  These enumerations are
   listed at the beginning of this specification.

2.4.1.  Registering Additional Enumerated Values

   This working group has defined several type of enumerations.  These
   enumerations differ in the method employed to control the addition of
   new enumerations.  Throughout this document, references to
   "enumeration (n)", where n can be 1, 2 or 3 can be found in the
   various tables.  The definitions of these types of enumerations are:

  enumeration (1)  All the values are defined in the Printer MIB
     specification (RFC for the Printer MIB).  Additional enumerated
     values require a new RFC.

  enumeration (2)  An initial set of values are defined in the Printer
     MIB specification.  Additional enumerated values are
     registered after review by this working group. The initial
     versions of the MIB will contain the values registered so far.
     After the MIB is approved, additional values will be
     registered through IANA after approval by this working group.

  enumeration (3)  An initial set of values are defined in the Printer
     MIB specification.  Additional enumerated values are
     registered without working group review.  The initial versions of
     the MIB will contain the values registered so far.  After the MIB
     is approved, additional values will be registered
     through IANA without approval by this working group.



(page 22 continued on part 2)

Next Section