>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 at=
tribute
list to eventually cover all the printer MIB stuff. >Why is this so dif=
ficult?
If we would accept SNMP (v3 perhaps) as the secondary channel between S=
erver
and Device we wouldn't have to map OID's to IPP at all. The main convin=
cing
argument (aside from "don't like it") I've heard against this is the de=
sire to
have one solution for network and local attachments. Tail wagging dog, =
but
still, a valid argument.
Once we get to designing a single protocol for submission and monitorin=
g, we
wish to maintain use of the MIB datastructures which are already in the=
device
for management purposes. Thus, we might want to extend the IPP attribut=
e list
to cover all the printer MIB objects, as you suggest. However, it has b=
een
observed that every printer MIB OID already has a unique, fairly terse =
"OID
stub" (the unique part, not the fully qualified OID). Since a lot of ef=
fort
goes into efficient use of controller MIPs, why make the device parse t=
he
longer IPP attribute strings when any IPP application can do the matchi=
ng for
human consumption?
Harry Lewis - IBM Printing Systems
=