IPP Mail Archive: Re: IPP> PMP> Re: JMP> JobStateValue

Re: IPP> PMP> Re: JMP> JobStateValue

Bill Wagner (bwagner@digprod.com)
Fri, 9 May 1997 13:19:50 -0400

Scott,

When we agonize about IPP disregarding the MIB's, it is not SNMP that
is the question but rather the parameters used in IPP versus those in
the MIB's. There is nothing to say that the MIB objects need only be
accessible via SNMP. It is indeed things such as "consistency between
job attributes in the Job Monitoring MIB and IPP and printer
attributes in the Printer MIB and IPP" that is the point of concern."

Your opinion that "For administrative requirements, I don't see the
MIBs being involved very much." is very interesting in that I believe
that administration is exactly the purpose of the MIB's.

To suggest that IPP should be a more universal solution handling
device management as well as job submission may not be to the
advantage of IPP either, since it burdens IPP with an additional,
non-trivial functionality.

Bill Wagner, Osicom/DPI



______________________________ Reply Separator
_________________________________
Subject: IPP> PMP> Re: JMP> JobStateValue
Author: Scott Isaacson <SISAACSON@novell.com> at Internet
Date: 5/9/97 10:50 AM

>>> Harry Lewis <harryl@us.ibm.com> 05/09 10:04 AM >>>
> Thank you, Jay! I've tried to point this out several times in the past.
> The PWG is not working together in this vein. IPP has taken an all
> encompassing approach, basically ignoring the fact that printer
> configuration and status can be handled via the printer MIB - a standard
> which is already implemented in at least 6 vendors printers and has the
> support of several printer management software products.
>
> IPP as a standard job submission protocol is a great idea. I guess there
> is nothing wrong with also making it an all encompassing status and
> configuration protocol... but, at least, we should be doing some sort
> of mapping back to the Printer and Job MIBs.

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