Paul,
This attribute was originally an optional object and was moved to
eliminate all optional objects. Experience with the Printer MIB shows
that few vendors implement optional objects. Also the IETF does not
approved of optional objects in MIBs.
It was also agreed that even in cases where the finisher unit was not
manufactured by the selling vendor, it would normally be represented as
the selling vendors equipment. Therefore, the need for the vendor name as
an object was minimal. (As you also pointed out in your third paragraph.)
So the real reason was not to allow it to be unique for each finisher
function, but to minimize its presence.
Ron Bergman
On Thu, 12 Nov 1998, Henerlau, Paul wrote:
>> Ron -
>> As we are putting the finishing touches on the
> code for the various MIBS we are supporting on
> our printer, we came across a small point in the
> Finishing MIB, which we wished to bring to your
> attention.
>> Specifically, we were addressing those areas
> in the mandatory Finisher groups, and noticed that
> the deviceVendorName was not part of the
> finDeviceTable, but rather to be found as a finDeviceAttribute.
>> This caused us to puzzle a bit, as we could not
> imagine any situation wherein a given finisher might
> have different vendors for its functions. These typically
> come together as an ensemble of functions provided
> by a single vendor [say, in our case stitching and
> stacking].
>> Was this the intended design? Was there a particular
> motivation for this approach? As a suggestion, should
> you open the draft document again, you might want
> to consider promoting the finDeviceAttributeDeviceVendorName
> to simply finDeviceVendorName.
>> Thoughts?
>> -- Paul Henerlau
>> [henerlau at sharplabs.com]
>>>>>>>>