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.
>
> 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.
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?
> 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.
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