Wagner,William (bwagner at digprod.com) wrote:
>The "design goals" indicated that management aspects were excluded in
>Version 1.0; this does not mean that there was ever any decision to include
>them in a later version. Indeed, one of the reasons management was "put
>aside" was that there was no consensus about what level of management was
>appropriate to IPP. There was substantial concern on the part of those
>familiar with the printer MIB that yet another device management path was
>not a good idea.
>>Indeed, the types of management functions identified in the "goals" are not
>device management but deal more with the logical printer, jobs, and who has
>authority to do what. These are quite different from capabilities like
>"shut-down printer".
>>To agree with adding such inappropriate capabilities for the sake of keeping
>things going merely sanctifies the idea that IPP should be a management as
>well as submission protocol, which is just not reasonable. The idea of
>providing the capability for someone to shut down my printer over the
>internet does not strike me as a desirable feature.
>How would SNMP be more secure than IPP in this scenario? Or are you saying that
this kind of operation shouldn't be allowed at all over a network? Are you
worried that TLS (including X.509 certificates, etc.) is not secure enough for
this application?
In some environments (e.g., statements printing), the printers actually have
operators: people whose job it is to run printers all day. For these
operators, being able to perform operations like Pause-Printer, Resume-Printer,
Purge-Jobs, Shutdown-Printer, Enable-Printer, Disable-Printer, Space-Printer,
etc., is just as important as being able to submit jobs. But these operators
have NO interest in being able to, say, manage the site's network routers using
the same tool they use to operate the printers.
>The Printer MIB has been updated. If, based on several years of SNMP based
>printer management experience, additional device control features were
>necessary, why were they not introduced as Printer MIB capabilities?
>
I think what happened in reality is that everyone who needed this kind of
functionality went off and invented unique, proprietary protocols. That's what
were trying to move away from. But if we're the only ones who need these
extensions, we can do them as private extensions. I just wanted to get the
things registered so that we avoid any future conflicts over operation numbers
or attribute names.
-Carl