Tom,
To further expound on my previous e-mail, unless I am missing something
just defining one new object will not fix the localization problems
in the Printer MIB. I will attempt to summarize my current position.
There are 5 types of objects in the Printer MIB where localization
may apply.
1. Objects covered by prtConsoleLocalization
2. Objects covered by prtGeneralCurrentLocalization
3. Objects that are written to and read back by an SNMP
management application, objects such as prtGeneralCurrentOperator.
4. Objects that are read-only strings that are strictly determined
by the printer, objects such as prtCoverDescription.
5. Objects that are Printer MIB read-only strings but are copied by the
printer from variables set by a non-SNMP host, objects such as
NDSP Server name from prtChannelInformation.
I think we have adequately covered type 1 and 2 objects from a
localization perspective. I think we decided some time back that we were
going to ignore the localization problems in type 3 objects. If I
understand
your proposal correctly, you are attempting to define the localization
of objects that fall in type 4 and 5 categories by using just one variable.
I do not think this is possible to do because they can be localized by
two different sources. Objects in category 4 are determined by the printer
and objects in category 5 are determined by a non-SNMP host.
I think the time has come (it may already be past due) for Chris and myself
to edict what is the consensus of the working group. I am not sure that we
are ever going to reach a true consensus on this issue from the working
group. I'll give the group some time (maybe only a few hours) to respond
to Tom's latest proposal and this e-mail before talking to Chris and
deciding
what we need to do.
Regards,
Lloyd Young