Subject: Re: IPP> PMP> Re: JMP> JobStateValue

From: [email-masked] (Bill Wagner)
Date: 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 <[email-masked]> at Internet
Date:    5/9/97 10:50 AM

>>> Harry Lewis <[email-masked]> 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

---

From: Scott Isaacson <[email-masked]>
Date: Fri, 09 May 1997 11:51:14 -0600

>>> Bill Wagner <[email-masked]> 05/09 11:19 AM >>>

I agree that there can be many ways at getting at a piece of information -
SNMP GET, IPP query, PDL specific query, etc.  If they are all trying to get
the "same" peice of info, then the printer just has to implement it once and
support multiple views.  If we state that IPP requires one piece of info and
the Printer MIB requires something different, and they are closely related
semantically but just different enough that it requires the Printer to
implement two things, this would not good - think that we are all ok on
that.  

>     that administration is exactly the purpose of the MIB's. 

I was trying to make a distinction bewteen what an "administrator" does (in
the IPP requirements) document and what a "manager" does.  I often use these
terms almost interchangeable, but sometimes I try to make a clear
distinction.

If an adminstrator does things like:
    - create a new "printer"  (name it, advertise it, register it, etc)
    - set access control rights
    - define the authentication and other security mechanisms
    - configure it to service one or more channels
    -  etc.
how would SNMP and MIBs help with that?
     
>     non-trivial functionality.
     
I really did not mean to imply that IPP should be used for device
management.  Thanks for clarifying.  The end user only needs to know about
Printer status in order to make job submission decisions.  I DO NOT see IPP
as encompassing  the MIB scope.

Sorry if I caused confusion.
Scott