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.
Bergman, et al. Standards Track [Page 1]

RFC 3805 Printer MIB v2 June 20041. Introduction1.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.
Bergman, et al. Standards Track [Page 4]

RFC 3805 Printer MIB v2 June 20041.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
Bergman, et al. Standards Track [Page 6]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 7]

RFC 3805 Printer MIB v2 June 20042. 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.
Bergman, et al. Standards Track [Page 8]

RFC 3805 Printer MIB v2 June 20042.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
Bergman, et al. Standards Track [Page 10]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 11]

RFC 3805 Printer MIB v2 June 20042.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
Bergman, et al. Standards Track [Page 12]

RFC 3805 Printer MIB v2 June 2004
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
Bergman, et al. Standards Track [Page 13]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 14]

RFC 3805 Printer MIB v2 June 20042.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.
Bergman, et al. Standards Track [Page 15]

RFC 3805 Printer MIB v2 June 20042.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.
Bergman, et al. Standards Track [Page 16]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 17]

RFC 3805 Printer MIB v2 June 2004
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
Bergman, et al. Standards Track [Page 18]

RFC 3805 Printer MIB v2 June 2004
"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
Bergman, et al. Standards Track [Page 19]

RFC 3805 Printer MIB v2 June 2004
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
Bergman, et al. Standards Track [Page 20]

RFC 3805 Printer MIB v2 June 2004
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
Bergman, et al. Standards Track [Page 21]

RFC 3805 Printer MIB v2 June 2004
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,
Bergman, et al. Standards Track [Page 22]

RFC 3805 Printer MIB v2 June 2004
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
Bergman, et al. Standards Track [Page 23]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 24]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 25]

RFC 3805 Printer MIB v2 June 20043.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 section1.
- 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 (RFC2790).
- Remove fixed association of hrDeviceStatus (warning/down) from
hrPrinterDetetctedErrorState per RFC 2790.
- Instead of showing bit 15 as "not assigned" in the quote from RFC2790 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.
Bergman, et al. Standards Track [Page 26]

RFC 3805 Printer MIB v2 June 2004
- 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.
Bergman, et al. Standards Track [Page 28]

RFC 3805 Printer MIB v2 June 2004
--
-- 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
Bergman, et al. Standards Track [Page 33]

RFC 3805 Printer MIB v2 June 2004
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.
Bergman, et al. Standards Track [Page 50]

RFC 3805 Printer MIB v2 June 2004
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
Bergman, et al. Standards Track [Page 52]

RFC 3805 Printer MIB v2 June 2004
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),
Bergman, et al. Standards Track [Page 53]

RFC 3805 Printer MIB v2 June 2004
-- 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 1759Bergman, et al. Standards Track [Page 54]

RFC 3805 Printer MIB v2 June 2004
CONTACT-INFO
"Harry Lewis
IBM
Phone (303) 924-5337
Email: harryl@us.ibm.com
http://www.pwg.org/index.html
Send comments to the printmib WG using the Printer MIB
Project (PMP) Mailing List: pmp@pwg.org
For further information, access the PWG web page under 'Printer
MIB': http://www.pwg.org/
Implementers of this specification are encouraged to join the
pmp mailing list in order to participate in discussions on any
clarifications needed and registration proposals being reviewed
in order to achieve consensus."
DESCRIPTION
"The MIB module for management of printers.
Copyright (C) The Internet Society (2004). This
version of this MIB module was published
in RFC 3805. For full legal notices see the RFC itself."
REVISION "200406020000Z"
DESCRIPTION
"Printer MIB v2.
Moved all enum groups to be maintained by IANA into new TCs
within the ianaPrinterMIB, which is contained in this
document.
New TCs created from enums defined within RFC 1759 Objects:
PrtPrintOrientationTC, PrtLocalizedDescriptionStringTC,
PrtConsoleDescriptionStringTC, PrtChannelStateTC,
PrtOutputStackingOrderTC, PrtOutputPageDeliveryOrientationTC,
PrtMarkerCounterUnitTC, PrtMarkerSuppliesSupplyUnitTC,
PrtMarkerSuppliesClassTC, PrtMarkerAddressabilityUnitTC,
PrtMarkerColorantRoleTC, PrtMediaPathMaxSpeedPrintUnitTC,
PrtInterpreterTwoWayTC, and PrtAlertSeverityLevelTC.
The following four TCs have been deprecated:
MediaUnit (replaced by PrtMediaUnitTC),
CapacityUnit (replaced by PrtCapacityUnitTC),
SubUnitStatus (replaced by PrtSubUnitStatusTC),
CodedCharSet (replaced by IANACharset in IANA Charset MIB)
Five new OBJECT-GROUPs: prtAuxilliarySheetGroup,
prtInputSwitchingGroup, prtGeneralV2Group,
prtAlertTableV2Group, prtChannelV2Group.
Nine new objects added to those groups:
prtAuxiliarySheetStartupPage, prtAuxiliarySheetBannerPage,
prtGeneralPrinterName, prtGeneralSerialNumber,
prtAlertCriticalEvents, prtAlertAllEvents,
Bergman, et al. Standards Track [Page 57]

RFC 3805 Printer MIB v2 June 2004
At intended state 0 0000'b
Transitioning to intended state 64 100 0000'b"
SYNTAX INTEGER (0..126)
PresentOnOff ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Presence and configuration of a device or feature."
SYNTAX INTEGER {
other(1),
on(3),
off(4),
notPresent(5)
}
PrtLocalizedDescriptionStringTC ::= TEXTUAL-CONVENTION
-- This TC did not appear in RFC 1759.
STATUS current
DESCRIPTION
"An object MUST use this TEXTUAL-CONVENTION when its
'charset' is controlled by the value of
prtGeneralCurrentLocalization."
SYNTAX OCTET STRING (SIZE(0..255))
PrtConsoleDescriptionStringTC ::= TEXTUAL-CONVENTION
-- This TC did not appear in RFC 1759.
STATUS current
DESCRIPTION
"An object MUST use this TEXTUAL-CONVENTION when its
'charset' is controlled by the value of
prtConsoleLocalization."
SYNTAX OCTET STRING (SIZE(0..255))
CodedCharSet ::= TEXTUAL-CONVENTION
-- Replaced by IANACharset TEXTUAL-CONVENTION in IANA Charset MIB.
STATUS deprecated
DESCRIPTION
"The original description clause from RFC 1759 [RFC1759] was
technically inaccurate and therefore has been deleted."
SYNTAX INTEGER {
other(1) -- used if the designated coded
-- character set is not currently in
-- the enumeration
}
--
Bergman, et al. Standards Track [Page 62]

RFC 3805 Printer MIB v2 June 2004
-- Channel Group TEXTUAL-CONVENTIONs
--
PrtChannelStateTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtChannelState in RFC 1759.
STATUS current
DESCRIPTION
"The state of this print job delivery channel. The value
determines whether print data is allowed through this channel."
SYNTAX INTEGER {
other(1),
printDataAccepted(3),
noDataAccepted(4)
}
--
-- Input/Output Group TEXTUAL-CONVENTIONs
--
PrtOutputStackingOrderTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtOutputStackingOrder in RFC 1759.
STATUS current
DESCRIPTION
"The current state of the stacking order for the associated
output sub-unit. 'firstToLast' means that as pages are output,
the front of the next page is placed against the back of the
previous page. 'lastToFirst' means that as pages are output,
the back of the next page is placed against the front of the
previous page."
SYNTAX INTEGER {
unknown(2),
firstToLast(3),
lastToFirst(4)
}
PrtOutputPageDeliveryOrientationTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtOutputPageDeliveryOrientation
-- in RFC 1759.
STATUS current
DESCRIPTION
"The reading surface that will be 'up' when pages are delivered
to the associated output sub-unit. Values are Face-Up and Face
Down (Note: interpretation of these values is, in general,
context-dependent based on locale; presentation of these values
to an end-user should be normalized to the expectations of the
user."
SYNTAX INTEGER {
faceUp(3),
Bergman, et al. Standards Track [Page 63]

RFC 3805 Printer MIB v2 June 2004
faceDown(4)
}
--
-- Marker Group TEXTUAL-CONVENTIONs
--
PrtMarkerCounterUnitTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtMarkerCounterUnit in RFC 1759.
STATUS current
DESCRIPTION
"The unit that will be used by the printer when reporting
counter values for this marking sub-unit. The
time units of measure are provided for a device like a
strip recorder that does not or cannot track the physical
dimensions of the media and does not use characters,
lines or sheets."
SYNTAX INTEGER {
tenThousandthsOfInches(3), -- .0001
micrometers(4),
characters(5),
lines(6),
impressions(7),
sheets(8),
dotRow(9),
hours(11),
feet(16),
meters(17)
}
PrtMarkerSuppliesSupplyUnitTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtMarkerSuppliesSupplyUnit
-- in RFC 1759.
STATUS current
DESCRIPTION
"Unit of this marker supply container/receptacle."
SYNTAX INTEGER {
other(1), -- New, not in RFC 1759
unknown(2), -- New, not in RFC 1759
tenThousandthsOfInches(3), -- .0001
micrometers(4),
impressions(7), -- New, not in RFC 1759
sheets(8), -- New, not in RFC 1759
hours(11), -- New, not in RFC 1759
thousandthsOfOunces(12),
tenthsOfGrams(13),
hundrethsOfFluidOunces(14),
Bergman, et al. Standards Track [Page 64]

RFC 3805 Printer MIB v2 June 2004
-- This TC was extracted from prtMediaPathMaxSpeedPrintUnit
-- in RFC 1759.
STATUS current
DESCRIPTION
"The unit of measure used in specifying the speed of all
media paths in the printer."
SYNTAX INTEGER {
tenThousandthsOfInchesPerHour(3),-- .0001/hour
micrometersPerHour(4),
charactersPerHour(5),
linesPerHour(6),
impressionsPerHour(7),
sheetsPerHour(8),
dotRowPerHour(9),
feetPerHour(16),
metersPerHour(17)
}
--
-- Interpreter Group TEXTUAL-CONVENTIONs
--
PrtInterpreterTwoWayTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtInterpreterTwoWay in RFC 1759.
STATUS current
DESCRIPTION
"Indicates whether or not this interpreter returns information
back to the host."
SYNTAX INTEGER {
yes(3),
no(4)
}
--
-- Alert Group TEXTUAL-CONVENTIONs
--
PrtAlertSeverityLevelTC ::= TEXTUAL-CONVENTION
-- This TC was extracted from prtAlertSeverityLevel in RFC 1759.
STATUS current
DESCRIPTION
"The level of severity of this alert table entry. The printer
determines the severity level assigned to each entry in the
table. A critical alert is binary by nature and definition. A
warning is defined to be a non-critical alert. The original and
most common warning is unary. The binary warning was added later
and given a more distinguished name."
SYNTAX INTEGER {
Bergman, et al. Standards Track [Page 66]

RFC 3805 Printer MIB v2 June 2004
other(1),
critical(3),
warning(4),
warningBinaryChangeEvent(5) -- New, not in RFC 1759
}
-- The General Printer Group
--
-- 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.
prtGeneral OBJECT IDENTIFIER ::= { printmib 5 }
prtGeneralTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtGeneralEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of general information per printer.
Objects in this table are defined in various
places in the MIB, nearby the groups to
which they apply. They are all defined
here to minimize the number of tables that would
otherwise need to exist."
::= { prtGeneral 1 }
prtGeneralEntry OBJECT-TYPE
SYNTAX PrtGeneralEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry exists in this table for each device entry in the
host resources MIB device table with a device type of
'printer'.
NOTE: The above description has been modified from RFC 1759
for clarification."
INDEX { hrDeviceIndex }
::= { prtGeneralTable 1 }
PrtGeneralEntry ::= SEQUENCE {
-- Note that not all of the objects in this sequence are in
-- the general printer group. The group to which an
-- object belongs is tagged with a label "General", "Input"
-- "Output", etc. after each entry in the following sequence.
--
prtGeneralConfigChanges Counter32, -- General
Bergman, et al. Standards Track [Page 67]

RFC 3805 Printer MIB v2 June 2004
prtGeneralCurrentLocalization Integer32, -- General
prtGeneralReset PrtGeneralResetTC,
-- General
prtGeneralCurrentOperator OCTET STRING,
-- Responsible Party
prtGeneralServicePerson OCTET STRING,
-- Responsible Party
prtInputDefaultIndex Integer32, -- Input
prtOutputDefaultIndex Integer32, -- Output
prtMarkerDefaultIndex Integer32, -- Marker
prtMediaPathDefaultIndex Integer32, -- Media Path
prtConsoleLocalization Integer32, -- Console
prtConsoleNumberOfDisplayLines Integer32, -- Console
prtConsoleNumberOfDisplayChars Integer32, -- Console
prtConsoleDisable PrtConsoleDisableTC,
-- Console,
prtAuxiliarySheetStartupPage PresentOnOff,
-- AuxiliarySheet
prtAuxiliarySheetBannerPage PresentOnOff,
-- AuxiliarySheet
prtGeneralPrinterName OCTET STRING,
-- General V2
prtGeneralSerialNumber OCTET STRING,
-- General V2
prtAlertCriticalEvents Counter32, -- Alert V2
prtAlertAllEvents Counter32 -- Alert V2
}
prtGeneralConfigChanges OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Counts configuration changes within the printer. A
configuration change is defined to be an action that results in
a change to any MIB object other than those that reflect status
or level, or those that act as counters or gauges. In addition,
any action that results in a row being added or deleted from
any table in the Printer MIB is considered a configuration
change. Such changes will often affect the capability of the
printer to service certain types of print jobs. Management
applications may cache infrequently changed configuration
information about sub units within the printer. This object
should be incremented whenever the agent wishes to notify
management applications that any cached configuration
information for this device is to be considered 'stale'. At
this point, the management application should flush any
configuration information cached about this device and fetch
Bergman, et al. Standards Track [Page 68]

RFC 3805 Printer MIB v2 June 2004
new configuration information.
The following are examples of actions that would cause the
prtGeneralConfigChanges object to be incremented:
- Adding an output bin
- Changing the media in a sensing input tray
- Changing the value of prtInputMediaType
Note that the prtGeneralConfigChanges counter would not be
incremented when an input tray is temporarily removed to load
additional paper or when the level of an input device changes.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtGeneralEntry 1 }
prtGeneralCurrentLocalization OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of the prtLocalizationIndex corresponding to the
current language, country, and character set to be used for
localized string values that are identified as being dependent
on the value of this object. Note that this object does not
apply to localized strings in the prtConsole group or to any
object that is not explicitly identified as being localized
according to prtGeneralCurrentLocalization. When an object's
'charset' is controlled by the value of
prtGeneralCurrentLocalization, it MUST specify
PrtLocalizedDescriptionStringTC as its syntax.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtGeneralEntry 2 }
prtGeneralReset OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly defined
-- by this object.
SYNTAX PrtGeneralResetTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this value to 'powerCycleReset', 'resetToNVRAM', or
'resetToFactoryDefaults' will result in the resetting of the
printer. When read, this object will always have the value
Bergman, et al. Standards Track [Page 69]

RFC 3805 Printer MIB v2 June 2004
'notResetting(3)', and a SET of the value 'notResetting' shall
have no effect on the printer. Some of the defined values are
optional. However, every implementation must support at least
the values 'notResetting' and 'resetToNVRAM'."
::= { prtGeneralEntry 3 }
-- The Responsible Party group
prtGeneralCurrentOperator OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the person who is responsible for operating
this printer. It is suggested that this string include
information that would enable other humans to reach the
operator, such as a phone number. As a convention to
facilitate automatic notification of the operator by the
agent or network management station, the phone number,
fax number or email address should be indicated by the
URL schemes 'tel:', 'fax:' and 'mailto:', respectively.
If either the phone, fax, or email information is not
available, then a line should not be included for this
information.
NOTE: For interoperability purposes, it is advisable to
use email addresses formatted according to [RFC2822]
requirements.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtGeneralEntry 4 }
prtGeneralServicePerson OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the person responsible for servicing this
printer. It is suggested that this string include
information that would enable other humans to reach the
service person, such as a phone number. As a convention
to facilitate automatic notification of the operator by
the agent or network management station, the phone
number, fax number or email address should be indicated
by the URL schemes 'tel:', 'fax:' and 'mailto:',
respectively. If either the phone, fax, or email
information is not available, then a line should not
Bergman, et al. Standards Track [Page 70]

RFC 3805 Printer MIB v2 June 2004
be included for this information.
NOTE: For interoperability purposes, it is advisable to use
email addresses formatted per [RFC2822] requirements.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtGeneralEntry 5 }
-- Default indexes section
--
-- The following four objects are used to specify the indexes of
-- certain subunits used as defaults during the printing process.
prtInputDefaultIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtInputIndex corresponding to the default input
sub-unit: that is, this object selects the default source of
input media."
::= { prtGeneralEntry 6 }
prtOutputDefaultIndex OBJECT-TYPE
-- A range has been added to the SYNTAX clause that was not in
-- RFC 1759. Although this violates SNMP compatibility rules,
-- it provides a more reasonable guide for SNMP managers.
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtOutputIndex corresponding to the default
output sub-unit; that is, this object selects the default
output destination."
::= { prtGeneralEntry 7 }
prtMarkerDefaultIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtMarkerIndex corresponding to the
default marker sub-unit; that is, this object selects the
default marker."
::= { prtGeneralEntry 8 }
Bergman, et al. Standards Track [Page 71]

RFC 3805 Printer MIB v2 June 2004
prtMediaPathDefaultIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtMediaPathIndex corresponding to
the default media path; that is, the selection of the
default media path."
::= { prtGeneralEntry 9 }
-- Console general section
--
-- The following four objects describe overall parameters of the
-- printer console subsystem.
prtConsoleLocalization OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of the prtLocalizationIndex corresponding to
the language, country, and character set to be used for the
console. This localization applies both to the actual display
on the console as well as the encoding of these console objects
in management operations. When an object's 'charset' is
controlled by the value of prtConsoleLocalization, it MUST
specify PrtConsoleDescriptionStringTC as its syntax.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtGeneralEntry 10 }
prtConsoleNumberOfDisplayLines OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of lines on the printer's physical
display. This value is 0 if there are no lines on the
physical display or if there is no physical display"
::= { prtGeneralEntry 11 }
prtConsoleNumberOfDisplayChars OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of characters per line displayed on the physical
Bergman, et al. Standards Track [Page 72]

RFC 3805 Printer MIB v2 June 2004
display. This value is 0 if there are no lines on the physical
display or if there is no physical display"
::= { prtGeneralEntry 12 }
prtConsoleDisable OBJECT-TYPE
-- In RFC 1759, the enumeration values were implicitly defined
-- by this object.
SYNTAX PrtConsoleDisableTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This value indicates how input is (or is not) accepted from
the operator console.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtGeneralEntry 13 }
-- The Auxiliary Sheet Group
--
-- The auxiliary sheet group allows the administrator to control
-- the production of auxiliary sheets by the printer. This group
-- contains only the "prtAuxiliarySheetStartupPage" and
-- "prtAuxiliarySheetBannerPage" objects.
prtAuxiliarySheetStartupPage OBJECT-TYPE
SYNTAX PresentOnOff
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Used to enable or disable printing a startup page. If enabled,
a startup page will be printed shortly after power-up, when the
device is ready. Typical startup pages include test patterns
and/or printer configuration information."
::= { prtGeneralEntry 14 }
prtAuxiliarySheetBannerPage OBJECT-TYPE
SYNTAX PresentOnOff
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Used to enable or disable printing banner pages at the
beginning of jobs. This is a master switch which applies to all
jobs, regardless of interpreter."
::= { prtGeneralEntry 15 }
Bergman, et al. Standards Track [Page 73]

RFC 3805 Printer MIB v2 June 2004
-- Administrative section (The General V2 Group)
--
-- The following two objects are used to specify administrative
-- information assigned to the printer.
prtGeneralPrinterName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..127))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An administrator-specified name for this printer. Depending
upon implementation of this printer, the value of this object
may or may not be same as the value for the MIB-II 'SysName'
object."
::= { prtGeneralEntry 16 }
prtGeneralSerialNumber OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A recorded serial number for this device that indexes some
type device catalog or inventory. This value is usually set by
the device manufacturer but the MIB supports the option of
writing for this object for site-specific administration of
device inventory or tracking."
::= { prtGeneralEntry 17 }
-- General alert table section (Alert Table V2 Group)
--
-- The following two objects are used to specify counters
-- associated with the Alert Table.
prtAlertCriticalEvents OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A running counter of the number of critical alert events that
have been recorded in the alert table. The value of this object
is RESET in the event of a power cycle operation (i.e., the
value is not persistent."
::= { prtGeneralEntry 18 }
prtAlertAllEvents OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
Bergman, et al. Standards Track [Page 74]

RFC 3805 Printer MIB v2 June 2004
unit. Although these values may change due to a major
reconfiguration of the device (e.g., the addition of new cover
sub-units to the printer), values SHOULD remain stable across
successive printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtCoverEntry 1 }
prtCoverDescription OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtLocalizedDescriptionStringTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The manufacturer provided cover sub-mechanism name in the
localization specified by prtGeneralCurrentLocalization."
::= { prtCoverEntry 2 }
prtCoverStatus OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly defined
-- by this object and are now defined in the IANA-PRINTER-MIB. The
-- new TC has defined "coverOpen" and "coverClosed" to replace
-- "doorOpen" and "doorClosed" in RFC 1759. A name change is not
-- formally allowed per SMI rules, but was agreed to by the WG group
-- since a door has a more restrictive meaning than a cover and
-- Cover group is intended to support doors as a subset of covers.
SYNTAX PrtCoverStatusTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of this cover sub-unit."
::= { prtCoverEntry 3 }
-- The Localization Table
--
-- The localization portion of the General printer sub-unit is
-- responsible for identifying the natural language, country, and
-- character set in which character strings are expressed. There
-- may be one or more localizations supported per printer. The
-- available localizations are represented by the Localization
-- table.
prtLocalization OBJECT IDENTIFIER ::= { printmib 7 }
prtLocalizationTable OBJECT-TYPE
Bergman, et al. Standards Track [Page 76]

RFC 3805 Printer MIB v2 June 2004
"This table will have an entry for each entry in the Host
Resources MIB storage table that represents storage associated
with a printer managed by this agent.
NOTE: The above description has been modified from RFC 1759
for clarification."
INDEX { hrStorageIndex, prtStorageRefSeqNumber }
::= { prtStorageRefTable 1 }
PrtStorageRefEntry ::= SEQUENCE {
prtStorageRefSeqNumber Integer32,
prtStorageRefIndex Integer32
}
prtStorageRefSeqNumber OBJECT-TYPE
-- NOTE: The range has been changed from RFC 1759, which allowed a
-- minumum value of zero. This was incorrect, since zero is not a
-- valid index.
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This value will be unique amongst all entries with a common
value of hrStorageIndex. This object allows a storage entry to
point to the multiple printer devices with which it is
associated."
::= { prtStorageRefEntry 1 }
prtStorageRefIndex OBJECT-TYPE
-- NOTE: The range has been changed from RFC 1759 to be compatible
-- with the defined range of hrDeviceIndex.
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the hrDeviceIndex of the printer device that this
storageEntry is associated with."
::= { prtStorageRefEntry 2 }
prtDeviceRefTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtDeviceRefEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table defines which printer, amongst multiple printers
serviced by one agent, is associated with which devices.
NOTE: The above description has been modified from RFC 1759Bergman, et al. Standards Track [Page 79]

RFC 3805 Printer MIB v2 June 2004
for clarification."
::= { prtGeneral 3 }
prtDeviceRefEntry OBJECT-TYPE
SYNTAX PrtDeviceRefEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table will have an entry for each entry in the Host
Resources MIB device table that represents a device associated
with a printer managed by this agent.
NOTE: The above description has been modified from RFC 1759
for clarification."
INDEX { hrDeviceIndex, prtDeviceRefSeqNumber }
::= { prtDeviceRefTable 1 }
PrtDeviceRefEntry ::= SEQUENCE {
prtDeviceRefSeqNumber Integer32,
prtDeviceRefIndex Integer32
}
prtDeviceRefSeqNumber OBJECT-TYPE
-- NOTE: The range has been changed from RFC 1759, which allowed a
-- minumum value of zero. This was incorrect, since zero is not a
-- valid index.
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This value will be unique amongst all entries with a common
value of hrDeviceIndex. This object allows a device entry to
point to the multiple printer devices with which it is
associated."
::= { prtDeviceRefEntry 1 }
prtDeviceRefIndex OBJECT-TYPE
-- NOTE: The range has been changed from RFC 1759 to be compatible
-- with the defined range of hrDeviceIndex.
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the hrDeviceIndex of the printer device that this
deviceEntry is associated with."
::= { prtDeviceRefEntry 2 }
Bergman, et al. Standards Track [Page 80]

RFC 3805 Printer MIB v2 June 2004
"The unit of measurement for use calculating and relaying
dimensional values for this input sub-unit."
::= { prtInputEntry 3 }
prtInputMediaDimFeedDirDeclared OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object provides the value of the declared dimension, in
the feed direction, of the media that is (or, if empty, was or
will be) in this input sub-unit. The feed direction is the
direction in which the media is fed on this sub-unit. This
dimension is measured in input sub-unit dimensional units
(controlled by prtInputDimUnit, which uses PrtMediaUnitTC). If
this input sub-unit can reliably sense this value, the value is
sensed by the printer and may not be changed by management
requests. Otherwise, the value may be changed. The value (-1)
means other and specifically means that this sub-unit places no
restriction on this parameter. The value (-2) indicates
unknown."
::= { prtInputEntry 4 }
prtInputMediaDimXFeedDirDeclared OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object provides the value of the declared dimension, in
the cross feed direction, of the media that is (or, if empty,
was or will be) in this input sub-unit. The cross feed
direction is ninety degrees relative to the feed direction
associated with this sub-unit. This dimension is measured in
input sub-unit dimensional units (controlled by
prtInputDimUnit,which uses PrtMediaUnitTC). If this input sub-
unit can reliably sense this value, the value is sensed by the
printer and may not be changed by management requests.
Otherwise, the value may be changed. The value (-1) means other
and specifically means that this sub-unit places no restriction
on this parameter. The value (-2) indicates unknown."
::= { prtInputEntry 5 }
prtInputMediaDimFeedDirChosen OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
Bergman, et al. Standards Track [Page 83]

RFC 3805 Printer MIB v2 June 2004
STATUS current
DESCRIPTION
"The printer will act as if media of the chosen dimension (in
the feed direction) is present in this input source. Note that
this value will be used even if the input tray is empty. Feed
dimension measurements are taken relative to the feed direction
associated with that sub-unit and are in input sub-unit
dimensional units (controlled by prtInputDimUnit, which uses
PrtMediaUnitTC). If the printer supports the declared
dimension,the granted dimension is the same as the declared
dimension. If not, the granted dimension is set to the closest
dimension that the printer supports when the declared dimension
is set. The value (-1) means other and specifically indicates
that this sub-unit places no restriction on this parameter. The
value (-2)indicates unknown."
::= { prtInputEntry 6 }
prtInputMediaDimXFeedDirChosen OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The printer will act as if media of the chosen dimension (in
the cross feed direction) is present in this input source. Note
that this value will be used even if the input tray is empty.
The cross feed direction is ninety degrees relative to the feed
direction associated with this sub-unit. This dimension is
measured in input sub-unit dimensional units (controlled by
prtInputDimUnit, which uses PrtMediaUnitTC). If the printer
supports the declare dimension, the granted dimension is the
same as the declared dimension. If not, the granted dimension
is set to the closest dimension that the printer supports when
the declared dimension is set. The value (-1) means other and
specifically indicates that this sub-unit places no restriction
on this parameter. The value (-2) indicates unknown."
::= { prtInputEntry 7 }
prtInputCapacityUnit OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtCapacityUnitTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The unit of measurement for use in calculating and relaying
capacity values for this input sub-unit."
::= { prtInputEntry 8 }
Bergman, et al. Standards Track [Page 84]

RFC 3805 Printer MIB v2 June 2004
prtInputMaxCapacity OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum capacity of the input sub-unit in input sub-unit
capacity units (PrtCapacityUnitTC). There is no convention
associated with the media itself so this value reflects claimed
capacity. If this input sub-unit can reliably sense this value,
the value is sensed by the printer and may not be changed by
management requests; otherwise, the value may be written (by a
Remote Control Panel or a Management Application). The value
(-1) means other and specifically indicates that the sub-unit
places no restrictions on this parameter. The value (-2) means
unknown."
::= { prtInputEntry 9 }
prtInputCurrentLevel OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-3..2147483647) -- in capacity units
-- (PrtCapacityUnitTC).
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current capacity of the input sub-unit in input sub-unit
capacity units (PrtCapacityUnitTC). If this input sub-unit can
reliably sense this value, the value is sensed by the printer
and may not be changed by management requests; otherwise, the
value may be written (by a Remote Control Panel or a Management
Application). The value (-1) means other and specifically
indicates that the sub-unit places no restrictions on this
parameter. The value (-2) means unknown. The value (-3) means
that the printer knows that at least one unit remains."
::= { prtInputEntry 10 }
prtInputStatus OBJECT-TYPE
SYNTAX PrtSubUnitStatusTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current status of this input sub-unit."
::= { prtInputEntry 11 }
prtInputMediaName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..63))
MAX-ACCESS read-write
STATUS current
Bergman, et al. Standards Track [Page 85]

RFC 3805 Printer MIB v2 June 2004
-- Medium resources are identified by name, and include a
-- collection of characteristic attributes that may further be
-- used for selection and management of them.
-- The Input Media group consists of a set of optional
-- "columns" in the Input Table. In this manner, a minimally
-- conforming implementation may choose to not support reporting
-- of media resources if it cannot do so.
prtInputMediaWeight OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The weight of the medium associated with this input sub-unit
in grams / per meter squared. The value (-2) means unknown."
::= { prtInputEntry 20 }
prtInputMediaType OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..63))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the type of medium associated with this input sub
unit. This name need not be processed by the printer; it might
simply be displayed to an operator.
NOTE: The above description has been modified from RFC 1759."
-- The following reference was not included in RFC 1759.
REFERENCE
"The PWG Standardized Media Names specification [PWGMEDIA],
section 3 Media Type Names, contains the recommended values for
this object. Implementers may add additional string values.
The naming conventions in ISO 9070 are recommended in order to
avoid potential name clashes."
::= { prtInputEntry 21 }
prtInputMediaColor OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..63))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the color of the medium associated with
this input sub-unit using standardized string values.
NOTE: The above description has been modified from RFC 1759."
-- The following reference was not included in RFC 1759.
REFERENCE
Bergman, et al. Standards Track [Page 88]

RFC 3805 Printer MIB v2 June 2004
"The PWG Standardized Media Names specification [PWGMEDIA],
section 4 Media Color Names, contains the recommended values
for this object. Implementers may add additional string values.
The naming conventions in ISO 9070 are recommended in order to
avoid potential name clashes."
::= { prtInputEntry 22 }
prtInputMediaFormParts OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The number of parts associated with the medium
associated with this input sub-unit if the medium is a
multi-part form. The value (-1) means other and
specifically indicates that the device places no
restrictions on this parameter. The value (-2) means
unknown."
::= { prtInputEntry 23 }
-- The Input Switching Group
--
-- The input switching group allows the administrator to set the
-- input subunit time-out for the printer and to control the
-- automatic input subunit switching by the printer when an input
-- subunit becomes empty.
prtInputMediaLoadTimeout OBJECT-TYPE
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When the printer is not able to print due to a subunit being
empty or the requested media must be manually loaded, the
printer will wait for the duration (in seconds) specified by
this object. Upon expiration of the time-out, the printer will
take the action specified by prtInputNextIndex.
The event which causes the printer to enter the waiting state
is product specific. If the printer is not waiting for manually
fed media, it may switch from an empty subunit to a different
subunit without waiting for the time-out to expire.
A value of (-1) implies 'other' or 'infinite' which translates
to 'wait forever'. The action which causes printing to continue
is product specific. A value of (-2) implies 'unknown'."
::= { prtInputEntry 24 }
Bergman, et al. Standards Track [Page 89]

RFC 3805 Printer MIB v2 June 2004
prtInputNextIndex OBJECT-TYPE
SYNTAX Integer32 (-3..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtInputIndex corresponding to the input subunit
which will be used when this input subunit is emptied and the
time-out specified by prtInputMediaLoadTimeout expires. A value
of zero(0) indicates that auto input switching will not occur
when this input subunit is emptied. If the time-out specified
by prtInputLoadMediaTimeout expires and this value is zero(0),
the job will be aborted. A value of (-1) means other. The
value (-2)means 'unknown' and specifically indicates that an
implementation specific method will determine the next input
subunit to use at the time this subunit is emptied and the time
out expires. The value(-3) means input switching is not
supported for this subunit."
::= { prtInputEntry 25 }
-- The Output Group
--
-- Output sub-units are managed as a tabular, indexed collection
-- of possible devices capable of receiving media delivered from
-- the printing process. Output sub-units typically have a
-- location, a type, an identifier, a set of constraints on
-- possible media sizes and potentially other characteristics,
-- and may be capable of indicating current status or capacity.
prtOutput OBJECT IDENTIFIER ::= { printmib 9 }
prtOutputTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtOutputEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of the devices capable of receiving media delivered
from the printing process."
::= { prtOutput 2 }
prtOutputEntry OBJECT-TYPE
SYNTAX PrtOutputEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Attributes of a device capable of receiving media delivered
from the printing process. Entries may exist in the table for
each device index with a device type of 'printer'.
Bergman, et al. Standards Track [Page 90]

RFC 3805 Printer MIB v2 June 2004
prtOutputType OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly defined
-- by this object.
SYNTAX PrtOutputTypeTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of technology supported by this output sub-unit."
::= { prtOutputEntry 2 }
prtOutputCapacityUnit OBJECT-TYPE
SYNTAX PrtCapacityUnitTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The unit of measurement for use in calculating and relaying
capacity values for this output sub-unit."
::= { prtOutputEntry 3 }
prtOutputMaxCapacity OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum capacity of this output sub-unit in output sub-
unit capacity units (PrtCapacityUnitTC). There is no convention
associated with the media itself so this value essentially
reflects claimed capacity. If this output sub-unit can reliably
sense this value, the value is sensed by the printer and may
not be changed by management requests; otherwise, the value may
be written (by a Remote Control Panel or a Management
Application). The value (-1) means other and specifically
indicates that the sub-unit places no restrictions on this
parameter. The value (-2) means unknown."
::= { prtOutputEntry 4 }
prtOutputRemainingCapacity OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-3..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The remaining capacity of the possible output sub-unit
capacity in output sub-unit capacity units
(PrtCapacityUnitTC)of this output sub-unit. If this output sub-
unit can reliably sense this value, the value is sensed by the
printer and may not be modified by management requests;
Bergman, et al. Standards Track [Page 92]

RFC 3805 Printer MIB v2 June 2004
-- The Output Dimensions Group
prtOutputDimUnit OBJECT-TYPE
SYNTAX PrtMediaUnitTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The unit of measurement for use in calculating and relaying
dimensional values for this output sub-unit."
::= { prtOutputEntry 14 }
prtOutputMaxDimFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum dimensions supported by this output sub-unit
for measurements taken parallel relative to the feed
direction associated with that sub-unit in output
sub-unit dimensional units (controlled by prtOutputDimUnit,
which uses PrtMediaUnitTC). If this output sub-unit can
reliably sense this value, the value is sensed by the printer
and may not be changed with management protocol operations.
The value (-1) means other and specifically indicates that the
sub-unit places no restrictions on this parameter. The value
(-2) means unknown.
NOTE: The above description has been modified from RFC 1759
for clarification and to explain the purpose of (-1) and (-2)."
::= { prtOutputEntry 15 }
prtOutputMaxDimXFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum dimensions supported by this output sub-unit
for measurements taken ninety degrees relative to the
feed direction associated with that sub-unit in output
sub-unit dimensional units (controlled by prtOutputDimUnit,
which uses PrtMediaUnitTC). If this output sub-unit can
reliably sense this value, the value is sensed by the printer
and may not be changed with management protocol operations.
The value (-1) means other and specifically indicates that the
sub-unit places no restrictions on this parameter. The value
(-2) means unknown.
Bergman, et al. Standards Track [Page 95]

RFC 3805 Printer MIB v2 June 2004
NOTE: The above description has been modified from RFC 1759
for clarification and to explain the purpose of (-1) and (-2)."
::= { prtOutputEntry 16 }
prtOutputMinDimFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The minimum dimensions supported by this output sub-unit
for measurements taken parallel relative to the feed
direction associated with that sub-unit in output
sub-unit dimensional units (controlled by prtOutputDimUnit,
which uses PrtMediaUnitTC). If this output sub-unit can
reliably sense this value, the value is sensed by the printer
and may not be changed with management protocol operations.
The value (-1) means other and specifically indicates that the
sub-unit places no restrictions on this parameter. The value
(-2) means unknown.
NOTE: The above description has been modified from RFC 1759
for clarification and to explain the purpose of (-1) and (-2)."
::= { prtOutputEntry 17 }
prtOutputMinDimXFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The minimum dimensions supported by this output sub-unit
for measurements taken ninety degrees relative to the
feed direction associated with that sub-unit in output
sub-unit dimensional units (controlled by prtOutputDimUnit,
which uses PrtMediaUnitTC). If this output sub-unit can
reliably sense this value, the value is sensed by the printer
and may not be changed with management protocol operations.
The value (-1) means other and specifically indicates that the
sub-unit places no restrictions on this parameter. The value
(-2) means unknown.
NOTE: The above description has been modified from RFC 1759
for clarification and to explain the purpose of (-1) and (-2)."
::= { prtOutputEntry 18 }
Bergman, et al. Standards Track [Page 96]

RFC 3805 Printer MIB v2 June 2004
-- The Output Features Group
prtOutputStackingOrder OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtOutputStackingOrderTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current state of the stacking order for the
associated output sub-unit. 'FirstToLast' means
that as pages are output the front of the next page is
placed against the back of the previous page.
'LasttoFirst' means that as pages are output the back
of the next page is placed against the front of the
previous page."
::= { prtOutputEntry 19 }
prtOutputPageDeliveryOrientation OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtOutputPageDeliveryOrientationTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The reading surface that will be 'up' when pages are
delivered to the associated output sub-unit. Values are
faceUp and faceDown. (Note: interpretation of these
values is in general context-dependent based on locale;
presentation of these values to an end-user should be
normalized to the expectations of the user)."
::= { prtOutputEntry 20 }
prtOutputBursting OBJECT-TYPE
SYNTAX PresentOnOff
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates that the outputting sub-unit supports
bursting, and if so, whether the feature is enabled. Bursting
is the process by which continuous media is separated into
individual sheets, typically by bursting along pre-formed
perforations."
::= { prtOutputEntry 21 }
prtOutputDecollating OBJECT-TYPE
SYNTAX PresentOnOff
MAX-ACCESS read-write
Bergman, et al. Standards Track [Page 97]

RFC 3805 Printer MIB v2 June 2004
STATUS current
DESCRIPTION
"This object indicates that the output supports decollating,
and if so, whether the feature is enabled. Decollating is the
process by which the individual parts within a multi-part form
are separated and sorted into separate stacks for each part."
::= { prtOutputEntry 22 }
prtOutputPageCollated OBJECT-TYPE
SYNTAX PresentOnOff
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates that the output sub-unit supports page
collation, and if so, whether the feature is enabled. See RFC3805Appendix A, Glossary Of Terms, for definition of how this
document defines collation.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtOutputEntry 23 }
prtOutputOffsetStacking OBJECT-TYPE
SYNTAX PresentOnOff
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates that the output supports offset
stacking,and if so, whether the feature is enabled. See RFC3805Appendix A, Glossary Of Terms, for how Offset Stacking is
defined by this document.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtOutputEntry 24 }
-- The Marker Group
--
-- A marker is the mechanism that produces marks on the print
-- media. The marker sub-units and their associated supplies are
-- represented by the Marker Group in the model. A printer can
-- contain one or more marking mechanisms. Some examples of
-- multiple marker sub-units are: a printer
-- with separate markers for normal and magnetic ink or an
-- imagesetter that can output to both a proofing device and
-- final film. Each marking device can have its own set of
-- characteristics associated with it, such as marking technology
-- and resolution.
Bergman, et al. Standards Track [Page 98]

RFC 3805 Printer MIB v2 June 2004
}
prtMarkerIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value used by the printer to identify this marking
SubUnit. Although these values may change due to a major
reconfiguration of the device (e.g., the addition of new marking
sub-units to the printer), values SHOULD remain stable across
successive printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerEntry 1 }
prtMarkerMarkTech OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerMarkTechTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of marking technology used for this marking
sub-unit."
::= { prtMarkerEntry 2 }
prtMarkerCounterUnit OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerCounterUnitTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The unit that will be used by the printer when reporting
counter values for this marking sub-unit. The time units of
measure are provided for a device like a strip recorder that
does not or cannot track the physical dimensions of the media
and does not use characters, lines or sheets."
::= { prtMarkerEntry 3 }
prtMarkerLifeCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the number of units of measure counted during the
Bergman, et al. Standards Track [Page 100]

RFC 3805 Printer MIB v2 June 2004
life of printer using units of measure as specified by
prtMarkerCounterUnit.
Note: This object should be implemented as a persistent object
with a reliable value throughout the lifetime of the printer."
::= { prtMarkerEntry 4 }
prtMarkerPowerOnCount OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the number of units of measure counted since the
equipment was most recently powered on using units of measure
as specified by prtMarkerCounterUnit."
::= { prtMarkerEntry 5 }
prtMarkerProcessColorants OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of process colors supported by this marker. A
process color of 1 implies monochrome. The value of this
object and prtMarkerSpotColorants cannot both be 0. The value
of prtMarkerProcessColorants must be 0 or greater.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerEntry 6 }
prtMarkerSpotColorants OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of spot colors supported by this marker. The value
of this object and prtMarkerProcessColorants cannot both be 0.
Must be 0 or greater.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerEntry 7 }
prtMarkerAddressabilityUnit OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerAddressabilityUnitTC
Bergman, et al. Standards Track [Page 101]

RFC 3805 Printer MIB v2 June 2004
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The unit of measure of distances, as applied to the marker's
resolution.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerEntry 8 }
prtMarkerAddressabilityFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of addressable marking positions in the
feed direction per 10000 units of measure specified by
prtMarkerAddressabilityUnit. A value of (-1) implies 'other'
or 'infinite' while a value of (-2) implies 'unknown'.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerEntry 9 }
prtMarkerAddressabilityXFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of addressable marking positions in the
cross feed direction in 10000 units of measure specified by
prtMarkerAddressabilityUnit. A value of (-1) implies 'other'
or 'infinite' while a value of (-2) implies 'unknown'.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerEntry 10 }
prtMarkerNorthMargin OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The margin, in units identified by prtMarkerAddressabilityUnit,
from the leading edge of the medium as the medium flows through
Bergman, et al. Standards Track [Page 102]

RFC 3805 Printer MIB v2 June 2004
the marking engine with the side to be imaged facing the
observer. The leading edge is the North edge and the other
edges are defined by the normal compass layout of directions
with the compass facing the observer. Printing within the area
bounded by all four margins is guaranteed for all interpreters.
The value (-2) means unknown."
::= { prtMarkerEntry 11 }
prtMarkerSouthMargin OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The margin from the South edge (see prtMarkerNorthMargin) of
the medium in units identified by prtMarkerAddressabilityUnit.
Printing within the area bounded by all four margins is
guaranteed for all interpreters. The value (-2) means unknown."
::= { prtMarkerEntry 12 }
prtMarkerWestMargin OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The margin from the West edge (see prtMarkerNorthMargin) of
the medium in units identified by prtMarkerAddressabilityUnit.
Printing within the area bounded by all four margins is
guaranteed for all interpreters. The value (-2) means unknown."
::= { prtMarkerEntry 13 }
prtMarkerEastMargin OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The margin from the East edge (see prtMarkerNorthMargin) of
the medium in units identified by prtMarkerAddressabilityUnit.
Printing within the area bounded by all four margins is
guaranteed for all interpreters. The value (-2) means unknown."
::= { prtMarkerEntry 14 }
prtMarkerStatus OBJECT-TYPE
SYNTAX PrtSubUnitStatusTC
MAX-ACCESS read-only
STATUS current
Bergman, et al. Standards Track [Page 103]

RFC 3805 Printer MIB v2 June 2004
supplies to the printer), values SHOULD remain stable across
successive printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerSuppliesEntry 1 }
prtMarkerSuppliesMarkerIndex OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of prtMarkerIndex corresponding to the marking sub
unit with which this marker supply sub-unit is associated."
::= { prtMarkerSuppliesEntry 2 }
prtMarkerSuppliesColorantIndex OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of prtMarkerColorantIndex corresponding to the
colorant with which this marker supply sub-unit is associated.
This value shall be 0 if there is no colorant table or if this
supply does not depend on a single specified colorant.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerSuppliesEntry 3 }
prtMarkerSuppliesClass OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerSuppliesClassTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether this supply entity represents a supply that
is consumed or a receptacle that is filled.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerSuppliesEntry 4 }
prtMarkerSuppliesType OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerSuppliesTypeTC
MAX-ACCESS read-only
Bergman, et al. Standards Track [Page 105]

RFC 3805 Printer MIB v2 June 2004
STATUS current
DESCRIPTION
"The type of this supply."
::= { prtMarkerSuppliesEntry 5 }
prtMarkerSuppliesDescription OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtLocalizedDescriptionStringTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The description of this supply container/receptacle in the
localization specified by prtGeneralCurrentLocalization."
::= { prtMarkerSuppliesEntry 6 }
prtMarkerSuppliesSupplyUnit OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerSuppliesSupplyUnitTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Unit of measure of this marker supply container/receptacle.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerSuppliesEntry 7 }
prtMarkerSuppliesMaxCapacity OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum capacity of this supply container/receptacle
expressed in prtMarkerSuppliesSupplyUnit. If this supply
container/receptacle can reliably sense this value, the value
is reported by the printer and is read-only; otherwise, the
value may be written (by a Remote Control Panel or a Management
Application). The value (-1) means other and specifically
indicates that the sub-unit places no restrictions on this
parameter. The value (-2) means unknown."
::= { prtMarkerSuppliesEntry 8 }
prtMarkerSuppliesLevel OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-3..2147483647)
Bergman, et al. Standards Track [Page 106]

RFC 3805 Printer MIB v2 June 2004
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current level if this supply is a container; the remaining
space if this supply is a receptacle. If this supply
container/receptacle can reliably sense this value, the value
is reported by the printer and is read-only; otherwise, the
value may be written (by a Remote Control Panel or a Management
Application). The value (-1) means other and specifically
indicates that the sub-unit places no restrictions on this
parameter. The value (-2) means unknown. A value of (-3) means
that the printer knows that there is some supply/remaining
space, respectively."
::= { prtMarkerSuppliesEntry 9 }
-- The Marker Colorant Group
prtMarkerColorant OBJECT IDENTIFIER ::= { printmib 12 }
prtMarkerColorantTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtMarkerColorantEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of all of the colorants available on the printer."
::= { prtMarkerColorant 1 }
prtMarkerColorantEntry OBJECT-TYPE
SYNTAX PrtMarkerColorantEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Attributes of a colorant available on the printer. Entries may
exist in the table for each device index with a device type of
'printer'.
NOTE: The above description has been modified from RFC 1759
for clarification."
INDEX { hrDeviceIndex, prtMarkerColorantIndex }
::= { prtMarkerColorantTable 1 }
PrtMarkerColorantEntry ::= SEQUENCE {
prtMarkerColorantIndex Integer32,
prtMarkerColorantMarkerIndex Integer32,
prtMarkerColorantRole PrtMarkerColorantRoleTC,
prtMarkerColorantValue OCTET STRING,
prtMarkerColorantTonality Integer32
}
Bergman, et al. Standards Track [Page 107]

RFC 3805 Printer MIB v2 June 2004
prtMarkerColorantIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value used by the printer to identify this colorant.
Although these values may change due to a major reconfiguration
of the device (e.g., the addition of new colorants to the
printer) , values SHOULD remain stable across successive
printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMarkerColorantEntry 1 }
prtMarkerColorantMarkerIndex OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of prtMarkerIndex corresponding to the marker sub
unit with which this colorant entry is associated."
::= { prtMarkerColorantEntry 2 }
prtMarkerColorantRole OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMarkerColorantRoleTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The role played by this colorant."
::= { prtMarkerColorantEntry 3 }
prtMarkerColorantValue OBJECT-TYPE
-- NOTE: The string length range has been increased from RFC 1759.
SYNTAX OCTET STRING (SIZE(0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the color of this colorant using standardized
string names from ISO 10175 (DPA) and ISO 10180 (SPDL) such as:
other
unknown
white
red
green
blue
Bergman, et al. Standards Track [Page 108]

RFC 3805 Printer MIB v2 June 2004
cyan
magenta
yellow
black
Implementers may add additional string values. The naming
conventions in ISO 9070 are recommended in order to avoid
potential name clashes"
::= { prtMarkerColorantEntry 4 }
prtMarkerColorantTonality OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The distinct levels of tonality realizable by a marking sub
unit when using this colorant. This value does not include the
number of levels of tonal difference that an interpreter can
obtain by techniques such as half toning. This value must be at
least 2."
::= { prtMarkerColorantEntry 5 }
-- The Media Path Group
--
-- The media paths encompass the mechanisms in the printer that
-- move the media through the printer and connect all other media
-- related sub-units: inputs, outputs, markers and finishers. A
-- printer contains one or more media paths. These are
-- represented by the Media Path Group in the model.
prtMediaPath OBJECT IDENTIFIER ::= { printmib 13 }
prtMediaPathTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtMediaPathEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The media path table includes both physical and logical paths
within the printer.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMediaPath 4 }
prtMediaPathEntry OBJECT-TYPE
SYNTAX PrtMediaPathEntry
MAX-ACCESS not-accessible
STATUS current
Bergman, et al. Standards Track [Page 109]

RFC 3805 Printer MIB v2 June 2004
"The unit of measure used in specifying the speed of all media
paths in the printer."
::= { prtMediaPathEntry 2 }
prtMediaPathMediaSizeUnit OBJECT-TYPE
SYNTAX PrtMediaUnitTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The units of measure of media size for use in calculating and
relaying dimensional values for all media paths in the
printer."
::= { prtMediaPathEntry 3 }
prtMediaPathMaxSpeed OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum printing speed of this media path expressed in
prtMediaPathMaxSpeedUnit's. A value of (-1) implies 'other'."
::= { prtMediaPathEntry 4 }
prtMediaPathMaxMediaFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum physical media size in the feed direction of this
media path expressed in units of measure specified by
PrtMediaPathMediaSizeUnit. A value of (-1) implies 'unlimited'
a value of (-2) implies 'unknown'.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMediaPathEntry 5 }
prtMediaPathMaxMediaXFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum physical media size across the feed direction of
this media path expressed in units of measure specified by
prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'.
Bergman, et al. Standards Track [Page 111]

RFC 3805 Printer MIB v2 June 2004
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMediaPathEntry 6 }
prtMediaPathMinMediaFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum physical media size in the feed direction of this
media path expressed in units of measure specified by
prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMediaPathEntry 7 }
prtMediaPathMinMediaXFeedDir OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum physical media size across the feed direction of
this media path expressed in units of measure specified by
prtMediaPathMediaSizeUnit. A value of (-2) implies 'unknown'.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtMediaPathEntry 8 }
prtMediaPathType OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtMediaPathTypeTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of the media path for this media path."
::= { prtMediaPathEntry 9 }
prtMediaPathDescription OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtLocalizedDescriptionStringTC
MAX-ACCESS read-only
STATUS current
Bergman, et al. Standards Track [Page 112]

RFC 3805 Printer MIB v2 June 2004
DESCRIPTION
"The manufacturer-provided description of this media path in
the localization specified by prtGeneralCurrentLocalization."
::= { prtMediaPathEntry 10 }
prtMediaPathStatus OBJECT-TYPE
SYNTAX PrtSubUnitStatusTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current status of this media path."
::= { prtMediaPathEntry 11 }
-- The Print Job Delivery Channel Group
--
-- Print Job Delivery Channels are independent sources of print
-- data. Here, print data is the term used for the information
-- that is used to construct printed pages and may have both data
-- and control aspects. The output of a channel is in a form
-- suitable for input to one of the interpreters as a
-- stream. A channel may be independently enabled (allowing
-- print data to flow) or disabled (stopping the flow of
-- print data). A printer may have one or more channels.
--
-- The Print Job Delivery Channel table describes the
-- capabilities of the printer and not what is currently being
-- performed by the printer
--
-- Basically, the print job delivery channel abstraction
-- describes the final processing step of getting the print data
-- to an interpreter. It might include some level of
-- decompression or decoding of print stream data.
-- channel. All of these aspects are hidden in the channel
-- abstraction.
--
-- There are many kinds of print job delivery channels; some of
-- which are based on networks and others which are not. For
-- example, a channel can be a serial (or parallel) connection;
-- it can be a service, such as the UNIX Line Printer Daemon
-- (LPD), offering services over a network connection; or
-- it could be a disk drive into which a floppy disk with
-- the print data is inserted. Each print job delivery channel is
-- identified by the electronic path and/or service protocol
-- used to deliver print data to a print data interpreter.
--
-- Channel example Implementation
--
-- serial port channel bi-directional data channel
Bergman, et al. Standards Track [Page 113]

RFC 3805 Printer MIB v2 June 2004
-- parallel port channel often uni-directional channel
-- IEEE 1284 port channel bi-directional channel
-- SCSI port channel bi-directional
-- Apple PAP channel may be based on LocalTalk,
-- Ethernet or Tokentalk
-- LPD Server channel TCP/IP based, port 515
-- Netware Remote Printer SPX/IPX based channel
-- Netware Print Server SPX/IPX based channel
--
-- It is easy to note that this is a mixed bag. There are
-- some physical connections over which no (or very meager)
-- protocols are run (e.g., the serial or old parallel ports)
-- and there are services which often have elaborate
-- protocols that run over a number of protocol stacks. In
-- the end, what is important is the delivery of print data
-- through the channel.
--
-- The print job delivery channel sub-units are represented by
-- the Print Job Delivery Channel Group in the Model. It has a
-- current print job control language, which can be used to
-- specify which interpreter is to be used for the print data and
-- to query and change environment variables used by the
-- interpreters (and Management Applications). There is also a
-- default interpreter that is to be used if an interpreter is
-- not explicitly specified using the Control Language.
-- The first seven items in the Print Job Delivery Channel Table
-- define the "channel" itself. A channel typically depends on
-- other protocols and interfaces to provide the data that flows
-- through the channel.
--
-- Control of a print job delivery channel is largely limited to
-- enabling or disabling the entire channel itself. It is likely
-- that more control of the process of accessing print data
-- will be needed over time. Thus, the ChannelType will
-- allow type-specific data to be associated with each
-- channel (using ChannelType specific groups in a fashion
-- analogous to the media specific MIBs that are associated
-- with the IANAIfType in the Interfaces Table). As a first
-- step in this direction, each channel will identify the
-- underlying Interface on which it is based. This is the
-- eighth object in each row of the table.
Bergman, et al. Standards Track [Page 114]

RFC 3805 Printer MIB v2 June 2004
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value used by the printer to identify this data
channel. Although these values may change due to a major
reconfiguration of the device (e.g., the addition of new data
channels to the printer), values SHOULD remain stable across
successive printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtChannelEntry 1 }
prtChannelType OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtChannelTypeTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of this print data channel. This object provides the
linkage to ChannelType-specific groups that may (conceptually)
extend the prtChannelTable with additional details about that
channel."
::= { prtChannelEntry 2 }
prtChannelProtocolVersion OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..63))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version of the protocol used on this channel. The format
used for version numbering depends on prtChannelType."
::= { prtChannelEntry 3 }
prtChannelCurrentJobCntlLangIndex OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtInterpreterIndex corresponding to the Control
Language Interpreter for this channel. This interpreter defines
the syntax used for control functions, such as querying or
changing environment variables and identifying job boundaries
(e.g., PJL, PostScript, NPAP). A value of zero indicates that
there is no current Job Control Language Interpreter for this
channel.
Bergman, et al. Standards Track [Page 116]

RFC 3805 Printer MIB v2 June 2004
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtChannelEntry 4 }
prtChannelDefaultPageDescLangIndex OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of prtInterpreterIndex corresponding to the Page
Description Language Interpreter for this channel. This
interpreter defines the default Page Description Language
interpreter to be used for the print data unless the Control
Language is used to select a specific interpreter (e.g., PCL,
PostScript Language, auto-sense). A value of zero indicates
that there is no default page description language interpreter
for this channel.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtChannelEntry 5 }
prtChannelState OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtChannelStateTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The state of this print data channel. The value determines
whether control information and print data is allowed through
this channel or not."
::= { prtChannelEntry 6 }
prtChannelIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero -- Was Integer32 in RFC 1759.
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of ifIndex in the ifTable; see the Interfaces Group
MIB [RFC2863] which corresponds to this channel.
When more than one row of the ifTable is relevant, this is the
index of the row representing the topmost layer in the
interface hierarchy. A value of zero indicates that no
interface is associated with this channel.
NOTE: The above description has been modified from RFC 1759Bergman, et al. Standards Track [Page 117]

RFC 3805 Printer MIB v2 June 2004
for clarification."
::= { prtChannelEntry 7 }
prtChannelStatus OBJECT-TYPE
SYNTAX PrtSubUnitStatusTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current status of the channel."
::= { prtChannelEntry 8 }
prtChannelInformation OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Auxiliary information to allow a printing application to use
the channel for data submission to the printer. An application
capable of using a specific PrtChannelType should be able to
use the combined information from the prtChannelInformation and
other channel and interface group objects to 'bootstrap' its
use of the channel. prtChannelInformation is not intended to
provide a general channel description, nor to provide
information that is available once the channel is in use.
The encoding and interpretation of the prtChannelInformation
object is specific to channel type. The description of each
PrtChannelType enum value for which prtChannelInformation is
defined specifies the appropriate encoding and interpretation,
including interaction with other objects. For channel types
that do not specify a prtChannelInformation value, its value
shall be null (0 length).
When a new PrtChannelType enumeration value is registered, its
accompanying description must specify the encoding and
interpretation of the prtChannelInformation value for the
channel type. prtChannelInformation semantics for an existing
PrtChannelType may be added or amended in the same manner as
described in section 2.4.1 for type 2 enumeration values.
The prtChannelInformation specifies values for a collection of
channel attributes, represented as text according to the
following rules:
1. The prtChannelInformation is not affected by localization.
2. The prtChannelInformation is a list of entries representing
the attribute values. Each entry consists of the following
Bergman, et al. Standards Track [Page 118]

RFC 3805 Printer MIB v2 June 2004
items, in order:
a. A keyword, composed of alphabetic characters (A-Z, a-z)
represented by their NVT ASCII [RFC854] codes, that
identifies a channel attribute,
b. The NVT ASCII code for an Equals Sign (=) (code 61) to
delimit the keyword,
c. A data value encoded using rules specific to the
PrtChannelType to with the prtChannelInformation applies which
must in no case allow an octet with value 10 (the NVT ASCII
Line Feed code),
d. the NVT ASCII code for a Line Feed character (code 10) to
delimit the data value.
No other octets shall be present.
Keywords are case-sensitive. Conventionally, keywords are
capitalized (including each word of a multi-word keyword) and
since they occupy space in the prtChannelInformation, they are
kept short.
3. If a channel attribute has multiple values, it is
represented by multiple entries with the same keyword, each
specifying one value. Otherwise, there shall be at most one
entry for each attribute.
4. By default, entries may appear in any order. If there are
ordering constraints for particular entries, these must be
specified in their definitions.
5. The prtChannelInformation value by default consists of text
represented by NVT ASCII graphics character codes. However,
other representations may be specified:
a. In cases where the prtChannelInformation value contains
information not normally coded in textual form, whatever
symbolic representation is conventionally used for the
information should be used for encoding the
prtChannelInformation value. (For instance, a binary port value
might be represented as a decimal number using NVT ASCII
codes.) Such encoding must be specified in the definition of
the value.
b. The value may contain textual information in a character set
other than NVT ASCII graphics characters. (For instance, an
Bergman, et al. Standards Track [Page 119]

RFC 3805 Printer MIB v2 June 2004
identifier might consist of ISO 10646 text encoded using the
UTF-8 encoding scheme.) Such a character set and its encoding
must be specified in the definition of the value.
6. For each PrtChannelType for which prtChannelInformation
entries are defined, the descriptive text associated with the
PrtChannelType enumeration value shall specify the following
information for each entry:
Title: Brief description phrase, e.g.: 'Port name',
'Service Name', etc.
Keyword: The keyword value, e.g.: 'Port' or 'Service'
Syntax: The encoding of the entry value if it cannot be
directly represented by NVT ASCII.
Status: 'Mandatory', 'Optional', or 'Conditionally
Mandatory'
Multiplicity: 'Single' or 'Multiple' to indicate whether the
entry may be present multiple times.
Description: Description of the use of the entry, other
information required to complete the definition
(e.g.: ordering constraints, interactions between
entries).
Applications that interpret prtChannelInformation should ignore
unrecognized entries, so they are not affected if new entry
types are added."
::= { prtChannelEntry 9 }
-- The Interpreter Group
--
-- The interpreter sub-units are responsible for the conversion
-- of a description of intended print instances into images that
-- are to be marked on the media. A printer may have one or more
-- interpreters. The interpreter sub-units are represented by the
-- Interpreter Group in the Model. Each interpreter is generally
-- implemented with software running on the System Controller
-- sub-unit. The Interpreter Table has one entry per interpreter
-- where the interpreters include both Page Description Language
-- (PDL) Interpreters and Control Language Interpreters.
prtInterpreter OBJECT IDENTIFIER ::= { printmib 15 }
Bergman, et al. Standards Track [Page 120]

RFC 3805 Printer MIB v2 June 2004
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each PDL or control language for which
there exists an interpreter or emulator in the printer. The
value is used to identify this interpreter. Although these
values may change due to a major reconfiguration of the device
(e.g., the addition of new interpreters to the printer), values
SHOULD remain stable across successive printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtInterpreterEntry 1 }
prtInterpreterLangFamily OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtInterpreterLangFamilyTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The family name of a Page Description Language (PDL) or
control language which this interpreter in the printer can
interpret or emulate.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtInterpreterEntry 2 }
prtInterpreterLangLevel OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..31))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The level of the language which this interpreter is
interpreting or emulating. This might contain a value like
'5e'for an interpreter which is emulating level 5e of the PCL
language. It might contain '2' for an interpreter which is
emulating level 2 of the PostScript language. Similarly it
might contain '2' for an interpreter which is emulating level 2
of the HPGL language."
::= { prtInterpreterEntry 3 }
prtInterpreterLangVersion OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..31))
MAX-ACCESS read-only
STATUS current
Bergman, et al. Standards Track [Page 122]

RFC 3805 Printer MIB v2 June 2004
DESCRIPTION
"The date code or version of the language which this
interpreter is interpreting or emulating."
::= { prtInterpreterEntry 4 }
prtInterpreterDescription OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtLocalizedDescriptionStringTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A string to identify this interpreter in the localization
specified by prtGeneralCurrentLocalization as opposed to the
language which is being interpreted. It is anticipated that
this string will allow manufacturers to unambiguously identify
their interpreters."
::= { prtInterpreterEntry 5 }
prtInterpreterVersion OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..31))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date code, version number, or other product specific
information tied to this interpreter. This value is associated
with the interpreter, rather than with the version of the
language which is being interpreted or emulated."
::= { prtInterpreterEntry 6 }
prtInterpreterDefaultOrientation OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtPrintOrientationTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current orientation default for this interpreter. This
value may be overridden for a particular job (e.g., by a
command in the input data stream)."
::= { prtInterpreterEntry 7 }
prtInterpreterFeedAddressability OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Bergman, et al. Standards Track [Page 123]

RFC 3805 Printer MIB v2 June 2004
"The maximum interpreter addressability in the feed
direction in 10000 prtMarkerAddressabilityUnits (as specified
by prtMarkerDefaultIndex) for this interpreter. The
value (-1) means other and specifically indicates that the
sub-unit places no restrictions on this parameter. The value
(-2) means unknown.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtInterpreterEntry 8 }
prtInterpreterXFeedAddressability OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum interpreter addressability in the cross feed
direction in 10000 prtMarkerAddressabilityUnits (as specified
by prtMarkerDefaultIndex) for this interpreter. The
value (-1) means other and specifically indicates that the
sub-unit places no restrictions on this parameter. The value
(-2) means unknown.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtInterpreterEntry 9 }
prtInterpreterDefaultCharSetIn OBJECT-TYPE
SYNTAX IANACharset
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default coded character set for input octets encountered
outside a context in which the Page Description Language
established the interpretation of the octets. (Input octets are
presented to the interpreter through a path defined in the
channel group.)"
::= { prtInterpreterEntry 10 }
prtInterpreterDefaultCharSetOut OBJECT-TYPE
SYNTAX IANACharset
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default character set for data coming from this
interpreter through the printer's output channel (i.e. the
'backchannel')."
Bergman, et al. Standards Track [Page 124]

RFC 3805 Printer MIB v2 June 2004
::= { prtInterpreterEntry 11 }
prtInterpreterTwoWay OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtInterpreterTwoWayTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether or not this interpreter returns information
back to the host."
::= { prtInterpreterEntry 12 }
-- The Console Group
--
-- 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 Display Buffer Table
prtConsoleDisplayBuffer OBJECT IDENTIFIER ::= { printmib 16 }
prtConsoleDisplayBufferTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtConsoleDisplayBufferEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Physical display buffer for printer console display or
operator panel
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtConsoleDisplayBuffer 5 }
prtConsoleDisplayBufferEntry OBJECT-TYPE
SYNTAX PrtConsoleDisplayBufferEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains one entry for each physical line on
the display. Lines cannot be added or deleted. Entries may
exist in the table for each device index with a device type of
'printer'.
NOTE: The above description has been modified from RFC 1759Bergman, et al. Standards Track [Page 125]

RFC 3805 Printer MIB v2 June 2004
for clarification."
INDEX { hrDeviceIndex, prtConsoleDisplayBufferIndex }
::= { prtConsoleDisplayBufferTable 1 }
PrtConsoleDisplayBufferEntry ::= SEQUENCE {
prtConsoleDisplayBufferIndex Integer32,
prtConsoleDisplayBufferText PrtConsoleDescriptionStringTC
}
prtConsoleDisplayBufferIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each console line in the printer. The value
is used to identify this console line. Although these values
may change due to a major reconfiguration of the device (e.g.,
the addition of new console lines to the printer). Values
SHOULD remain stable across successive printer power cycles.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtConsoleDisplayBufferEntry 1 }
prtConsoleDisplayBufferText OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtConsoleDescriptionStringTC
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The content of a line in the logical display buffer of
the operator's console of the printer. When a write
operation occurs, normally a critical message, to one of
the LineText strings, the agent should make that line
displayable if a physical display is present. Writing a zero
length string clears the line. It is an implementation-
specific matter as to whether the agent allows a line to be
overwritten before it has been cleared. Printer generated
strings shall be in the localization specified by
prtConsoleLocalization.Management Application generated strings
should be localized by the Management Application."
::= { prtConsoleDisplayBufferEntry 2 }
-- The Console Light Table
prtConsoleLights OBJECT IDENTIFIER ::= { printmib 17 }
Bergman, et al. Standards Track [Page 126]

RFC 3805 Printer MIB v2 June 2004
prtConsoleOnTime OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object, in conjunction with prtConsoleOffTime, defines
the current status of the light. If both prtConsoleOnTime and
prtConsoleOffTime are non-zero, the lamp is blinking and the
values presented define the on time and off time, respectively,
in milliseconds. If prtConsoleOnTime is zero and
prtConsoleOffTime is non-zero, the lamp is off. If
prtConsoleOffTime is zero and prtConsoleOnTime is non-zero, the
lamp is on. If both values are zero the lamp is off.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtConsoleLightEntry 2 }
prtConsoleOffTime OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object, in conjunction with prtConsoleOnTime, defines the
current status of the light. If both prtConsoleOnTime and
prtConsoleOffTime are non-zero, the lamp is blinking and the
values presented define the on time and off time, respectively,
in milliseconds. If prtConsoleOnTime is zero and
prtConsoleOffTime is non-zero, the lamp is off. If
prtConsoleOffTime is zero and prtConsoleOnTime is non-zero, the
lamp is on. If both values are zero the lamp is off.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtConsoleLightEntry 3 }
prtConsoleColor OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtConsoleColorTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The color of this light."
::= { prtConsoleLightEntry 4 }
Bergman, et al. Standards Track [Page 128]

RFC 3805 Printer MIB v2 June 2004
prtConsoleDescription OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtConsoleDescriptionStringTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor description or label of this light in the
localization specified by prtConsoleLocalization."
::= { prtConsoleLightEntry 5 }
-- The Alerts Group
--
-- The table contains information on the severity, component,
-- detail location within the component, alert code and
-- description of each critical alert that is currently active
-- within the printer. See 2.2.13 for a more complete
-- description of the alerts table and its management.
--
-- Each parameter in the Trap PDU is a full OID which itself is
-- indexed by the host resources MIB "hrDeviceIndex" object. In
-- order for a management station to obtain the correct
-- "hrDeviceIndex" associated with a particular Trap PDU, the
-- "hrDeviceIndex" value can be extracted from the returned OID
-- value in the Trap PDU when the PDU is received by the
-- Management station.
prtAlert OBJECT IDENTIFIER ::= { printmib 18 }
prtAlertTable OBJECT-TYPE
SYNTAX SEQUENCE OF PrtAlertEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The prtAlertTable lists all the critical and non-critical
alerts currently active in the printer. A critical alert is
one that stops the printer from printing immediately and
printing can not continue until the critical alert condition
is eliminated. Non-critical alerts are those items that do
not stop printing but may at some future time.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtAlert 1 }
prtAlertEntry OBJECT-TYPE
SYNTAX PrtAlertEntry
MAX-ACCESS not-accessible
Bergman, et al. Standards Track [Page 129]

RFC 3805 Printer MIB v2 June 2004
STATUS current
DESCRIPTION
"Entries may exist in the table for each device
index with a device type of 'printer'.
NOTE: The above description has been modified from RFC 1759
for clarification."
INDEX { hrDeviceIndex, prtAlertIndex }
::= { prtAlertTable 1 }
PrtAlertEntry ::= SEQUENCE {
prtAlertIndex Integer32,
prtAlertSeverityLevel PrtAlertSeverityLevelTC,
prtAlertTrainingLevel PrtAlertTrainingLevelTC,
prtAlertGroup PrtAlertGroupTC,
prtAlertGroupIndex Integer32,
prtAlertLocation Integer32,
prtAlertCode PrtAlertCodeTC,
prtAlertDescription PrtLocalizedDescriptionStringTC,
prtAlertTime TimeTicks
}
prtAlertIndex OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined. The MAX-ACCESS has
-- been changed from not accessible to allow the object to be
-- included (as originally in RFC 1759) in the trap bindings.
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The index value used to determine which alerts have been added
or removed from the alert table. This is an incrementing
integer initialized to 1 when the printer is reset. (i.e., The
first event placed in the alert table after a reset of the
printer shall have an index value of 1.) When the printer adds
an alert to the table, that alert is assigned the next higher
integer value from the last item entered into the table. If
the index value reaches its maximum value, the next index value
used must be 1.
NOTE: The management application will read the alert table when
a trap or event notification occurs or at a periodic rate and
then parse the table to determine if any new entries were added
by comparing the last known index value with the current
highest index value. The management application will then
update its copy of the alert table. When the printer discovers
that an alert is no longer active, the printer shall remove the
Bergman, et al. Standards Track [Page 130]

RFC 3805 Printer MIB v2 June 2004
row for that alert from the table and shall reduce the number
of rows in the table. The printer may add or delete any number
of rows from the table at any time. The management station can
detect when binary change alerts have been deleted by
requesting an attribute of each alert, and noting alerts as
deleted when that retrieval is not possible. The objects
'prtAlertCriticalEvents'and 'prtAlertAllEvents' in the
'prtGeneralTable' reduce the need for management applications
to scan the 'prtAlertTable'.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtAlertEntry 1 }
prtAlertSeverityLevel OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtAlertSeverityLevelTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The level of severity of this alert table entry. The printer
determines the severity level assigned to each entry into the
table."
::= { prtAlertEntry 2 }
prtAlertTrainingLevel OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtAlertTrainingLevelTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"See TEXTUAL-CONVENTION PrtAlertTrainingLevelTC.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtAlertEntry 3 }
prtAlertGroup OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtAlertGroupTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of sub-unit within the printer model that this alert
is related. Input, output, and markers are examples of printer
Bergman, et al. Standards Track [Page 131]

RFC 3805 Printer MIB v2 June 2004
model groups, i.e., examples of types of sub-units. Wherever
possible, these enumerations match the sub-identifier that
identifies the relevant table in the printmib."
::= { prtAlertEntry 4 }
prtAlertGroupIndex OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The low-order index of the row within the table identified
by prtAlertGroup that represents the sub-unit of the printer
that caused this alert, or -1 if not applicable. The
combination of the prtAlertGroup and the prtAlertGroupIndex
defines exactly which printer sub-unit caused the alert; for
example, Input #3, Output#2, and Marker #1. Every object in
this MIB is indexed with hrDeviceIndex and optionally, another
index variable. If this other index variable is present in the
table that generated the alert, it will be used as the value
for this object. Otherwise, this value shall be -1.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtAlertEntry 5 }
prtAlertLocation OBJECT-TYPE
-- NOTE: In RFC 1759, the range was not defined.
SYNTAX Integer32 (-2..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The sub-unit location that is defined by the printer
manufacturer to further refine the location of this alert
within the designated sub-unit. The location is used in
conjunction with the Group and GroupIndex values; for example,
there is an alert in Input #2 at location number 7. The value
(-2) indicates unknown.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtAlertEntry 6 }
prtAlertCode OBJECT-TYPE
-- NOTE: In RFC 1759, the enumeration values were implicitly
-- defined by this object.
SYNTAX PrtAlertCodeTC
MAX-ACCESS read-only
Bergman, et al. Standards Track [Page 132]

RFC 3805 Printer MIB v2 June 2004
STATUS current
DESCRIPTION
"See associated TEXTUAL-CONVENTION PrtAlertCodeTC.
NOTE: The above description has been modified from RFC 1759
for clarification."
::= { prtAlertEntry 7 }
prtAlertDescription OBJECT-TYPE
-- In RFC 1759, the SYNTAX was OCTET STRING. This has been changed
-- to a TC to better support localization of the object.
SYNTAX PrtLocalizedDescriptionStringTC
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A description of this alert entry in the localization
specified by prtGeneralCurrentLocalization. The description is
provided by the printer to further elaborate on the enumerated
alert or provide information in the case where the code is
classified as 'other' or 'unknown'. The printer is required to
return a description string but the string may be a null
string."
::= { prtAlertEntry 8 }
prtAlertTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time that this alert was
generated."
::= { prtAlertEntry 9 }
printerV1Alert OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The value of the enterprise-specific OID in an SNMPv1 trap
sent signaling a critical event in the prtAlertTable."
::= { prtAlert 2 }
printerV2AlertPrefix OBJECT IDENTIFIER ::= { printerV1Alert 0 }
printerV2Alert NOTIFICATION-TYPE
OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup,
prtAlertGroupIndex, prtAlertLocation, prtAlertCode }
STATUS current
DESCRIPTION
"This trap is sent whenever a critical event is added to the
Bergman, et al. Standards Track [Page 133]

RFC 3805 Printer MIB v2 June 2004
object. Any additional states are optional."
OBJECT prtConsoleOnTime
MIN-ACCESS read-only
DESCRIPTION
"It is conformant to implement this object as read-only"
OBJECT prtConsoleOffTime
MIN-ACCESS read-only
DESCRIPTION
"It is conformant to implement this object as read-only"
::= { prtMIBConformance 1 }
prtMIB2Compliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for agents that implement the
printer MIB V2."
-- The changes from RFC 1759 fall into 2 categories:
-- 1. New objects plus existing objects with a MIN-ACCESS of
-- read-only are included. Existing objects have been added
-- to this category due to feedback from implementers and
-- interoperability testing. This allows products to be
-- be designed with a higher degree of SNMP security.
-- 2. New object groups have been added to include all new
-- objects in this MIB. All new object groups are optional.
-- Any MIB that is compliant with RFC 1759 will also be
-- compliant with this version of the MIB.
MODULE -- this module
MANDATORY-GROUPS { prtGeneralGroup, prtInputGroup,
prtOutputGroup,
prtMarkerGroup, prtMediaPathGroup,
prtChannelGroup, prtInterpreterGroup,
prtConsoleGroup, prtAlertTableGroup }
OBJECT prtGeneralReset
SYNTAX INTEGER {
notResetting(3),
resetToNVRAM(5)
}
DESCRIPTION
"It is conformant to implement just these two states in this
object. Any additional states are optional."
OBJECT prtGeneralCurrentLocalization
MIN-ACCESS read-only
DESCRIPTION
"It is conformant to implement this object as read-only"
Bergman, et al. Standards Track [Page 135]

RFC 3805 Printer MIB v2 June 2004
DESCRIPTION
"This group is unconditionally optional."
GROUP prtInputMediaGroup
DESCRIPTION
"This group is unconditionally optional."
GROUP prtExtendedOutputGroup
DESCRIPTION
"This group is unconditionally optional."
GROUP prtOutputDimensionsGroup
DESCRIPTION
"This group is unconditionally optional."
GROUP prtOutputFeaturesGroup
DESCRIPTION
"This group is unconditionally optional."
GROUP prtMarkerSuppliesGroup
DESCRIPTION
"This group is unconditionally optional."
GROUP prtMarkerColorantGroup
DESCRIPTION
"This group is unconditionally optional."
GROUP prtAlertTimeGroup
DESCRIPTION
"This group is unconditionally optional."
-- the prtResponsiblePartyGroup, prtExtendedInputGroup,
-- prtInputMediaGroup, prtExtendedOutputGroup,
-- prtOutputDimensionsGroup, prtOutputFeaturesGroup,
-- prtMarkerSuppliesGroup, prtMarkerColorantGroup, and the
-- prtAlertTimeGroup are completely optional. However, it is
-- strongly RECOMMENDED that the prtAlertTimeGroup be implemented.
-- New to version 2 of this printer MIB:
OBJECT prtAuxiliarySheetStartupPage
MIN-ACCESS read-only
DESCRIPTION
"It is conformant to implement this object as read-only"
OBJECT prtAuxiliarySheetBannerPage
MIN-ACCESS read-only
DESCRIPTION
"It is conformant to implement this object as read-only"
Bergman, et al. Standards Track [Page 141]

RFC 3805 Printer MIB v2 June 2004
Appendix A - Glossary of Terms
Addressability - On the marker, the number of distinct marking units
(pels) per unit of addressability unit that can be set; for example,
300 dots per inch is expressed as 300 per 1000 Thousandths Of Inches
and 4 dots per millimeter is 4 per 1000 Micrometers. Addressability
is not resolution because marks that are one addressability position
apart may not be independently resolvable by the eye due to factors
such as gain in the area of marks so they overlap or nearly touch.
Alert - A reportable event for which there is an entry in the alert
table.
Bin - An output sub-unit which may or may not be removable.
Binary Change Event - An event which comes 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. A binary change event may
be critical or non-critical. See unary change event.
Bursting - The process by which continuous media is separated into
individual sheets, typically by bursting along pre-formed
perforations.
Channel - A term used to describe a single source of data which is
presented to a printer. The model that we use in describing a
printer allows for an arbitrary number of channels. Multiple
channels can exist on the same physical port. This is commonly done
over Ethernet ports where EtherTalk, TCP/IP, and SPX/IPX protocols
can be supplying different data streams simultaneously to a single
printer on the same physical port.
Collation - In multiple copy output, placing the pages from separate
copies into separate ordered sets, ready for binding.
Control Language - A data syntax or language for controlling the
printer through the print data channel.
Critical Alert - An alert triggered by an event which leads to a
state in which printing is no longer possible; the printer is
stopped.
Decollating - The process by which the individual parts within a
multi-part form are separated and sorted into separate stacks for
each part.
Description - Information about the configuration and capabilities of
the printer and its various sub-units.
Bergman, et al. Standards Track [Page 153]

RFC 3805 Printer MIB v2 June 2004
DPA - ISO 10175 Document Printing Application standard. A standard
for a client server protocol for a print system, including (1)
submitting print jobs to and (2) managing print jobs in a spooler.
Event - A state change in the printer.
Group - A collection of objects that represent a type of sub-unit of
the printer.
Host Resources MIB - See [RFC2790].
IANA - Internet Assigned Numbers Authority. See [RFC3232].
Idempotent - Idempotence is the property of an operation that results
in the same state no matter how many times it is executed (at least
once). This is a property that is shared by true databases in which
operations on data items only change the state of the data item and
do not have other side effects. Because the SNMP data model is that
of operations on a database, SNMP MIB objects should be assumed to be
idempotent. If a MIB object is defined in a non-idempotent way, the
this data model can break in subtle ways when faced with packet loss,
multiple managers, and other common conditions.
In order to fulfill the common need for actions to result from
SNMP Set operations, SNMP MIB objects can be modeled such that the
change in state from one state to another has the side effect of
causing an action. It is important to note that with this model,
an SNMP operation that sets a value equal to its current value
will cause no action. This retains the idempotence of a single
command, while allowing actions to be initiated by SNMP SET
requests.
Input - A tray or bin from which instances of the media are obtained
and fed into the Media Path.
Interpreter - The embodiment of an algorithm that processes a data
stream consisting of a Page Description Language (PDL) and/or a
Control Language.
Localization - The specification of human language, country, and
character set needed to present information to people in their native
languages.
Management Application (a.k.a. Manager) - A program which queries and
controls one or more managed nodes.
Management Station - A physical computer on which one or more
management applications can run.
Bergman, et al. Standards Track [Page 154]

RFC 3805 Printer MIB v2 June 2004
Media Path - The mechanisms that transport instances of the media
from an input, through the marker, possibly through media buffers and
duplex pathways, out to the output with optional finishing applied.
The inputs and outputs are not part of the Media Path.
Non-critical Alert - An alert triggered by a reportable event which
does not lead to a state in which printing is no longer possible;
such an alert may lead to a state from which printing may no longer
be possible in the future, such as the low toner state or the alert
may be pure informational, such as a configuration change at the
printer.
Output - A bin or stacker which accepts instances of media that have
been processed by a printer.
Page Description Language (PDL) - A data syntax or language for the
electronic representation of a document as a sequence of page images.
Printer - A 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.
Printing - The entire process of producing a printed document from
generation of the file to be printed, choosing printing properties,
selection of a printer, routing, queuing, resource management,
scheduling, and finally printing including notifying the user.
Reportable event - An event that is deemed of interest to a
management station watching the printer.
Status - Information regarding the current operating state of the
printer and its various sub-units. This is an abstraction of the
exact physical condition of the printer.
Sub-mechanism - A distinguishable part of a sub-unit.
Sub-unit - A part of the printer which may be a physical part, such
as one of the input sources or a logical part such as an interpreter.
Tray - An input sub-unit which is typically removable.
Unary Change Event - An event that indicates a change of state of the
printer, but to a state which is (often) just as valid as the state
that was left, and from which no return is necessary. See binary
change event.
Bergman, et al. Standards Track [Page 155]

RFC 3805 Printer MIB v2 June 2004
Visible state - The portion of the state of the printer that can be
examined by a management application.
Warning - A non-critical alert. See non-critical alert.
Appendix B - Media Size Names
The PWG Standardized Media Names specification [PWGMEDIA], section 5
Self Describing Names, contains the currently recommended media size
names. This appendix lists the standardized media size names from
ISO/IEC 10175 Document Printing Application (DPA), [ISO10175] as
presented in RFC 1759. Management applications are encouraged to use
the names from the PWG standard. However, many legacy systems exist
that use the DPA names and they are presented here for the
convenience of developers.
A printer implementing the Printer MIB has no knowledge of these
names, however; all media sizes in the MIB are given in terms of
media dimensions as the values of prtInputMediaDimFeedDirChosen and
prtInputMediaDimXFeedDirChosen.
String name Description
other
unknown
na-letter or letter North American letter size: 8.5 by 11 inches
na-legal or legal North American legal size: 8.5 by 14 inches
na-10x13-envelope North American 10x13 envelope
size: 10 by 13 inches
na-9x12-envelope North American 9x12 envelope
size: 9 by 12 inches
na-number-10-envelope North American number 10 business envelope
size: 4.125 by 9.5 inches
na-7x9-envelope North American 7x9 size: 7 by 9 inches
na-9x11-envelope North American 9x11 size: 9 by 11 inches
na-10x14-envelope North American 10x14 envelope
size: 10 by 14 inches
na-number-9-envelope North American number 9 business envelope
size: 3.875 by 8.875 inches
na-6x9-envelope North American 6x9 envelope
size: 6 by 9 inches
na-10x15-envelope North American 10x15 envelope
size: 10 by 15 inches
a engineering A size 8.5 inches by 11 inches
b engineering B size 11 inches by 17 inches
c engineering C size 17 inches by 22 inches
d engineering D size 22 inches by 34 inches
Bergman, et al. Standards Track [Page 156]

RFC 3805 Printer MIB v2 June 2004
Appendix C - Media Names
For the convenience of management application developers, this
appendix lists the standardized media names from ISO/IEC 10175
Document Printing Application (DPA), [ISO10175]. Management
applications that present a dialogue for choosing media may wish to
use these names as an alternative to separately specifying, size,
color, and/or type. New names may also be created using this format
and the names defined in the PWG Standardized Media Names
specification [PWGMEDIA].
Using standard media names will mean that a single management
application dealing with printers from different vendors and under
different system mangers will tend to use the same names for the same
media. If selection of media by name is used, the attributes (size,
type or color) implied by the name must be explicitly mapped to the
appropriate object (prtInputMediaDimFeedDirDeclared,
prtInputMediaDimXFeedDirDeclared, prtInputMediaType and
prtInputMediaColor) in the MIB. The object prtInputMediaName is
intended for display to an operator and is purely descriptive. The
value in prtInputMediaName is not interpreted by the printer so using
a standard name for this value will not change any of the other media
attributes nor will it cause an alert if the media in the input sub-
unit does not match the name.
Simple Name Descriptor Text
other
unknown
iso-a4-white Specifies the ISO A4 white medium with
size: 210 mm by 297 mm as defined in ISO 216
iso-a4-coloured Specifies the ISO A4 colored medium with
size: 210 mm by 297 mm as defined in ISO 216
iso-a4-transparent Specifies the ISO A4 transparent medium with
size: 210 mm by 297 mm as defined in ISO 216
iso-a3-white Specifies the ISO A3 white medium with
size: 297 mm by 420 mm as defined in ISO 216
iso-a3-coloured Specifies the ISO A3 colored medium with
size: 297 mm by 420 mm as defined in ISO 216
iso-a5-white Specifies the ISO A5 white medium with
size: 148 mm by 210 mm as defined in ISO 216
iso-a5-coloured Specifies the ISO A5 colored medium with
size: 148 mm by 210 mm as defined in ISO 216
iso-b4-white Specifies the ISO B4 white medium with
size: 250 mm by 353 mm as defined in ISO 216
iso-b4-coloured Specifies the ISO B4 colored medium with
size: 250 mm by 353 mm as defined in ISO 216
Bergman, et al. Standards Track [Page 158]

RFC 3805 Printer MIB v2 June 2004
The following standard values are defined for engineering media:
a Specifies the engineering A size medium with
size: 8.5 inches by 11 inches
b Specifies the engineering B size medium with
size: 11 inches by 17 inches
c Specifies the engineering C size medium with
size: 17 inches by 22 inches
d Specifies the engineering D size medium with
size: 22 inches by 34 inches
e Specifies the engineering E size medium with
size: 34 inches by 44 inches
Appendix D - Roles of Users
Background
The need for "Role Models" stemmed in large part from the need to
understand the importance of any given proposed object for the MIB.
Many times the real world need for a proposed object would be debated
within the group; the debate would typically result in the need to
describe the potential usage of the object in terms of a "live"
person performing some type of printing-related task.
Determining the value of a proposed object through identification of
the associated human users was found to be so common that a more
formalized model was required for consistent analysis. The model
describing categories of human-oriented tasks is called "Role Models"
in this document.
In developing the Role Models it was necessary to identify the
common, primary tasks that humans typically face when interacting
with a printer and its related printing system(s). It was expected
that certain kinds of tasks would serve to identify the various Role
Models.
In presenting the set of Role Models, the set of "Common Print System
Tasks" are first presented, followed by the set of Role Model
definitions. Finally, a simple matrix is presented in which Role
Models and Tasks are cross-compared.
Common Print System Tasks
Upon researching the many tasks encountered by humans in dealing with
printers and printing systems, the following were found to be
pervasive within any operating environment:
Printer job state - Determine the status of a job without a printer.
Bergman, et al. Standards Track [Page 162]

RFC 3805 Printer MIB v2 June 2004
Printer capabilities - Determine the current capabilities of a
printer, for example, the available media sizes, two-sided printing,
a particular type of interpreter, etc.
Printer job submission - Submit a print job to a printer.
Printer job removal - Remove a job from a printer.
Notification of events - Receive notification of the existence of a
defined printer event. An event can be of many types, including
warnings, errors, job stage completion (e.g., "job done"), etc.
Printer configuration - Query the current configuration of a printer.
Printer consumables - Determine the current state of any and all
consumables within a printer.
Print job identification - Determine the identification of a job
within a printer.
Internal printer status - Determine the current status of the
printer.
Printer identification - Determine the identity of a printer.
Printer location - Determine the physical location of a printer.
Local system configuration - Determine various aspects of the current
configuration of the local system involved with the operation of a
printer.
These "tasks" cover a large spectrum of requirements surrounding the
operation of a printer in a network environment. This list serves as
the basis for defining the various Role Models described below.
Proposed Role Models
Following is the list of "Role Models" used to evaluate the
requirements for any given Printer MIB object. Note that the keyword
enclosed in parentheses represents an abbreviation for the particular
Role Model in the matrix described later in this document.
User (USER) - A person or application that submits print jobs to the
printer; typically viewed as the "end user" within the overall
printing environment.
Bergman, et al. Standards Track [Page 163]

RFC 3805 Printer MIB v2 June 2004
Operator (OP) - A person responsible for maintaining a printer on a
day-to-day basis, including such tasks as filling empty media trays,
emptying full output trays, replacing toner cartridges, clearing
simple paper jams, etc.
Technician (TECH) - A person responsible for repairing a
malfunctioning printer, performing routine preventive maintenance,
and other tasks that typically require advanced training on the
printer internals. An example of a "technician" would be a
manufacturer's Field Service representative, or other person formally
trained by the manufacturer or similar representative.
System Manager (MGR) - A person responsible for configuration and
troubleshooting of components involved in the overall printing
environment, including printers, print queues and network
connectivity issues. This person is typically responsible for
ensuring the overall operational integrity of the print system
components, and is typically viewed as the central point of
coordination among all other Role Models.
Help Desk (HELP) - A person responsible for supporting Users in
their printing needs, including training Users and troubleshooting
Users' printing problems.
Asset Manager (AM) - A person responsible for managing an
organization's printing system assets (primarily printers). Such a
person needs to be able to identify and track the location of
printing assets on an ongoing basis.
Capacity Planner (CP) - A person responsible for tracking the usage
of printing resources on an ongoing basis for the purpose of planning
printer acquisitions and/or placement of printers based on usage
trends.
Installer (INST) - A person or application responsible for
installing or configuring printing system components on a local
system.
Accountant (ACCT) - A person responsible for tracking the usage of
printing resources on an ongoing basis for the purpose of charging
Users for resources used.
Matrix of Common Print System Tasks and Role Models
To better understand the relationship between the set of defined
"Common Print System Tasks" and the various "Role Models," the
following matrix is provided.
Bergman, et al. Standards Track [Page 164]

RFC 3805 Printer MIB v2 June 2004
It is important to recognize that many of the tasks will appear to be
applicable to many of the Role Models. However, when considering the
actual context of a task, it is very important to realize that often
the actual context of a task is such that the Role Model can change.
For example, it is obvious that a "System Manager" must be able to
submit print jobs to a printer; however, when submitting a print job,
a person identified as a "System Manager" is actually operating in
the context of a "User" in this case; hence, the requirement to
submit a print job is not listed as a requirement for a System
Manager.
Conversely, while a "User" must be able to remove a job previously
submitted to a printer, an "Operator" is often expected to be able to
remove any print job from any printer; hence, print job removal is a
(subtly different) requirement for both the "User" and "Operator"
Role Models.
Role Models
-----------
Requirement Area USER OP TECH MGR HELP AM CP INST ACCT
Print job status xx xx xx xx xx
Printer capabilities xx xx xx
Print job submission xx
Print job removal xx xx
Notification of events xx xx
Printer configuration xx xx
Printer consumables xx xx xx
Print job identification xx xx xx xx xx
Internal printer status xx xx xx
Printer identification xx xx xx xx xx xx xx
Printer location xx
Local system configuration xx xx
Appendix E - Overall Printer Status Table
The Status Table establishes a convention for the top 25 printer
errors. The table defines a suggested relationship between various
printer states and the variables Printer hrDeviceStatus,
hrPrinterStatus, hrPrinterDetectedErrorState, prtAlertGroup,
prtAlertCode and various sub-unit status variables (prtInputStatus,
prtOutputStatus, prtMarkerStatus, prtMediaPathStatus and
prtChannelStatus). This table is the recommended implementation of
these variables. It is provided to guide implementors of this MIB
and users of the MIB by providing a sample set of states and the
variable values that are expected to be produced as result of that
state. This information supplements that provided in Section
Bergman, et al. Standards Track [Page 165]

RFC 3805 Printer MIB v2 June 2004
2.2.13.2 "Overall Printer Status". This is not an exhaustive list
rather it is a guideline.
The definition of PrtSubUnitStatusTC specifies that SubUnitStatus is
an integer that is the sum of 5 distinct values/states: Availability,
Critical, Non-Critical, On-line and Transitioning. Thus when a non-
critical alert or alerts are present the values for Availability,
On-Line and Transitioning will be summed with the Non- Critical
Alerts (8) value.
The table was generated in landscape format and is located at
ftp://ftp.pwg.org/pub/pwg/pmp/contributions/Top25Errors.pdf.
Appendix F - Participants
The Printer MIB Working Group would like to extend a special thank
you to the following individuals that put forth a significant effort
to review this document and provide numerous suggestions for
improvement.
David Harrington - Enterasys Networks
Juergen Schoenwaelder - TU Braunschweig
Bert Wijnen - Lucent Technologies and IETF Op & Mngmt, Area Director
This version of the Printer MIB would not be possible without the
previous work that resulted in RFC 1759. The authors of the Printer
MIB version 2 would like to acknowledge the following individuals for
their efforts in developing the base for this document. A special
recognition is also extended to Steve Waldbusser, who provided
significant technical guidance in the development of the architecture
of the Printer MIB.
Joel Gyllenskog - Microworks
Tom Hastings - Xerox
Jay Martin - Underscore, Inc.
Ron Smith - Texas Instruments
Steve Waldbusser - Lucent Technologies
Don Wright - Lexmark
Steve Zilles - Adobe
The following people attended at least one meeting of the Printer MIB
Working Group for version 2; many attended most meetings.
Ron Bergman - Hitachi Printing Solutions
Luis Cubero - Hewlett-Packard
Jay Cummings - Novell
Andy Davidson - Tektronix
Lee Farrell - Canon
Bergman, et al. Standards Track [Page 166]

RFC 3805 Printer MIB v2 June 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bergman, et al. Standards Track [Page 171]