Regarding the question about the different MIB-WALK implementations of
prtStorageRefTable :
> > I looked at the Interop mib walk test results. Vendor 2 has 2 storage
> devices
> > and they use prtStorageRefIndex.1.1 and prtStorageIndex.2.2. Vendor 4 has
4
> > devices,
> > with prtStorageRefIndex.1.1, .2.1, .3.1 and .4.1. Which of these is more
> > correct?
I think it's very clear that vendor 2 (it's not too difficult to guess who it
is) has wrong implementation. And we should urge them to fix it. The reasons
are :
1. RFC1759 says the prtStorageRefSeqNumber is "unique amongst all the entries
with a common value of hrStorageIndex". This means it's sub-index in
prtStorageRefTable. Since it's an index itself, it should start with 1, not 2.
2. It doesn't make sense to have two duplicated indexes in a single table. If
two indexes are having the same value, there should only be one index in the
table.
Regarding the implementation issues for prtStorageRefTable and
prtDeviceRefTable in multiple printer environment, I believe the interpretation
I made on March 6th email is the most reasonable and clear. Since we haven't
heard any objections from any company for the past five days, EFI will be the
first one to use this table in this way (unless any objection comes out after
this email).
So, the only suggestion I have is we should include an example in the next
printer mib RFC to explain prtStorageRefTable and prtDeviceRefTable, so it will
not be ambiguous to the future implementors.
I am pretty new to the PWG mail list and if I violated any traditions or
unspoken rules in the group, please accept my appology.
Eugene
--
_____________________________________________________________
Eugene Chen Sr. Software Engineer, Networking.
-------------------------------------------------------------
DIR:(415) 286-8372 Electronics for Imaging, Inc.
OPER:(415) 286-8600 2855 Campus Drive
email:Eugene.Chen@eng.efi.com San Mateo, CA 94403