As printer speeds climb and finishing features become more common place, a MIB to configure and obtain status from the Finisher is a natural follow-on to the Printer MIB. The 3rd meeting of the PWG Finisher MIB working group was held in Maui, the last week of January, along with a series of other PWG meetings. The Finisher MIB is on 2nd pass, structurally. We are settling debates about finishing axis and coordinate systems and, for the sake of correlating with the submission process, have chosen a document based view (like DPA) over a bit more intuitive device description approach. The printer/finisher must, therefor, contain the intelligence to map finishing parameters (ex. which corner to staple) to it's own physical reality (feed direction, print orientation etc.) - just as it would for printing. I expect the FIN MIB project to last another 6 or 7 months. We are soliciting input regarding finishing attributes from finisher manufactures.
1. Should the Finisher MIB be registered, separately, in the PWG subtree or should it be an
extension of the Printer MIB?
The consensus of the group is to have the Finisher MIB as an extension to the Printer MIB.
We should maintain the structure in the format as currently presented, which is consistent
with the consensus, and change only if an objection is raised from the IETF.
2. All names in the FinDeviceTypeTC should be revised so that "Unit" does not appear. For example, change "StitchingUnit" to "Stitcher" and "FoldingUnit" to "Folder". This will be
more consistent (since some names were already listed without the "Unit" suffix, and will
also avoid confusion with the notion of units of measure which are treated elsewhere in the
MIB.
3. The enums commented out in FinSupplyTypeTC should be restored to form one large,
common list of Printer and Finisher supplies enums. Some Finishers will have marking
capability and, thus, share the printer supply enums. We can remove any that are not required, later.
4. Change the object name "finDeviceOperation" to "finDeviceType".
5. The "finFeatureOperation" object could be eliminated if "finFeatureIndex" was
"FinFeatureTypeTC". This would depend upon the desirability of having table entries for all
possible finisher functions. As currently defined, finFeatureIndex is independent of the
actual feature. It was agreed to retain the object as currently defined and presented.
6. Is "finDevicePresentOnOff" necessary? Since there is no table entry for devices which are
not present, what added value is derived from this object?
The object does allow an indication that a feature can be installed even though it is not current present. We agreed to keep the object.
7. "finDeviceDescription" was discussed as a standard (mandatory) device subunit at the LA
meeting. Placement in the optional, extended group, however, is consistent with the Printer
MIB Input and Output groups. It was agreed that this object is one of the more useful pieces
of information and should be mandatory. It is unfortunate that the Printer MIB treats
descriptions as optional.
8. "PrtInputTypeTC" should be used for the "finSupplyMediaInputType" enums.
9. "finSupplyMediaInputControlMode" (mapped to the Finisher MIB from LMO) does not seem applicable to the types of finishers we expect this MIB to cover. We agreed to remove this
object.
10. Alternatives to the using the "finSupplyMediaInputTable" were discussed but we agreed to
keep the table unless a better method is proposed. Since finishers may have media inputs of
their own, which do not feed the printers media path, finisher inputs will be described
separately form printer inputs and will not be part of the Printer MIB Input Group.
11. Stapling positions and finishing axis were discussed (again) and the paper presented by
Gary Padlipsky and Paul Gloger (Xerox) was reviewed. The majority of the debate centered around whether to build a conceptual model that is intuitive with respect to the finishing
device or, rather, to base the model within the context of the document, itself. Although this is a device management MIB, the resulting agreement favored the document approach. The
main reason for this decision is recognition of the role information from the Finisher MIB
will play in helping determine and describe finishing options during job submission. The
intent is to follow the DPA definition of reference edge and processing axis with offset
which we think is the same as what is currently presented in the MIB document. The DPA
specifications for finishing axis and operations needs to be reviewed more thoroughly to
assure we are in synch since we expect many finishing applications to base their approach
on DPA. Tom, Ron and Harry will work on this issue to resolve.
12. Finishing defaults should be described using DefVAL, like Tom did in the Job MIB.
13. For a look at the DMTF LMO MIF see http://www.dmtf.org/tech/apps.html
14. The finisher model was discussed (again) with an attempt to capture a diagram. Of course,
there's always that lovely IETF challenge of representing everything in TEXT! (Haven't they heard... a picture is worth 1000 words?).Thanks for this one, Ron!
+------+ +------+ +-----+ +------+
| | | | | | | |
+-------+ | +-----+ +------+ | +------+ +-----+ | +------+ |
| Input |-+ +------+| |Marker|-+ +------+| | Fin |-+ |Output|-+
| |===>| |+<==>| |<==>| |+==>| |==>| |
+-------+ +-+ +-+ +------+ +-+ +-+ +-----+ +------+
\ | || | || ||
\ | || | || ||
\ | || | || ||
+------+ | |+--------------------| || +----------+
| | | +---------------------+ || | Fin |-+
+-------+ | | Media Path |+ | Supplies | |
| Media |-+ +---------------------------+ +----------+ |
|(opt.) | | |
+-------+ +----------+
15. The Finisher Attribute group is designed to reflect the dynamic and unpredictable
configuration of Finishing devices. It is similar in nature to the Job MIB attribute table. This
table can also be used to convey constraints and limitations related to combinations of
finishing features. We have begun to define some attributes but would like help from
finishing vendors to check our coverage, terminology and accuracy. Some attributes we will
need to define better (and want to follow industry terminology on) are shape of hole, fold
direction, etc. The following attributes were discussed:
Attributes
Stitcher - see finStitchingTypeTC
binder - see finBinderTypeTC
slitter - see finSlitterTypeTC
Folder - define (FoldingTypeTC)
other
unknown
zFold (3)
halfFold(4)
letterFold(5)
Wrapper - define (WrappingTypeTC)
wrap(3)
shrinkWrap(4)
paperWrap(5)
punchHoleType - define (HoleTypeTC)
round
oblong
square
rectangular
star
oval ?
punchHoleSizeMaxDim
punchHoleSizeMinDim
punchPattern - define (punchPatternTypeTC)
3hole
2hole
4hole
19hole (for comb bindings)
20hole
trimmer ?
diecut ?
impress?
perforating?
separation cut ?
banding ?