tech-invite   World Map     

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

RFC 3805

Proposed STD
Pages: 171
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PRINTMIB

Printer MIB v2

Part 1 of 6, p. 1 to 25
None       Next RFC Part

Obsoletes:    1759


Top       ToC       Page 1 
Network Working Group                                         R. Bergman
Request for Comments: 3805                    Hitachi Printing Solutions
Obsoletes: 1759                                                 H. Lewis
Category: Standards Track                                IBM Corporation
                                                             I. McDonald
                                                         High North Inc.
                                                               June 2004


                             Printer MIB v2

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.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document provides definitions of models and manageable objects
   for printing environments.  The objects included in this MIB apply to
   physical, as well as logical entities within a printing device.  This
   document obsoletes RFC 1759.

Top       Page 2 
Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Network Printing Environment. . . . . . . . . . . . . .   4
       1.2.  Printer Device Overview . . . . . . . . . . . . . . . .   6
       1.3.  Categories of Printer Information . . . . . . . . . . .   6
             1.3.1.  Descriptions. . . . . . . . . . . . . . . . . .   6
             1.3.2.  Status. . . . . . . . . . . . . . . . . . . . .   6
             1.3.3.  Alerts. . . . . . . . . . . . . . . . . . . . .   6
       1.4.  The Internet-Standard Management Framework. . . . . . .   7
       1.5.  Requirement Levels. . . . . . . . . . . . . . . . . . .   7
   2.  Printer Model . . . . . . . . . . . . . . . . . . . . . . . .   8
       2.1.  Overview of the Printer Model . . . . . . . . . . . . .  10
       2.2.  Printer Sub-Units . . . . . . . . . . . . . . . . . . .  10
             2.2.1.  General Printer . . . . . . . . . . . . . . . .  10
                     2.2.1.1.  International Considerations. . . . .  10
             2.2.2.  Inputs. . . . . . . . . . . . . . . . . . . . .  11
             2.2.3.  Media . . . . . . . . . . . . . . . . . . . . .  12
             2.2.4.  Outputs . . . . . . . . . . . . . . . . . . . .  12
             2.2.5.  Finishers . . . . . . . . . . . . . . . . . . .  12
             2.2.6.  Markers . . . . . . . . . . . . . . . . . . . .  13
             2.2.7.  Media Paths . . . . . . . . . . . . . . . . . .  13
             2.2.8.  System Controller . . . . . . . . . . . . . . .  14
             2.2.9.  Interfaces. . . . . . . . . . . . . . . . . . .  14
             2.2.10. Print Job Delivery Channels . . . . . . . . . .  14
             2.2.11. Interpreters. . . . . . . . . . . . . . . . . .  15
             2.2.12. Console . . . . . . . . . . . . . . . . . . . .  15
             2.2.13. Alerts. . . . . . . . . . . . . . . . . . . . .  15
                     2.2.13.1. Status and Alerts . . . . . . . . . .  16
                     2.2.13.2. Overall Printer Status. . . . . . . .  16
                               2.2.13.2.1. Host Resources MIB
                                           Printer Status. . . . . .  18
                               2.2.13.2.2. Sub-unit Status . . . . .  20
                     2.2.13.3. Alert Tables. . . . . . . . . . . . .  21
                     2.2.13.4. Alert Table Management. . . . . . . .  21
       2.3.  Read-Write Objects. . . . . . . . . . . . . . . . . . .  23
       2.4.  Enumerations. . . . . . . . . . . . . . . . . . . . . .  24
             2.4.1.  Registering Additional Enumerated Values. . . .  25
   3.  Groups from other MIB Specifications. . . . . . . . . . . . .  25
       3.1.  System Group. . . . . . . . . . . . . . . . . . . . . .  25
       3.2.  System Controller . . . . . . . . . . . . . . . . . . .  25
       3.3.  Interface Group objects . . . . . . . . . . . . . . . .  26
             3.3.1.  Interface Types . . . . . . . . . . . . . . . .  26
   4.  Differences from RFC 1759 . . . . . . . . . . . . . . . . . .  26
   5.  The IANA Printer MIB. . . . . . . . . . . . . . . . . . . . .  29
   6.  The Printer MIB . . . . . . . . . . . . . . . . . . . . . . .  56
       -- Textual conventions for this MIB module. . . . . . . . . .  59
       -- The General Printer Group. . . . . . . . . . . . . . . . .  67

Top      ToC       Page 3 
       -- The Responsible Party group. . . . . . . . . . . . . . . .  70
       -- The Auxiliary Sheet Group. . . . . . . . . . . . . . . . .  73
       -- Administrative section  (The General V2 Group) . . . . . .  74
       -- General alert table section  (Alert Table V2 Group). . . .  74
       -- The Cover Table. . . . . . . . . . . . . . . . . . . . . .  75
       -- The Localization Table . . . . . . . . . . . . . . . . . .  76
       -- The System Resources Tables. . . . . . . . . . . . . . . .  78
       -- The Input Group. . . . . . . . . . . . . . . . . . . . . .  81
       -- The Extended Input Group . . . . . . . . . . . . . . . . .  86
       -- The Input Media Group. . . . . . . . . . . . . . . . . . .  87
       -- The Input Switching Group. . . . . . . . . . . . . . . . .  89
       -- The Output Group . . . . . . . . . . . . . . . . . . . . .  90
       -- The Extended Output Group. . . . . . . . . . . . . . . . .  93
       -- The Output Dimensions Group. . . . . . . . . . . . . . . .  95
       -- The Output Features Group. . . . . . . . . . . . . . . . .  97
       -- The Marker Group . . . . . . . . . . . . . . . . . . . . .  98
       -- The Marker Supplies Group. . . . . . . . . . . . . . . . . 104
       -- The Marker Colorant Group. . . . . . . . . . . . . . . . . 107
       -- The Media Path Group . . . . . . . . . . . . . . . . . . . 109
       -- The Print Job Delivery Channel Group . . . . . . . . . . . 113
       -- The Interpreter Group. . . . . . . . . . . . . . . . . . . 115
       -- The Console Group. . . . . . . . . . . . . . . . . . . . . 120
       -- The Alerts Group . . . . . . . . . . . . . . . . . . . . . 125
       -- Conformance Information. . . . . . . . . . . . . . . . . . 129
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 147
   8.  Internationalization Considerations . . . . . . . . . . . . . 147
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 148
   10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 150
       10.1. Normative References. . . . . . . . . . . . . . . . . . 150
       10.2. Informative References. . . . . . . . . . . . . . . . . 151
   Appendix A - Glossary of Terms. . . . . . . . . . . . . . . . . . 153
   Appendix B - Media Size Names . . . . . . . . . . . . . . . . . . 156
   Appendix C - Media Names. . . . . . . . . . . . . . . . . . . . . 158
   Appendix D - Roles of Users . . . . . . . . . . . . . . . . . . . 162
   Appendix E - Overall Printer Status Table . . . . . . . . . . . . 165
   Appendix F - Participants . . . . . . . . . . . . . . . . . . . . 166
   Significant Contributors. . . . . . . . . . . . . . . . . . . . . 168
   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 170
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 171

Top      ToC       Page 4 
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      ToC       Page 5 
              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|<----------------+
              +=============+  +-----------------+

Top      ToC       Page 6 
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 may have
   mechanical problems.  In the management of the physical device the
   description, status and alert information concerning the printer and
   its various subparts has to be made available to the 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.  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

Top      ToC       Page 7 
   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 the critical alert is eliminated.
   "Out of paper", "toner empty" and "output bin full" are 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 these kinds 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 the printer can be
   thought of as a database 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 database is needed.

1.4.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

1.5.  Requirement Levels

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Compliant implementations must follow this specification.

Top      ToC       Page 8 
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.

   Figure 2 shows a block diagram of the printer and its basic 13 sub-
   units.

Top      ToC       Page 9 
                    Figure 2 - Printer Block Diagram

                           Physical Connections
                                   |
                                +-----------+
                                |           |
                            +-------------+ |
                            |  Interface  |-+
                            |    MIB-II   |
                            +-------------+
                                   |
                                +-----------+
                                |           |
                            +-------------+ |    +-----------+
                            | Channel     |-+    | Operator  |
                            |             |      |  Console  |
                            +-------------+      +-----------+
                                   |
                                +-----------+        +---------+
                                |           |        |         |
        +-----------+       +-------------+ |    +-----------+ |
        |  General  |       | Interpreter |-+    |  Alerts   |-+
        |  Printer  |       |             |      |           |
        +-----------+       +-------------+      +-----------+
                                   |
                   +-------------------------------+
                   |        System Controller      |
                   |        HOST-RESOURCES-MIB     |
                   +-------------------------------+

   +------+                    +--------+                  +--------+
   |      |                    |        |                  |        |
+-------+ |    +-------+    +---------+ |    +-------+   +--------+ |
| Input |-+  +--------+|    |  Marker |-+  +--------+|   | Output |-+
|       |===>|        |+<==>|         |<==>|        |+==>|        |
+-------+    +--+  +--+     +---------+    +--+  +--+    +--------+
   \            |  ||                         |  ||         \
    \           |  ||                         |  ||          \
     \          |  ||                         |  ||           \
    +--------+  |  |+-------------------------|  ||         +---------+
    |        |  |  +--------------------------+  ||         |         |
+----------+ |  |            Media Path          |+      +----------+ |
|  Media   |-+  +--------------------------------+       | Finisher |-+
|(optional)|                                             |(optional)|
+----------+                                             +----------+

Top      ToC       Page 10 
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 that 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 Group in the model represents
   the general printer sub-unit.  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.

2.2.1.1.  International Considerations

   The localization portion of the general printer sub-unit is
   responsible for identifying the natural language, country, and
   character set in which certain character strings are expressed in

Top      ToC       Page 11 
   this MIB.  Character sets are identified in this MIB using the
   IANACharset textual convention imported from the IANA Character Set
   MIB [CHARMIB].

   There may be one or more localizations supported per printer.  The
   available localizations are specified in the Localization table.
   Localization SHOULD only be performed on string objects which are
   named 'xxxDescription' (sub-unit descriptions) or
   'prtConsoleDisplayBufferText' (local console text).

   The agent SHALL return all other character strings in coded character
   sets in which code positions 0-127 (decimal) are US-ASCII [ASCII].
   The agent SHOULD return all other character strings in the UTF-8
   [RFC3629] transform of ISO 10646 [ISO10646], to conform with the IETF
   Policy on Character Sets and Languages [RFC2277].  Control codes
   (code positions 0-31 and 127 decimal) SHALL NOT be used unless
   specifically required in the DESCRIPTION of an object.

   The character set portion of the general printer Localization table
   is responsible for identifying the possible character sets for the
   operator console, and network management requests for display
   objects.  There may be one or more character sets per printer.
   Default coded character sets for interpreter unit and output octets
   are described in the interpreter sub-unit by
   prtInterpreterDefaultCharSetIn and prtInterpreterDefaultCharSetOut.
   These input/output character sets may be overridden by commands in
   the interpreter language itself.

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.  The
   Input Group in the model represents these.  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 one tray has both a manual and
   auto feeding option, then this is two input sub-units if these two
   sources can be (must be) separately selected.  However, the above
   would be considered one input sub-unit if putting a sheet in the
   manual feed slot overrides feeding from the contents of the tray.  In
   the second case there is no way to separately select or address the
   manual feed slot.

Top      ToC       Page 12 
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 media 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.  The Output Group in the model represents the one or more
   output mechanisms contained by a printer.  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
   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 Group in the model represents the
   finisher sub-units.  Some examples of finishing processes are
   stapling, punching, binding, inserting, or folding.  Finishing
   processes may have supplies associated 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 described in the companion Finisher MIB
   [RFC3806].

   The model does not specify the exact interaction and sequencing
   between an output device and its associated finisher.  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

Top      ToC       Page 13 
   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 Group in the model represents the marker sub-units and
   their associated supplies.  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 image setter
   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
   xerographic 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
   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 (e.g., fuser oil) 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.  The Media Path Group in the model
   represents these.  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, duplex 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

Top      ToC       Page 14 
   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 is
   marked.

2.2.8.  System Controller

   The System Controller is the sub-unit upon which the software
   components of the Printer run.  The Host Resources MIB [RFC2790]
   represents the System Controller in the model.  The Host Resources
   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 [RFC1213], [RFC2863].  Some
   examples of 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.  Print Job Delivery Channels

   The print job delivery 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 Print Job Delivery Channel Group in the
   Model.  The electronic path typically identifies each channel 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 that 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.  Print Job
   Delivery Channel sub-units can, and usually are, based on an
   underlying interface.

Top      ToC       Page 15 
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 Group in the Model represents the interpreter sub-
   units. 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.  The Console Group in the model represents
   this console sub-unit.  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 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 exception to this rule is
   when the "alertRemovalofBinaryChangeEntry" trap is generated.  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, and detailed location within the sub-unit, alert code and
   description of each alert that is currently active within the
   printer.  Each reportable event causes an entry to be made in the
   Alert Table.

Top      ToC       Page 16 
2.2.13.1.  Status and Alerts

   Summary information about the state of the printer is reported at
   three separate levels: (1) The status of the printer as a whole is
   reported in the Host Resources MIB, (2) The status of various sub-
   units is reported in the principle table of the Group that represents
   the sub-unit, and (3) Alert codes are 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 terminology).  A trained
   service person is typically necessary to make it available.

   Moving on-line or off-line - The printer is either off-line, in the
   process of moving off-line or moving back on-line.  For example, on
   printers with motorized hoppers, reloading paper involves a
   transition to off-line to open the paper bin, filling the hopper and,
   finally, a transition back to on-line as the paper bin is
   repositioned for printing.

   Standby - The printer or sub-unit is not immediately available but
   can accept new instructions.

   Available - The printer or subunit is functioning normally.

   Idle - The printer or subunit is immediately available.

   Active - The printer or subunit is performing its primary function.

   Busy - The printer or subunit is performing a function (not
   necessarily its primary function) and is not immediately available
   for its primary function.

Top      ToC       Page 17 
   The Host Resources MIB [RFC2790] provides three status objects that
   can be used to describe the status of a printer: (1) hrDeviceStatus
   in the entry in the 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 values of the
   three printer-related objects in the Host Resources MIB relate to the
   states named above:

   Printer       hrDeviceStatus hrPrinterStatus hrPrinterDetected-
   Status                                       ErrorState

   Idle           running(2)     idle(3)        none set

   Busy/          running(2)     printing(4)
   Active

   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)
   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 Resources 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.

Top      ToC       Page 18 
   Detailed status per sub-unit is reported in the sub-unit status
   fields.

2.2.13.2.1.  Host Resources MIB Printer Status

   For completeness, the definitions of the Printer Status objects of
   the Host Resources MIB [RFC2790] 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
        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

Top      ToC       Page 19 
        "The current status of this printer device.  When in the
        idle(3), printing(4), or warmup(5) state, the corresponding
        hrDeviceStatus should be running(2) or warning(3).  When in
        the unknown(2) state, the corresponding hrDeviceStatus
        should be unknown(1)."
       ::= { hrPrinterEntry 1 }

   hrPrinterDetectedErrorState OBJECT-TYPE
       SYNTAX OCTET STRING (0..128)
       ACCESS read-only
       STATUS mandatory
       DESCRIPTION
        "This object represents any error conditions detected by the
        printer.  The error conditions are encoded as an OCTET STRING
        with the following definitions:

        Condition          Bit #

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

        inputTrayMissing     8
        outputTrayMissing    9
        markerSupplyMissing 10
        outputNearFull      11
        outputFull          12
        inputTrayEmpty      13
        overduePreventMaint 14

        Bit # 15 is not assigned.

        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

Top      ToC       Page 20 
        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 PrtSubUnitStatusTC 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
           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

           State is On-Line                 0
           State is Off-Line               32

   Transitioning

           At intended state                0
           Transitioning to intended state 64

Top      ToC       Page 21 
   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 an 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.  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 unary 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

Top      ToC       Page 22 
   when that is accomplished.  The trailing edge event exits the state
   that 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 signaled 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.  Removing the leading edge entry
   may cause the unary change event "alertRemovalofBinaryChangeEntry" to
   be added to the table.  With binary change 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 unary 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 might be
   changed to executive instead.  This is where the problem occurs.  It
   is not obvious how long to keep unary change event entries in the
   Alert Table.  If 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 unary alerts that would overflow the storage capacity of the
   table.  When the table is full and new alerts need to be added, an
   old alert to be deleted should be chosen using the following rules:

   1. Find a non-critical unary alert and delete it.  If there are
      multiple non-critical unary alerts, it is suggested that the
      oldest one is chosen.  If there are no non-critical unary 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 is chosen.  If there are no non-critical binary alerts,
      then,

Top      ToC       Page 23 
   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 implementers 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.

   In the event that a critical binary alert has been deleted out of the
   alert table; when space allows and the alert condition still exists,
   the alert should be re-added to the alert table even if there was no
   subsequent transition into the associated state.  It is recommended
   that this be done for non-critical binary alerts as well.  Note that
   the new alert entry will not have the same index as the original
   entry that was moved out of the table.

   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.  The management application may want to re-acquire the
   Printer state and check for state changes that it did not observe in
   the Alert Table if such gaps are detected.

2.3.  Read-Write Objects

   Some objects in the printer MIB reflect the existence or amount of a
   given resource within the printer.  Some examples of such resources
   are the size and number of sheets in a paper tray or the existence of
   certain output options.  Some printers have automatic sensors for
   these resources.  Most printers lack sensors for every property of
   every resource.  The management application is allowed to write into
   objects that hold descriptive or existence values for printers that
   cannot sense these values.  The ability to change the value of a
   read- write object may depend on the implementation of the agent.
   Many objects in the MIB are given read-write access, but a printer
   implementation might only permit a management application to change
   the value if the printer can not sense the value itself.  Note that
   even though some objects explicitly state the behavior of conditional
   ability to change values, any read-write object may act this 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

Top      ToC       Page 24 
   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
      "sticky-note". 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.

   3. 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.

   4. 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.

2.4.  Enumerations

   Enumerations (enums) are sets of symbolic values defined for use with
   one or more objects.  Commonly used enumeration sets are assigned a
   symbolic data type name (textual convention), rather than being
   specified in the SYNTAX clause of each individual object definition.

   Textual conventions defined in the Printer MIB or the companion IANA
   Printer MIB are extensible by RFC publication or by Designated Expert
   Review (see the 'IANA Considerations' section of this Printer MIB and
   the DESCRIPTION clause in MODULE-IDENTITY of IANA Printer MIB).  All
   of these textual conventions are:

   a) used more than once in the Printer MIB itself; or

   b) imported and used in the companion Finisher MIB; or

   c) imported and used in any other, including vendor private, MIB
      modules.

Top      ToC       Page 25 
   The Printer MIB has also defined the following special values for use
   with objects of the syntax "Integer32" to define conditions that are
   outside of the normal numeric range:  other(-1), unknown(-2), and
   partial(-3).  The 'partial' value means that there is some supply
   remaining (but the amount is indeterminate) or there is some capacity
   remaining (but the amount is indeterminate).  The Integer32 range
   field indicates in which objects these special values are valid.

2.4.1.  Registering Additional Enumerated Values

   The Printer MIB and the companion IANA Printer MIB each defines one
   category of textual convention, according to the process employed to
   control the addition of new enumerations:

   Type 1 - All of the legal values are defined in the Printer MIB.
   Additional enumerated values require the publication of a new Printer
   MIB.

   Type 2 - All of the legal values are registered in the IANA Printer
   MIB.  Additional enumerated values require a Designated Expert Review
   defined in "Guidelines for Writing an IANA Considerations Section in
   RFCs" [RFC2434].  The Designated Expert will be selected by the IETF
   Area Director(s) of the Applications Area.



(page 25 continued on part 2)

Next RFC Part