I don't know if our controller developers are unique in the sense that
they are *very* leery about having a remote "kill switch" that
can be invoked instantaneously, thus upsetting things in the midst of
a print job and, if taken to the limit, even resulting in jams.
I don't think we every defined the semantic for WHEN the Reset should
take place or even the reason for having a remote reset.
One reason which has been talked about is that if the printer is "hung"
the remote operator can cause a reset. How likely is this? If the
controller is hung and the SNMP agent is in the controller, it's likely
to be hung too. If the SNMP agent is in the NIC, the interface between
Controller and NIC could very possibly be unresponsive.
I see a valuable use for administratively taking the printer offline or
otherwise locking the op panel, loading some code then causing a reset
to bootstrap things. But no-one would derive that from our description.
Do others think it would be valuable to derive the current state of affairs
regarding RESET during interoperability test?
Harry Lewis