Thank you for reviewing the Finisher MIB draft. Your comments will
certainly help to improve this document.
I have attached some additional comments and explaination with your text.
Ron Bergman
Dataproducts Corp.
On Mon, 23 Feb 1998, Caruso, Angelo wrote:
> Since I won't be in Austin, here are my comments on the latest finisher
> mib draft, dated 19 February 1998.
>
> 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???
>
The idea here is to provide attributes, instead of unique objects, for
information that is unique for a finisher device. This is the method used
in the Job MIB to minimize the number of objects.
For your example, see FinStitchingTypeTC for the information provided.
Also, see the Attribute Table for the objects that are encoded with this
information.
The Attributes section still needs a significant amount of work. Anyone
that wouls like to make a contribution here, please do!
> 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.
>
Thank you for catching this! I was interrupted in this middle of revising
this section and really botched this up. Not only are the 3 TCs repeated,
but I did not add 4 TCs discussed in Maui. The 4 are FinFoldingTypeTC,
FinWrappingTypeTC, FinPunchHoleTypeTC, and FinPunchPatternTypeTC. I will
update this prior to the meeting next week.
> 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.
>
This was patterned after the Printer MIB, since it is intended that the
Finisher MIB be combined into the Printer MIB, someday. I was not aware
that this is incorrect MIB design. So, should we match the format of the
Printer MIB and, if the documents are eventually integrated, they are
uniform? Or, do we follow your proposed structure? What about SNMPv1
compatibility with Augmenting?
I will add this as an issue and request comments.
> 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???
>
This is a good point. I will include this change unless there is an
objection.
> 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.
>
This is another good item for discussion! By making a unique table it is
obvious that these inputs are not used by the marking subunit.
But I do not believe that hrDeviceIndex is a good differentiator. Our
model describes the finisher subunits as a part of the printer and
thus the same hrDeviceIndex applies.
I will add this as an issue. Does anyone have a good suggestion as how
this can be implemented?
> 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
>
>