Angelo,
>>> "Caruso, Angelo " <Angelo.Caruso at usa.xerox.com> 04/27 8:49 AM >>>
>Perhaps someone would please enlighten me as to why we need to build =
Printer
>MIB OID access into IPP. I thought the intent was to extend the IPP
>attribute list to eventually cover all the printer MIB stuff. Why is this =
so
>difficult?
In the original "Sub-Units" proposal that I presented in Portland, I =
showed a
mapping from MIB OIDs to IPP attribute names. It not really a complete =
mapping,=20
but examples and some rules of how to complete the mapping. =20
This seemed simple enough to me. This is the direction that I thought we =
were
going.
Some of the comments on the proposal during the meeting were:
1. Since an implementation of IPP with Printer MIB sub-unit support will =
most likely
be co-resident with a Printer MIB agent which already names things with =
OIDs,
it would be a waste of resources to require that implementation and agent
to translate back and forth between strings and OIDs. So, in order to=20
"extend the IPP attribute list to eventually cover all the printer MIB =
stuff." the
thought process was to name the new attributes by their stringified OIDs
rather than some arbtrary symbolic name
2. The discussion seems to be focused on now "how hard can it be" but "is =
it
necessary" since we already have SNMP.
3. If we stick with arbitrary new strings for attributes, it might be =
harder to get at
other MIBs using the same mechanism without a full mapping document. For =
example,
the Finishing MIB. If we just go with stringified OIDs we can easily =
extend that to any
MIB object OID without having to show a mapping to the IPP attribute name.
These are just the thoughts behind the disucsisons that I have heard.
Scott