Pages 6-7:
It is not very clear how these attributes are to be used. For example,
stitchingType(3), an INTEGER, provides additional information regarding
the stitching operation. What sort of additional information is being
provided, and how exactly will it be encoded as an integer???
Pages 10-11:
In the textual conventions section, several of the textual conventions
have been repeated (i.e. FinStitchingTypeTC, FinBindingTypeTC, and
FinSlittingTypeTC). I assume this is a simple cut and paste error.
Pages 14-15:
The optional Extended Finisher Device Group should be defined as a NEW
table that AUGMENTS the Finisher Device Group table. The printer MIB is
the only MIB I know of that defines subsets of an ENTRY sequence as
optional. This is incorrect MIB design, and we should not repeat this
error this just because it was done in the printer MIB.
Page 15-16 & 18-19:
The indexing schema for finisher supplies is different than that used
for marker supplies in the printer MIB. This results in tables with 3
and 4 indices! In the printer MIB, the marker supplies and marker
colorant tables contained a reference index to the corresponding marker
subunit, and therefore, those tables only needed two indices. Do we
really want a table with four indices here???
And, for that matter, the Finisher Supply Media Input Group, from what I
can tell, is more or less an exact copy of the Printer Input Group. Why
can't we use the input group from the printer MIB for finishers too? A
simple cross reference table (AUGMENTing the Input table, for example)
could be used to associate rows in the printer input table with specific
finisher subunits. Another approach would be to state that finishers
must always use a different hrDeviceIndex than printers. Then, it would
be obvious which rows in the input table are associated with the
finisher based on hrDeviceIndex.
Pages 21-23:
Same comments as Pages14-15, there are two more optional groups defined
here. These should be defined as NEW tables that AUGMENT the Finisher
Supply Media Input Group table.
Thanks,
Angelo