Hi Ira,
At the last concall we had discussed making a point of the distinction
between Power State and Operational State. Certainly, power consumption will
be a function of both Power State and Operational State. And there will be
some restriction on allowable Operational State depending upon power state.
It may not be possible to define a clear or device-independent relationship
between the two types of states.
As I reviewed the power states in the MIB (PowPowerStateTC), some questions
come up on what states are reportable and what are selectable, as well as
what may be considered not power states (although I understand that these
states are derived from other standards)
1. I was assuming that any of the listed states could be a response, but
that only what have been elsewhere identified as "Stable" states could be
used in a request. This followed from an understanding that the non-stable
states were transition power states, and one would typically request the
desired end state, not a transition state. But one may want to request how
the desired end state is reached, so that requesting "off","offGraceful",
"offHard", or "offHardGraceful" would reasonable be desirable different
requests. Is it your understanding that any of the listed power states
could be used in a request (although I would wonder about resetNMI) ?
2. If this is so, then can the reset states be requested? One may
consider that the various resets are operational rather than power
transition states. That is, although there may be an effect upon power
consumption by a reset as there is when going from Idle to Busy, a reset
would typically occur for operational rather than for power purposes. Is the
Power MIB to also expand the capability for what are really operational
resets?
3. If, as it appears, the Power states other that the six "stable"
states are transitory but not transition states, what should be reported
when the device is in transition between two stable states? Or are we not
concerned with what would normally be a relatively short duration transition
state?
4. The offHard state is defined as "mechanical unplug", which suggests
that it cannot be either reported nor requested, rendering it useless and
eliminating the availability of a not-powered state (since "off" is "flea
power") . I expect that offHard really means unpowered, whether the
disconnect is by pulling a plug, opening relay contacts or shutting off a
Triac. If so suggest that unpowered is preferable to mechanical unplug.
Similarly, associating the "off" state with "flea power" is not very
informative, particularly for non-English speakers. Is the implication that
enough of the unit powered so that a remote command (from some source) can
be accepted? (one would assume that, if the agent is sufficiently powered to
response to a status request, it is sufficiently powered to accept a
state-change request).
Again, I understand that these states are inherited and should be supported
for consistency. However, I think that more explanation of how they apply to
hardcopy equipment may be appropriate to encourage consistency in
implementation.
Thanks,
Bill Wagner
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/wims/attachments/20100122/eeeb0345/attachment-0001.html>