Harry,
I have thought some about this - "Why not let IPP just be job submission and
do a better job of integrate the end user's client software with the Job MIB
and Printer MIB for job and printer status.?" I keep coming back to one
main thought:
I do not envision a SNMP stack on every end user client. It seems to heavy
weight for me. I see SNMP enable apps on every manager/operator client, but
that is typically a different configuration.
I say let the MIBs stay on the course they are on, which is a good one in my
view, because they are oriented towards "print device management". There
is a big difference between "printing system management" and "print device
management." There is some overlap between the two, but let IPP (non-SNMP
based at all) be a full solution for the end user even when the end user
starts to take on the role of a "jr. manager" their own jobs and devices
in order to make job submission decisions. These are all printing system
kinds of things, not just device kinds of things.
Since there is overlap, there must be (SHALL be to use better conformance
language) consistency between job attributes in the Job Monitoring MIB and
IPP and printer attributes in the Printer MIB and IPP.
In the IPP requirements we say only a subset of the end user requirements
are satisfied in V1.0. I expect much better integration (and less overlap)
with the MIBs when we talk about solving the manager requirements. For
administrative requirements, I don't see the MIBs being involved very much.
Scott