Hi Thomas,
Nice to hear from you! My replies inline below.
Cheers,
- Ira (co-editor of Finisher MIB)
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: Silver, Thomas [mailto:Thomas.Silver at xerox.com]
Sent: Tuesday, September 20, 2005 11:26 AM
To: ron.bergman at hitachi-ps.us; harryl at us.ibm.com; imcdonald at sharplabs.com;
waldbusser at ins.com
Cc: fin at pwg.org; hostmib at andrew.cmu.edu
Subject: Finisher MIB-related questions
Hi folks,
The Finisher MIB does not appear to provide enough guidance related to the
indexing of the 'finDeviceTable'. Specifically:
(1) Should the 'hrDeviceIndex' value of 'hrDevicePrinter' be used when
referencing the various Finisher MIB tables?
-- the closest evidence that I've found is on page 14 within "5. The
Attribute Mechanism" section which provides the following statements:
"1. hrDeviceIndex - which device in the host"
"2. finDeviceIndex - which finisher subunit in the printer
device"
Can I assume that the "...printer device..." text in item 2 means
that the 'hrDeviceIndex' has to be 'hrDevicePrinter'?
<ira>
The Finisher MIB MUST be implemented along with the Printer MIB v2
(doesn't work with Printer MIB v1), because the Finisher MIB
depends on object groups in the Printer MIB v2 (General and
Localization for the locale of description strings, Alert for
finisher warnings/errors, etc.).
The value of 'hrDeviceIndex' used to access an instance of the
Finisher MIB MUST be of type 'hrDevicePrinter', or the Finisher
MIB doesn't work at all.
</ira>
(2) Why doesn't RFC 2790 define a device type for the finisher? (e.g.
'hrDeviceFinisher') I know this may seem a bit unusual but does it make any
sense to create a new 'hrDeviceType' enums for common finisher hardware
modules to reference the Finisher MIB-related tables? (e.g.
'hrDeviceBookletMakerFinisher', 'hrDeviceInsertionFinisher',
'hrDeviceMultiPurposeFinisher', 'hrDeviceStaplerFinisher', etc.)
Just a few thoughts to consider:
-- 'hrDeviceDescr' can be used to identify the optional finishing
hardware modules more efficiently than those queries required to retrieve
'deviceName(3)', 'deviceVendorName(4)', 'deviceModel(5)', and perhaps
'deviceVersion(6)' attributes
-- 'hrDeviceErrors' can be used to track individual finishing
hardware module faults separate from the printer
-- 'hrDeviceStatus' can be used to show which finisher module is
down for fault isolation purposes
-- etc.
<ira>
Bad idea - see (1) above for why this won't work.
</ira>
(3) How can an asset management app easily track these different, optional
finishing hardware modules without having to make numerous queries to the
device? The concern I have is the amount of network traffic and time that is
required to discover the finisher capabilities provided by a network
printer. Furthermore, some production equipment can contain multiple,
optional finishing hardware modules that can be linked together. These
optional finishing hardware modules can be provided by the same and/or
different multiple vendors I'm told. Seems to me that lumping everything
into the 'hrDevicePrinter' type may not enable the operability to be
optimized between network printers and mgmt apps....
I look forward to any guidance you can provide. Thanks for your time and
consideration w/ this matter,
Tom :-)
<ira>
See my reply to (1) above - you can't get there from here.
</ira>
----------------------------------------------------------------------------
-----------
Device Compliance, Solutions, & Systems Engineering Mgr.
Xerox Office Services Development
Xerox Global Services
800 Phillips Road
MS 111-02J
Webster, NY 14580
thomas.silver at xerox.com
8*222-7219 / 585-422-7219