>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.
You make a good point, but I wonder just how (relatively) heavy it is?
HP can correct me if I'm wrong, but I think every Mopier and/or 5si
driver that installs out there today brings in an SNMP stack (at least I
saw some SNMP related file names flash by as I was loading the Mopier
Driver onto my w95 client). IBM's drivers do the same. Lexmark's drivers
might not load SNMP on the client but they have to load NPAP. Is IPP really
going to lighten the load?
>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.
You really can't say the Job MIB is oriented toward device mgt. It's Job
all the way and heavily oriented to end-users.
>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.
No argument here! I think the PWG will have failed if there is no conformance.
Scott, I do follow your main point (I think) and that is that every client will
naturally have HTTP and every Administrator will most likely have SNMP. And,
since there is overlap between end-user and admin (printing) functions, we can't
really have two distinct architectures. It's not hard for me to imaging a future
devoid of SNMP and everything happening "on the web"... but, as we get carried
away with this idea... we at least have to realize that IPP can't really seem
to agree on whether HTTP is really the right protocol and printers have already
implemented the Printer MIB and some will most likely also embrace the Job MIB
(after all... Job MIB hasn't been dropped from the PWG venue, even though IPP
is now some 8 or so months old).
Another way to imagine the future is one where a standard IPP (non-HTTP,
perhaps)
protocol exists for print submission and the SNMP Printer and Job MIBs
facilitate
status and configuration of the printer and job.
Harry Lewis