[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]
Alternate Formats: rfc3805.txt | rfc3805.txt.pdf
RFC 3805 - Printer MIB v2
|
 |
RFC3805 - Printer MIB v2
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.
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
-- 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
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.
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 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
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.
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.
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)|
+----------+ +----------+
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
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.
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
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
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.
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.
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.
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.
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
"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
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
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
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,
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
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.
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.
3. Groups from other MIB Specifications
This section identifies the groups from other MIBs that shall be
supported to supplement and complete a printer MIB implementation.
The section also describes some of the less obvious characteristics
of the Printer MIB structure that are related to the inclusion of
these other MIB groups.
3.1. System Group
All objects in the system group of MIB-II [RFC1213] shall be
implemented; however, as described in paragraph 2.4, implementers
should carefully consider what constitutes the "system".
3.2. System Controller
The storage and device groups of the Host Resources MIB [RFC2790]
shall be implemented to support the printer(s) system controller, and
any supporting devices. If deemed appropriate by the implementer,
other groups of the Host Resources MIB (System, Running Software,
Running Software Performance, and Installed Software) may be
implemented. Because of the structure of the Host Resources MIB, the
devices constituting the system controller are at the same level as
the printer.
3.3. Interface Group objects
All objects in the Interfaces Group of MIB-II [RFC1213] shall be
implemented for all print information interfaces to the printer,
including non-network interfaces.
3.3.1. Interface Types
The interfaces group of RFC 1213 [RFC1213] contains only a partial
list of interface types that can be specified in the "ifType" object.
For a complete list of interface types, refer to the IANA registry at
"ftp://ftp.isi.edu/mib/iana.mib/ianaiftype.mib"
4. Differences from RFC 1759
This document supersedes and replaces RFC 1759. However, a compliant
implementation of RFC 1759 is also compliant with this document. The
following changes to RFC 1759 are included: (See the printmib
REVISION/DESCRIPTION clause for additional details of changes.)
- Minor editorial corrections and changes. Updated the cover page
and added the "SNMP Management Framework" boilerplate to section
1.
- Updated figure 2 to use MIB names instead of RFC numbers.
- Updated Coded Character Set description and IANA registration
process.
- Change hrPrinterDetectedErrorState "coverOpen" (bit 4) to
"doorOpen" per RFC 2790.
- Added second octet of hrPrinterDetectedErrorState as partially
described and assigned in the updated Host Resources MIB (RFC
2790).
- Remove fixed association of hrDeviceStatus (warning/down) from
hrPrinterDetetctedErrorState per RFC 2790.
- Instead of showing bit 15 as "not assigned" in the quote from RFC
2790 in the hrPrinterDetectedErrorState object, removed that from
the tabular form and added it as a sentence, because the RFC
doesn't show bit 15 in the tabular form.
- Clarified the international considerations.
- Added prtChannelInformation to the Channel Group textual-
conventions on a per channel basis to clarify the channel
description and enhance interoperability.
- Deprecated some obsolete channel types.
- Extended the Alert Table and PrtMarkerSuppliesSupplyUnit textual
conventions to include values from the Finisher MIB.
- Clarified alerts based on unary vs. binary change events.
- Added (optional) unary change event
alertRemovalOfBinaryChangeEntry(1801).
- Establish a convention for contact information for
prtGeneralCurrentOperator and prtGeneralServicePerson.
- Added prtAuxiliarySheetStartupPage PresentOnOff
- Added prtAuxiliarySheetBannerPage PresentOnOff
- Added prtGeneralPrinterName OCTET STRING
- Added prtGeneralSerialNumber OCTET STRING
- Added prtInputNextIndex Integer32
- Added the Input Switching Group
- Added prtAlertCriticalEvents Counter32
- Added prtAlertAllEvents Counter32
- Updated PrtAlertCode enums including generic alert codes.
- Created five OBJECT-GROUPs (prtAuxilliarySheetGroup,
prtInputSwitchingGroup, prtGeneralV2Group, prtAlertTableV2Group,
prtChannelV2Group). Added the nine new objects to them
(prtAuxiliarySheetStartupPage, prtAuxiliarySheetBannerPage,
prtGeneralPrinterName, prtGeneralSerialNumber,
prtAlertCriticalEvents, prtAlertAllEvents,
prtInputMediaLoadTimeout, prtInputNextIndex,
prtChannelInformation). Created one new NOTIFICATION-GROUP
(prtAlertTrapGroup) to contain printerV2Alert. Included the new
OBJECT-GROUPs and the NOTIFICATION_GROUP in prtMIBCompliance, all
in GROUP (not MANDATORY-GROUP) clauses. The nine new objects are
optional, i.e., this document is backward compatible with RFC
1759.
- prtAlertTime is strongly recommended.
- Deprecated the use of alert codes doorOpen(501) and
doorClosed(502), in favor of coverOpened(3) and coverClosed(4).
- Added the PrtConsoleDisableTC and PrtMarkerAddressabilityUnitTC
textual conventions, and changed the PrtConsoleDisable and
PrtMarkerAddressabilityUnit objects' syntax to use those TCs, and
changed the PrtGeneralEntry and PrtMarkerColorantEntry SEQUENCEs
to reflect the new syntax.
- Added textual conventions "PrtLocalizedDescriptionStringTC" and
"PrtConsoleDescriptionStringTC" and updated several objects to use
them.
- Changed most enumerations to textual conventions and therefore
changed the SYNTAX of many objects from RFC 1759 to specify the
appropriate textual conventions. (28 TCs were added.)
- Changed the TC names "MediaUnit" to "PrtMediaUnitTC",
"CapacityUnit" to "PrtCapacityUnitTC", and "SubUnitStatus" to
"PrtSubUnitStatusTC"
- All objects with a MAX-ACCESS of read-write now have a MIN-ACCESS
of read-only.
- Added 'IANA Considerations' and 'Internationalization
Considerations' as top level sections, per IETF guidelines.
- Updated Security and Copyright sections.
- Updated references and split into Normative and Informative
groups.
- Added Appendix E - Overall Printer Status Table.
- Updated participant and contact information.
- Removed CodedCharSet Textual Convention, replaced with an import
of the IANACharset.
- Removed all comment statements that indicated objects or groups
are mandatory or optional. Avoids any potential conflicts with
the conformance section.
- Added text to empty description clauses. (prtStorageRefTable,
prtDeviceRefTable, prtMarkerTable, prtMediaPathTable,
prtChannelTable, prtInterpreterTable, prtConsoleLightTable, and
prtAlertTable)
- Added "DEFVAL { unknown }" to prtInterpreterDefaultCharSetIn and
prtInterpreterDefaultCharSetOut.
- Changed "...values are expected to remain stable..." to "...values
SHOULD remain stable..." in the description clauses for the index
object in all tables.
- Added ranges to all objects with a syntax of Integer32.
- Revised the description clause for prtAlertGroupIndex.
- Added additional text to the description clause for
prtMediaPathEntry, prtChannelEntry, prtInterpreterEntry, and
printerV2Alert.
- Added text to section 2.4 to explain the usage of textual
conventions in this MIB and others. Also added a note defining
the common usage of the enumerations 'other(-1)' and 'unknown(-2)'
- Changed range of prtStorageRefSeqNumber, prtDeviceRefSeqNumber,
and prtConsoleLightIndex from (0..65535) to (1..65535) since index
values cannot be zero. (Typo in RFC 1759)
- The PWG Standard for Standardized Media Names is now recommended
for the objects prtInputMediaName, prtInputMediaColor, and
prtInputMediaType.
- Added chSMTP(45) to prtChannelTypeTC.
5. The IANA Printer MIB
IANA-PRINTER-MIB DEFINITIONS ::= BEGIN
-- http://www.iana.org/assignments/ianaprinter-mib
IMPORTS
MODULE-IDENTITY,
mib-2
FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- [RFC2579]
ianaPrinterMIB MODULE-IDENTITY
LAST-UPDATED "200406020000Z" -- June 2, 2004
ORGANIZATION "IANA"
CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 823 9358
E-Mail: iana@iana.org"
DESCRIPTION "This MIB module defines a set of printing-related
TEXTUAL-CONVENTIONs for use in Printer MIB (RFC 3805),
Finisher MIB (RFC 3806), and other MIBs which need to
specify printing mechanism details.
Any additions or changes to the contents of this MIB
module require either publication of an RFC, or
Designated Expert Review as defined in RFC 2434,
Guidelines for Writing an IANA Considerations Section
in RFCs. The Designated Expert will be selected by
the IESG Area Director(s) of the Applications Area.
Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3805. For full legal notices see the RFC
itself or see:
http://www.ietf.org/copyrights/ianamib.html"
REVISION "200406020000Z" -- June 2, 2004
DESCRIPTION "Original version, published in coordination
with Printer MIB (RFC 3805)."
::= { mib-2 109 }
--
-- Generic TEXTUAL-CONVENTIONs
--
PrtCoverStatusTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtCoverStatus in RFC 1759.
STATUS current
DESCRIPTION
"Values for encoding the state of a particular cover or
access panel on the printer case or enclosure."
SYNTAX INTEGER {
other(1),
coverOpen(3),
coverClosed(4),
interlockOpen(5),
interlockClosed(6)
}
--
-- General Group TEXTUAL-CONVENTIONs
--
PrtGeneralResetTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtGeneralReset in RFC 1759.
STATUS current
DESCRIPTION
"Values for reading and writing the prtGeneralReset object.
If a device does not have NVRAM, the device shall none the
less respond to a SET with the value resetToNVRAM(5) with a
sort of warm reset that resets the device to implementation-
defined state that is preferably under control of the system
administrator by some means outside the scope of the Printer
MIB specification."
SYNTAX INTEGER {
notResetting(3),
powerCycleReset(4), -- Cold Start
resetToNVRAM(5), -- Warm Start
resetToFactoryDefaults(6) -- Reset contents of
-- NVRAM to factory
-- defaults
}
--
-- Channel Group TEXTUAL-CONVENTIONs
--
PrtChannelTypeTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtChannelType in RFC 1759.
STATUS current
DESCRIPTION
"This enumeration indicates the type of channel that is
receiving jobs."
SYNTAX INTEGER {
other(1),
chSerialPort(3),
chParallelPort(4),
chIEEE1284Port(5),
chSCSIPort(6),
chAppleTalkPAP(7),
-- AppleTalk Printer
-- Access Protocol (PAP)
--
-- prtChannelInformation entry:
--
-- Printer Name
-- Keyword: Name
-- Syntax: Name
-- Status: Optional
-- Multiplicity: Single
-- Description: The name of the printer
-- within the AppleTalk naming scope
chLPDServer(8),
-- prtChannelInformation entry:
--
-- Printer queue name
-- Keyword: Queue
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: queue name as
-- defined in [RFC1179].
chNetwareRPrinter(9),
-- Novell, Inc.
-- For each entry of this type, the
-- prtChannelInformation must have a pair of
-- keywords. For Netware 3.x channels this must
-- be a (PServer, Printer) pair. For Netware
-- 4.x channels and for IntranetWare channels
-- this must be a (NDSTree, NDSPrinter) pair.
--
-- prtChannelInformation entries:
-- Print Server Name
-- Keyword: PServer
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The Pserver's SAP name
--
-- Printer Number
-- Keyword: Printer
-- Syntax: Integer
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The printer number
--
-- NDSTree
-- Keyword: NDSTree
-- Syntax: Name
-- Multiplicity: Single
-- Description: The tree's SAP name
--
-- NDS Printer object
-- Keyword: NDSPrinter
-- Syntax: Text (Unicode)
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The fully qualified
-- name of the Printer
--
-- In the Netware 3.x environment, the
-- client checks the Bindery object
-- representing the named PServer. The
-- client then checks for queues which
-- are associated with the numbered
-- printer. In the 4.x and IntraNetware
-- environment, the client looks up the
-- queues which are associated with the
-- NDS Printer Object in the named Tree.
-- Depending on client access rights to
-- those queues, the client submits jobs
-- to the appropriate queue.
chNetwarePServer(10),
-- Novell,Inc.
-- For each entry of this type, the
-- prtChannelInformation must have a pair
-- of keywords. For Netware 3.x channels
-- this must be a (Server, PServer) pair.
-- For Netware 4.x and IntranetWare
-- channels, this must be a
-- (NDSTree, NDSPServer) pair.
--
-- prtChannelInformation entries:
--
-- Server Name
-- Keyword: Server
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The SAP name of the
-- server for which the PServer is defined.
--
-- PServer
-- Keyword: PServer
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The bindery name of
-- the PServer
--
-- NDS Tree
-- Keyword: NDSTree
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The NDS Tree name
--
-- PServer
-- Keyword: NDSPServer
-- Syntax: Text (Unicode)
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The fully qualified
-- name of the PServer object in the tree.
--
-- In the 3.x environment, the client
-- checks the bindery object
-- representing the named PServer on the
-- named Server. In the 4.x and
-- IntranetWare environment,
-- the client checks the NDS object
-- representing the named PServer in the
-- named Tree. In either case, the
-- client then checks for all queues
-- associated with the Pserver object.
-- Depending on client access rights
-- to those queues, the client submits
-- jobs to the appropriate queue.
chPort9100(11),
-- DEPRECATED
-- (see chPortTCP - 37; chBidirPortTCP - 38)
chAppSocket(12),
-- A bi-directional, LPD-like, protocol using
-- 9101 for control and 9100 for data.
-- Adobe Systems, Inc.
chFTP(13), -- [RFC959]
chTFTP(14), -- [RFC1350]
chDLCLLCPort(15),
chIBM3270(16), -- IBM Coax
chIBM5250(17), -- IBM Twinax
chFax(18),
chIEEE1394(19),
chTransport1(20),
-- TCP port 35, for reserved TCP port list see
-- [RFC3232]. This RFC should also be
-- referenced for other channel
-- enumerations utilizing TCP port
-- numbers 0 through 1024.
chCPAP(21), -- TCP port 170
-- Digital Equipment Corp.
chDCERemoteProcCall(22), -- OSF
-- DEPRECATED
chONCRemoteProcCall(23), -- SUN Microsystems
-- DEPRECATED
chOLE(24), -- Microsoft
-- DEPRECATED
chNamedPipe(25),
chPCPrint(26), -- Banyan
chServerMessageBlock(27),
-- File/Print sharing protocol used by
-- various network operating systems
-- from IBM 3Com, Microsoft and others
--
-- prtChannelInformation entry:
--
-- Service Name
-- Keyword: Name
-- Syntax: Name
-- Status: Optional
-- Multiplicity: Single
-- Description: The service name of
-- the printer
chDPMF(28), -- IBM Infoprint
chDLLAPI(29), -- Microsoft
-- DEPRECATED
chVxDAPI(30), -- Microsoft
-- DEPRECATED
chSystemObjectManager(31), -- IBM
chDECLAT(32),
-- Digital Equipment Corp.
--
-- prtChannelInformation entries:
--
-- Port Name
-- Keyword: Port
-- Syntax: Name
-- Status: Conditionally
-- Mandatory
-- (see note below)
-- Multiplicity: Single
-- Description: LAT port name
--
-- Service Name
-- Keyword: Service
-- Syntax: Name
-- Status: Conditionally
-- Mandatory
-- Multiplicity: Single
-- Description: LAT service name
--
-- The LAT channel may be
-- identified by either a port or
-- service, so either a
-- Port or Service entry must be
-- specified, but not both.
chNPAP(33),
chUSB(34), -- Not in RFC 1759
-- Universal Serial Bus
chIRDA(35), -- Not in RFC 1759
-- Infrared Data Assoc. Prot.
chPrintXChange(36), -- Not in RFC 1759
-- PrintXChange Protocol
chPortTCP(37), -- Not in RFC 1759
-- A unidirectional "raw" TCP
-- channel that uses an administratively
-- assigned TCP port address.
--
-- prtChannelInformation entry:
--
-- Port Number
-- Keyword: Port
-- Syntax: decimal number
-- Status: Mandatory
-- Multiplicity: Single
-- Description: TCP port number
chBidirPortTCP(38), -- Not in RFC 1759
-- A bi-directional version of chPortTCP
--
-- prtChannelInformation entries:
-- (See chPortTCP)
chUNPP(39), -- Not in RFC 1759
-- Universal Network Printing
-- Protocol(UNPP). A bi-directional,
-- multiport network printing
-- application protocol available on
-- multiple transport protocols.
-- Underscore, Inc.
-- Contact: info@underscore.com
chAppleTalkADSP(40), -- Not in RFC 1759
-- AppleTalk Data Stream Protocol.
-- ADSP is part of the AppleTalk
-- suite of protocols.
-- It is a symmetric, connection-
-- oriented protocol that makes
-- possible the establishment
-- and maintenance of full-duplex
-- streams of data bytes between
-- two sockets in an AppleTalk
-- internet.
-- See [APPLEMAC].
chPortSPX(41), -- Not in RFC 1759
-- Sequenced Packet Exchange (SPX)
-- socket.
-- Novell, Inc. Similar to TCP, a
-- bi-directional data pipe using
-- Novell SPX as a transport.
--
-- prtChannelInformation entries:
--
-- Network Number
-- Keyword: Net
-- Syntax: HexString
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The network number
--
-- Node Number
-- Keyword: Node
-- Syntax: HexString
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The node number
--
-- Socket Number
-- Keyword: Socket
-- Syntax: HexString
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The SPX socket number
--
-- There must be exactly one "Net" and
-- one "Node" and one "Socket" entry. A
-- HexString is a binary value
-- represented as a string of
-- ASCII characters using hexadecimal
-- notation.
chPortHTTP(42), -- Not in RFC 1759
-- Hypertext Transfer Protocol. See [RFC1945]
-- and [RFC2616].
chNDPS(43), -- Not in RFC 1759
-- Novell, Inc.
--
-- prtChannelInformation entry:
--
-- Printer Agent Name
-- Keyword: PA
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Description: The NDPS Printer
-- Agent Name
chIPP(44), -- Not in RFC 1759
-- Internet Printing Protocol (IPP),
-- (IPP/1.1 - see [RFC2910] and [RFC2911])
-- also applies to all future versions of IPP.
--
-- IPP Printer URI
-- Keyword: URI
-- Syntax: URI (Unicode UTF-8 per
-- [RFC2396])
-- Status: Mandatory
-- Multiplicity: Single
-- Default: not applicable
-- Description: URI of this IPP Printer
-- within Internet naming scope. Unicode
-- UTF-8 [RFC3629] string with
-- hexadecimal escapes for any non-ASCII
-- characters (per [RFC2396]).
-- Conformance: An IPP Printer shall list all
-- IPP URI it supports (one per IPP Channel
-- entry). If a URI contains the 'http:'
-- scheme it must have an explicit port.
-- See: [RFC3629], [RFC2396], [RFC2910],
-- [RFC2911].
--
-- IPP Printer Client Authentication
-- Keyword: Auth
-- Syntax: Keyword
-- Status: Optional
-- Multiplicity: Single
-- Default: 'none'
-- Description: A client authentication
-- mechanism supported for this IPP Printer
-- URI:
-- 'none'
-- no client authentication mechanism
-- 'requesting-user-name'
-- authenticated user in 'requesting-
-- user-name'
-- 'basic'
-- authenticated user via HTTP Basic
-- mechanism
-- 'digest'
-- authenticated user via HTTP Digest
-- mechanism
-- 'certificate'
-- authenticated user via certificate
-- mechanism
-- Conformance: An IPP Printer should list
-- all IPP client authentication mechanisms
-- it supports (one per IPP Channel entry).
-- See: [RFC2911] and [RFC2910].
--
-- IPP Printer Security
-- Keyword: Security
-- Syntax: Keyword
-- Status: Optional
-- Multiplicity: Single
-- Default: 'none'
-- Description: A security mechanism
-- supported for this IPP Printer URI:
-- 'none'
-- no security mechanism
-- 'ssl3'
-- SSL3 secure communications channel
-- protocol
-- 'tls'
-- TLS secure communications channel
-- protocol
-- Conformance: An IPP Printer should list
-- all IPP security mechanisms it supports
-- (one per IPP Channel entry).
-- See: [RFC2246], [RFC2911].
--
-- IPP Printer Protocol Version
-- Keyword: Version
-- Syntax: Keyword
-- Status: Optional
-- Multiplicity: Multiple
-- Default: '1.1'
-- Description: All of the IPP protocol
-- versions (major.minor) supported for
-- this IPP Printer URI:
-- '1.0'
-- IPP/1.0 conforming Printer
-- '1.1'
-- IPP/1.1 conforming Printer
-- Conformance: An IPP Printer should list
-- all IPP versions it supports (all listed
-- in each IPP Channel entry). An IPP
-- Client should select the highest
-- numbered version the IPP Client supports
-- for use in all IPP Requests (for optimum
-- interworking).
-- See: [RFC2911].
chSMTP(45)
-- Print Job submission via Simple Mail
-- Transfer Protocol (SMTP) - see [RFC2821]
--
-- prtChannelInformation entry:
--
-- Keyword: Mailto
-- Syntax: Name
-- Status: Mandatory
-- Multiplicity: Single
-- Default: not applicable
-- Description: The SMTP URL of the printer.
}
--
-- Interpreter Group TEXTUAL-CONVENTIONs
--
PrtInterpreterLangFamilyTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtInterpreterLangFamily in RFC 1759.
STATUS current
DESCRIPTION
"This enumeration indicates the type of interpreter that is
receiving jobs."
SYNTAX INTEGER {
other(1),
unknown(2), -- Not in RFC 1759
langPCL(3), -- PCL. Starting with PCL version 5,
-- HP-GL/2 is included as part of the
-- PCL language.
-- PCL and HP-GL/2 are registered
-- trademarks of Hewlett-Packard
-- Company.
langHPGL(4), -- Hewlett-Packard Graphics Language.
-- HP-GL is a registered trademark of
-- Hewlett-Packard Company.
langPJL(5), -- Peripheral Job Language. Appears in
-- the data stream between data intended
-- for a page description language.
-- Hewlett-Packard Co.
langPS(6), -- PostScript (tm) Language
-- Postscript - a trademark of Adobe
-- Systems Incorporated which may be
-- registered in certain jurisdictions
langIPDS(7), -- Intelligent Printer Data Stream
-- Bi-directional print data stream for
-- documents consisting of data objects
-- (text, image, graphics, bar codes),
-- resources (fonts, overlays) and page,
-- form and finishing instructions.
-- Facilitates system level device
-- control, document tracking and error
-- recovery throughout the print
-- process.
-- IBM Corporation.
langPPDS(8), -- IBM Personal Printer Data Stream.
-- Originally called IBM ASCII, the name
-- was changed to PPDS when the Laser
-- Printer was introduced in 1989.
-- Lexmark International, Inc.
langEscapeP(9), -- Epson Corp.
langEpson(10),
langDDIF(11), -- Digital Document Interchange Format
-- Digital Equipment Corp., Maynard MA
langInterpress(12),
-- Xerox Corp.
langISO6429(13), -- ISO 6429. Control functions for
-- Coded Character Sets (has ASCII
-- control characters, plus additional
-- controls for
-- character imaging devices.)
langLineData(14), -- line-data: Lines of data as
-- separate ASCII or EBCDIC records
-- and containing no control functions
-- (no CR, LF, HT, FF, etc.)
-- For use with traditional line
-- printers. May use CR and/or LF to
-- delimit lines, instead of records.
-- See ISO 10175 Document Printing
-- Application (DPA) [ISO10175].
langMODCA(15), -- Mixed Object Document Content
-- Architecture
-- Definitions that allow the
-- composition, interchange, and
-- presentation of final form
-- documents as a collection of data
-- objects (text, image, graphics, bar
-- codes), resources (fonts, overlays)
-- and page, form and finishing
-- instructions.
-- IBM Corporation.
langREGIS(16), -- Remote Graphics Instruction Set,
-- Digital Equipment Corp., Maynard MA
langSCS(17), -- SNA Character String
-- Bi-directional print data stream for
-- SNA LU-1 mode of communication.
-- IBM
langSPDL(18), -- ISO 10180 Standard Page Description
-- Language
-- ISO Standard
langTEK4014(19), -- Tektronix Corp.
langPDS(20),
langIGP(21), -- Printronix Corp.
langCodeV(22), -- Magnum Code-V, Image and printer
-- control language used to control
-- impact/dot-matrix printers.
-- QMS, Inc., Mobile AL
langDSCDSE(23), -- DSC-DSE: Data Stream Compatible and
-- Emulation Bi-directional print data
-- stream for non-SNA (DSC) and SNA LU-3
-- 3270 controller (DSE) communications
-- IBM
langWPS(24), -- Windows Printing System, Resource
-- based command/data stream used by
-- Microsoft At Work Peripherals.
-- Developed by the Microsoft
-- Corporation.
langLN03(25), -- Early DEC-PPL3, Digital Equipment
-- Corp.
langCCITT(26),
langQUIC(27), -- QUIC (Quality Information Code), Page
-- Description Language for laser
-- printers. Included graphics, printer
-- control capability and emulation of
-- other well-known printer.
-- QMS, Inc.
langCPAP(28), -- Common Printer Access Protocol
-- Digital Equipment Corp.
langDecPPL(29), -- Digital ANSI-Compliant Printing
-- Protocol
-- (DEC-PPL)
-- Digital Equipment Corp.
langSimpleText(30),
-- simple-text: character coded data,
-- including NUL, CR , LF, HT, and FF
-- control characters. See ISO 10175
-- Document Printing Application (DPA)
-- [ISO10175].
langNPAP(31), -- Network Printer Alliance Protocol
-- (NPAP). This protocol has been
-- superseded by the IEEE 1284.1 TIPSI
-- Std (ref. LangTIPSI(49)).
langDOC(32), -- Document Option Commands, Appears in
-- the data stream between data
-- intended for a page description.
-- QMS, Inc.
langimPress(33), -- imPRESS, Page description language
-- originally developed for the
-- ImageServer product line. A binary
-- language providing representations
-- of text, simple graphics, and some
-- large forms (simple
-- bit-map and CCITT group 3/4
-- encoded).The
-- language was intended to be sent over
-- an 8-bit channel and supported early
-- document preparation languages (e.g.,
-- TeX and TROFF).
-- QMS, Inc.
langPinwriter(34),
-- 24 wire dot matrix printer for
-- USA, Europe, and Asia except
-- Japan.
-- More widely used in Germany, and
-- some Asian countries than in US.
-- NEC
langNPDL(35), -- Page printer for Japanese market.
-- NEC
langNEC201PL(36), -- Serial printer language used in
-- the Japanese market.
-- NEC
langAutomatic(37),
-- Automatic PDL sensing. Automatic
-- sensing of the interpreter
-- language family by the printer
-- examining the document content.
-- Which actual interpreter language
-- families are sensed depends on
-- the printer implementation.
langPages(38), -- Page printer Advanced Graphic
-- Escape Set
-- IBM Japan
langLIPS(39), -- LBP Image Processing System
langTIFF(40), -- Tagged Image File Format (Aldus)
langDiagnostic(41),
-- A hex dump of the input to the
-- interpreter
langPSPrinter(42),
-- The PostScript Language used for
-- control (with any PDLs)
-- Adobe Systems Incorporated
langCaPSL(43), -- Canon Print Systems Language
langEXCL(44), -- Extended Command Language
-- Talaris Systems Inc.
langLCDS(45), -- Line Conditioned Data Stream
-- Xerox Corporation
langXES(46), -- Xerox Escape Sequences
-- Xerox Corporation
langPCLXL(47), -- Not in RFC 1759
-- Printer Control Language. Extended
-- language features for printing, and
-- printer control.
-- Hewlett-Packard Co.
langART(48), -- Not in RFC 1759
-- Advanced Rendering Tools (ART).
-- Page Description language
-- originally developed for the Laser
-- Press printers.
-- Technical reference manual: "ART IV
-- Reference Manual", No F33M.
-- Fuji Xerox Co., Ltd.
langTIPSI(49), -- Not in RFC 1759
-- Transport Independent Printer
-- System Interface (ref. IEEE Std.
-- 1284.1)
langPrescribe(50), -- Not in RFC 1759
-- Page description and printer
-- control language. It can be
-- described with ordinary ASCII
-- Technical reference manual:
-- "PRESCRIBE II Programming Manual"
langLinePrinter(51), -- Not in RFC 1759
-- A simple-text character stream which
-- supports the control codes LF, VT,
-- FF, and plus Centronics or
-- Dataproducts Vertical Format Unit
-- (VFU) language is commonly used on
-- many older model line and matrix
-- printers.
langIDP(52), -- Not in RFC 1759
-- Imaging Device Protocol
-- Apple Computer.
langXJCL(53), -- Not in RFC 1759
-- Xerox Job Control Language (JCL).
-- A Job Control language originally
-- developed for the LaserPress printers
-- and is capable of switching PDLs.
-- Technical reference manual:
-- "ART IV Reference Manual", No F33M.
-- Fuji Xerox Co., Ltd.
langPDF(54), -- Not in RFC 1759
-- Adobe Portable Document Format
-- Adobe Systems, Inc.
langRPDL(55), -- Not in RFC 1759
-- Ricoh Page Description Language for
-- printers.
-- Technical manual "RPDL command
-- reference" No.307029
-- RICOH, Co. LTD
langIntermecIPL(56), -- Not in RFC 1759
-- Intermec Printer Language for label
-- printers.
-- Technical Manual: "IPL Programmers
-- Reference Manual"
-- Intermec Corporation
langUBIFingerprint(57), -- Not in RFC 1759
-- An intelligent basic-like programming
-- language for label printers.
-- Reference Manual: "UBI Fingerprint
-- 7.1", No. 1-960434-00
-- United Barcode Industries
langUBIDirectProtocol(58), -- Not in RFC 1759
-- An intelligent control language for
-- label printers.
-- Programmers guide: " UBI Direct
-- Protocol", No. 1-960419-00
-- United Barcode Industries
langFujitsu(59), -- Not in RFC 1759
-- Fujitsu Printer Language
-- Reference Manual:
-- "FM Printer Sequence" No. 80HP-0770
-- FUJITSU LIMITED
langCGM(60), -- Not in RFC 1759
-- Computer Graphics Metafile
-- MIME type 'image/cgm'
langJPEG(61), -- Not in RFC 1759
-- Joint Photographic Experts Group
-- MIME type 'image/jpeg'
langCALS1(62), -- Not in RFC 1759
-- US DOD CALS1 (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
langCALS2(63), -- Not in RFC 1759
-- US DOD CALS2 (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
langNIRS(64), -- Not in RFC 1759
-- US DOD NIRS (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
langC4(65) -- Not in RFC 1759
-- US DOD C4 (see MIL-STD-1840)
-- MIME type 'application/cals-1840'
}
--
-- Input/Output Group TEXTUAL-CONVENTIONs
--
PrtInputTypeTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtInputType in RFC 1759.
STATUS current
DESCRIPTION
"The type of technology (discriminated primarily according to
feeder mechanism type) employed by a specific component or
components."
SYNTAX INTEGER {
other(1),
unknown(2),
sheetFeedAutoRemovableTray(3),
sheetFeedAutoNonRemovableTray(4),
sheetFeedManual(5),
continuousRoll(6),
continuousFanFold(7)
}
PrtOutputTypeTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtOutputType in RFC 1759.
STATUS current
DESCRIPTION
"The Type of technology supported by this output subunit."
SYNTAX INTEGER {
other(1),
unknown(2),
removableBin(3),
unRemovableBin(4),
continuousRollDevice(5),
mailBox(6),
continuousFanFold(7)
}
--
-- Marker Group TEXTUAL-CONVENTIONs
--
PrtMarkerMarkTechTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtMarkerMarkTech in RFC 1759.
STATUS current
DESCRIPTION
"The type of marking technology used for this marking
subunit."
SYNTAX INTEGER {
other(1),
unknown(2),
electrophotographicLED(3),
electrophotographicLaser(4),
electrophotographicOther(5),
impactMovingHeadDotMatrix9pin(6),
impactMovingHeadDotMatrix24pin(7),
impactMovingHeadDotMatrixOther(8),
impactMovingHeadFullyFormed(9),
impactBand(10),
impactOther(11),
inkjetAqueous(12),
inkjetSolid(13),
inkjetOther(14),
pen(15),
thermalTransfer(16),
thermalSensitive(17),
thermalDiffusion(18),
thermalOther(19),
electroerosion(20),
electrostatic(21),
photographicMicrofiche(22),
photographicImagesetter(23),
photographicOther(24),
ionDeposition(25),
eBeam(26),
typesetter(27)
}
PrtMarkerSuppliesTypeTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtMarkerSuppliesType in RFC 1759.
STATUS current
DESCRIPTION
"The type of this supply."
SYNTAX INTEGER {
other(1),
unknown(2),
-- Values for Printer MIB
toner(3),
wasteToner(4),
ink(5),
inkCartridge(6),
inkRibbon(7),
wasteInk(8),
opc(9), -- photo conductor
developer(10),
fuserOil(11),
solidWax(12),
ribbonWax(13),
wasteWax(14),
fuser(15), -- Not in RFC 1759
coronaWire(16), -- Not in RFC 1759
fuserOilWick(17), -- Not in RFC 1759
cleanerUnit(18), -- Not in RFC 1759
fuserCleaningPad(19), -- Not in RFC 1759
transferUnit(20), -- Not in RFC 1759
tonerCartridge(21), -- Not in RFC 1759
fuserOiler(22), -- Not in RFC 1759
-- End of values for Printer MIB
-- Values for Finisher MIB
water(23), -- Not in RFC 1759
wasteWater(24), -- Not in RFC 1759
glueWaterAdditive(25),-- Not in RFC 1759
wastePaper(26), -- Not in RFC 1759
bindingSupply(27), -- Not in RFC 1759
bandingSupply(28), -- Not in RFC 1759
stitchingWire(29), -- Not in RFC 1759
shrinkWrap(30), -- Not in RFC 1759
paperWrap(31), -- Not in RFC 1759
staples(32), -- Not in RFC 1759
inserts(33), -- Not in RFC 1759
covers(34) -- Not in RFC 1759
-- End of values for Finisher MIB
}
--
-- Media Path TEXTUAL-CONVENTIONs
--
PrtMediaPathTypeTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtMediaPathType in RFC 1759.
STATUS current
DESCRIPTION
"The type of the media path for this media path."
SYNTAX INTEGER {
other(1),
unknown(2),
longEdgeBindingDuplex(3),
shortEdgeBindingDuplex(4),
simplex(5)
}
--
-- Console Group TEXTUAL-CONVENTIONs
--
PrtConsoleColorTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtConsoleColor in RFC 1759.
STATUS current
DESCRIPTION
"The color of this light."
SYNTAX INTEGER {
other(1),
unknown(2),
white(3),
red(4),
green(5),
blue(6),
cyan(7),
magenta(8),
yellow(9),
orange(10) -- Not in RFC 1759
}
PrtConsoleDisableTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtConsoleDisable in RFC 1759.
STATUS current
DESCRIPTION
"This value indicates whether or not input is accepted from
the operator console. A value of 'enabled' indicates that
input is accepted from the console, and a value of 'disabled'
indicates that input is not accepted from the console. "
SYNTAX INTEGER {
enabled(3),
disabled(4)
}
--
-- Alert Group TEXTUAL-CONVENTIONs
--
PrtAlertTrainingLevelTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtAlertTrainingLevel in RFC 1759.
STATUS current
DESCRIPTION
"The level of training required to handle this alert, if
human intervention is required. The noInterventionRequired
value should be used if the event does not require any human
intervention. The training level is an enumeration that is
determined and assigned by the printer manufacturer based on
the information or training required to handle this alert.
The printer will break alerts into these different training
levels. It is the responsibility of a management application
in the system to determine how a particular alert is handled
and how and to whom that alert is routed. The following are
the four training levels of alerts:
Field Service - Alerts that typically require advanced
training and technical knowledge of the printer and its
subunits. An example of a technical person would be a
manufacturer's Field Service representative, or other
person formally trained by the manufacturer or similar
representative.
Trained - Alerts that require an intermediate or moderate
knowledge of the printer and its subunits. A typical
example of such an alert is replacing a toner cartridge.
Untrained - Alerts that can be fixed without prior
training either because the action to correct the alert
is obvious or the printer can help the untrained person
fix the problem. A typical example of such an alert is
reloading paper trays or emptying output bins on a low
end printer.
Management - Alerts that have to do with overall operation
of and configuration of the printer. Examples of such
management events are configuration change of subunits."
SYNTAX INTEGER {
other(1),
unknown(2),
untrained(3),
trained(4),
fieldService(5),
management(6),
noInterventionRequired(7) -- Not in RFC 1759
}
PrtAlertGroupTC ::= TEXTUAL-CONVENTION
-- Values in the range 1 to 29 must not be IANA-assigned without
-- re-publishing Printer MIB.
-- Values of 30 and greater are for use in MIBs that augment
-- the Printer MIB, such as the Finisher MIB.
-- This TC extracted from prtAlertGroup in RFC 1759.
STATUS current
DESCRIPTION
"The type of subunit within the printer model that this alert
is related. Input, output, and markers are examples of
printer model groups, i.e., examples of types of subunits.
Wherever possible, the enumerations match the sub-identifier
that identifies the relevant table in the Printer MIB.
NOTE: Alert type codes have been added for the Host Resources
MIB storage table and device table. These additional types
are for situations in which the printer's storage and device
objects must generate alerts (and possibly traps for critical
alerts)."
SYNTAX INTEGER {
other(1),
-- (2) is reserved for conformance information
-- Values for Host Resources MIB
hostResourcesMIBStorageTable(3),
hostResourcesMIBDeviceTable(4),
-- Values for Printer MIB
generalPrinter(5),
cover(6),
localization(7),
input(8),
output(9),
marker(10),
markerSupplies(11),
markerColorant(12),
mediaPath(13),
channel(14),
interpreter(15),
consoleDisplayBuffer(16),
consoleLights(17),
alert(18), -- Not in RFC 1759
-- Values (5) to (29) reserved for Printer MIB
-- Values for Finisher MIB
finDevice(30), -- Not in RFC 1759
finSupply(31), -- Not in RFC 1759
finSupplyMediaInput(32), -- Not in RFC 1759
finAttribute(33) -- Not in RFC 1759
-- Values (30) to (39) reserved for Finisher MIB
}
PrtAlertCodeTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtAlertCode in RFC 1759.
STATUS current
DESCRIPTION
"The code that describes the type of alert for this entry in
the table. Binary change event alerts describe states of the
subunit while unary change event alerts describe a single
event. The same alert code can be used for a binary change
event or a unary change event, depending on implementation.
Also, the same alert code can be used to indicate a critical
or non-critical (warning) alert, depending on implementation.
The value of prtAlertSeverityLevel specifies binary vs. unary
and critical vs. non-critical for each event for the
implementation.
While there are some specific codes for many subunits, the
generic codes should be used for most subunit alerts. The
network management station can then query the subunit
specified by prtAlertGroup to determine further subunit
status and other subunit information.
An agent shall not add two entries to the alert table for the
same event, one containing a generic event code and the other
containing a specific event code; the agent shall add only
one entry in the alert table for each event; either generic
(preferred) or specific, not both.
Implementation of the unary change event
alertRemovalOfBinaryChangeEntry(1801) is optional. When
implemented, this alert code shall indicate to network
management stations that the trailing edge of a binary change
event has occurred and the corresponding alert entry has been
removed from the alert table. As with all events, the
alertRemovalOfBinaryChangeEntry(1801) alert shall be placed
at the end of the alert table. Such an alert table entry
shall specify the following information:
prtAlertSeverityLevel warningUnaryChangeEvent(4)
prtAlertTrainingLevel noInterventionRequired(7)
prtAlertGroup alert(18)
prtAlertGroupIndex the index of the row in the
alert table of the binary
change event that this event
has removed.
prtAlertLocation unknown (-2)
prtAlertCode alertRemovalOfBinaryChangeEntry(1801)
prtAlertDescription <description or null string>
prtAlertTime the value of sysUpTime at
the time of the removal of the
binary change event from the
alert table.
Optionally, the agent may generate a trap coincident with
removing the binary change event and placing the unary change
event alertRemovalOfBinaryChangeEntry(1801) in the alert
table. For such a trap, the prtAlertIndex sent with the above
trap parameters shall be the index of the
alertRemovalOfBinaryChangeEvent row that was added to the
prtAlertTable; not the index of the row that was removed from
the prtAlertTable."
SYNTAX INTEGER {
other(1),
-- an event that is not represented
-- by one of the alert codes
-- specified below.
unknown(2),
-- The following generic codes are common to
-- multiple groups. The NMS may examine the
-- prtAlertGroup object to determine what group
-- to query for further information.
coverOpen(3),
coverClosed(4),
interlockOpen(5),
interlockClosed(6),
configurationChange(7),
jam(8),
subunitMissing(9), -- Not in RFC 1759
-- The subunit tray, bin, etc.
-- has been removed.
subunitLifeAlmostOver(10), -- Not in RFC 1759
subunitLifeOver(11), -- Not in RFC 1759
subunitAlmostEmpty(12), -- Not in RFC 1759
subunitEmpty(13), -- Not in RFC 1759
subunitAlmostFull(14), -- Not in RFC 1759
subunitFull(15), -- Not in RFC 1759
subunitNearLimit(16), -- Not in RFC 1759
subunitAtLimit(17), -- Not in RFC 1759
subunitOpened(18), -- Not in RFC 1759
subunitClosed(19), -- Not in RFC 1759
subunitTurnedOn(20), -- Not in RFC 1759
subunitTurnedOff(21), -- Not in RFC 1759
subunitOffline(22), -- Not in RFC 1759
subunitPowerSaver(23), -- Not in RFC 1759
subunitWarmingUp(24), -- Not in RFC 1759
subunitAdded(25), -- Not in RFC 1759
subunitRemoved(26), -- Not in RFC 1759
subunitResourceAdded(27), -- Not in RFC 1759
subunitResourceRemoved(28), -- Not in RFC 1759
subunitRecoverableFailure(29),
-- Not in RFC 1759
subunitUnrecoverableFailure(30),
-- Not in RFC 1759
subunitRecoverableStorageError(31),
-- Not in RFC 1759
subunitUnrecoverableStorageError(32),
-- Not in RFC 1759
subunitMotorFailure(33), -- Not in RFC 1759
subunitMemoryExhausted(34), -- Not in RFC 1759
subunitUnderTemperature(35), -- Not in RFC 1759
subunitOverTemperature(36), -- Not in RFC 1759
subunitTimingFailure(37), -- Not in RFC 1759
subunitThermistorFailure(38), -- Not in RFC 1759
-- General Printer group
doorOpen(501), -- DEPRECATED
-- Use coverOpened(3)
doorClosed(502), -- DEPRECATED
-- Use coverClosed(4)
powerUp(503),
powerDown(504),
printerNMSReset(505), -- Not in RFC 1759
-- The printer has been reset by some
-- network management station(NMS)
-- writing into 'prtGeneralReset'.
printerManualReset(506), -- Not in RFC 1759
-- The printer has been reset manually.
printerReadyToPrint(507), -- Not in RFC 1759
-- The printer is ready to print. (i.e.,
-- not warming up, not in power save
-- state, not adjusting print quality,
-- etc.).
-- Input Group
inputMediaTrayMissing(801),
inputMediaSizeChange(802),
inputMediaWeightChange(803),
inputMediaTypeChange(804),
inputMediaColorChange(805),
inputMediaFormPartsChange(806),
inputMediaSupplyLow(807),
inputMediaSupplyEmpty(808),
inputMediaChangeRequest(809), -- Not in RFC 1759
-- An interpreter has detected that a
-- different medium is need in this input
-- tray subunit. The prtAlertDescription may
-- be used to convey a human readable
-- description of the medium required to
-- satisfy the request.
inputManualInputRequest(810), -- Not in RFC 1759
-- An interpreter has detected that manual
-- input is required in this subunit. The
-- prtAlertDescription may be used to convey
-- a human readable description of the medium
-- required to satisfy the request.
inputTrayPositionFailure(811), -- Not in RFC 1759
-- The input tray failed to position correctly.
inputTrayElevationFailure(812),
-- Not in