Hi Bill,
Thanks for catching my mistaken comment.
I intended that PowerStateMessage be kept ONLY
in the base PowerMonitor group - far from being a
single message, it may include information about
how the current power state was entered, about
power usage in watts, and any other relevant
*power-related* information
As such, it corresponds to the use in some products
of the Printer MIB prtAlertDescription (i.e., it is NOT
limited to be just a human-readable name of the state).
Re PowerStateMessage 'Ready' not saying paper out:
No, the PowerStateMessage must NOT reflect that
kind of information. The top-level System or Subunit
state message (e.g., SystemStatus. StateMessage)
is the only suitable place for such information.
Power State does NOT equal overal System/Subunit
operational state - OK?
Re PowerState rollup from Subunits to System:
After looking at real product implementations
and some offline discussions, it's clear to me
that PowerState of Subunits MUST NOT be
rolled up or have any other affect on reported
PowerState of the System - they are wholly
separate.
However, the System *operation* to change
overall PowerState SHOULD be propagated
down to subordinate hardware Subunits (in
order to avoid surprising the user) - similar to
IPP admin operation fan-out in RFC 3998.
Re PowerMode as a Capabilites group:
Yes, PowerMode is the supported power states
on the System or Subunit - as it says on line
605 of the current draft - I can reiterate that
higher in the group description (line 599).
We can also rename the PowerMode group -
if we can think of a single, alternate word for
Mode - what about PowerChoice?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 4983
906-494-2434
On Thu, Sep 24, 2009 at 1:56 PM, William Wagner <wamwagner at comcast.net> wrote:
> Ira,
>> Certainly a significant simplification. Thank you. We will see what the
> response is.
>> Question: You state:
> delete PowerStateMessage from PowerLog (redundant w/ PowerMonitor)
> and
> delete PowerStateMessage from PowerMode (redundant w/ PowerLog)
>> I am not sure of your intent (nor perhaps of several other things)
>> With regard to PowerStateMessage, is this just a localized string defining
> the current power state and for which there is just one message per
> enumerated power state? That is, is it just a manufacturer specified name
> for the enumerated power state? I wonder at the example given in 5.3.1,
> where the PowerOn state has a message of "Ready". I would expect that you
> may have a PowerOn state where, because of no paper for example, the device
> is not Ready.
>> If PowerMode is a table of all power states supported by the device (these
> seems the case since it is a table under capabilities, although this is not
> specifically stated) and PowerStateMessage is a manufacturer determined
> localized Power State Name, it might reasonable to provide the enum/name
> information in PowerMode. If PowerStateMessage for each powerstate may be
> one of several messages providing additional information about the power
> state, or how the device got there, or that it was someplace in the timeout
> going to a different power state, or whatever, then it may be more difficult
> to provide an enum to message set entry.
>> Thanks,
>> Bill Wagner
>>> -----Original Message-----
> From: wims-bounces at pwg.org [mailto:wims-bounces at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Wednesday, September 23, 2009 1:34 PM
> To: wims at pwg.org; Ira McDonald
> Subject: [WIMS] URGENT - simpler Power classes - please reply ASAP
>> Hi, Wednesday (23 September 2009)
>> For review at our next WIMS WG teleconference on Monday (28 September).
>> Below are some simplifications for my next draft of Power Management
> Model - please read and reply ASAP - thanks.
>> New conformance packages are TBD, after further discussion.
>> FAIR WARNING - In the absence of any protests, I will make ALL of these
> changes in my next draft of Power Management Model (except perhaps the
> PowerPolicy breakdown into 3 new simpler policy groups).
>>> PowerMonitor (REQUIRED)
> - keep PowerState (single-access read of state is a base requirement)
> - keep PowerStateMessage (only localized state message - see below)
> - delete MonitorID (only one instance allowed per System/Subunit object)
> - delete PowerStateTimestamp (redundant w/ PowerLog)
> - delete LastLogID (not useful, per Mike Fenelon)
>>> PowerLog (OPTIONAL)
> - keep LogID (key)
> - keep PowerState and PowerStateTimestamp (machine-readable)
> - delete PowerStateMessage (redundant w/ PowerMonitor)
> - delete LogPolicyID (not useful, per Ira)
>>> PowerMode (OPTIONAL)
> - keep PowerState (key)
> - keep PowerUsageWatts (per Power Mgmt Project charter)
> - keep IsAcceptingJobs, IsProcessingJobs, IsValidRequestPowerState
> (per Power Mgmt Project charter - but rename for clarity)
> - delete PowerStateMessage (redundant w/ PowerLog)
>>> PowerTransition (OPTIONAL)
> - keep StatePowerState and EndPowerState (keys)
> - keep StateChangeSeconds (per Power Mgmt Project charter)
>>> PowerPolicy (OPTIONAL)
> - maybe divide up into 3 simpler policy groups (see below)
> - delete PolicyTotalTriggers (overkill, though CIM supported)
> - delete PolicyLastTriggerTimestamp (overkill, though CIM supported)
>>> PowerRequest (OPTIONAL)
> - keep RequestPowerState (read-write)
> - keep RequestStatus (machine-readable)
> - keep RequestStatusMessage (human-readable status message)
> - delete RequestID (only one instance allowed per System/Subunit object)
> - delete StartRequestTimestamp, EndRequestTimestamp (see PowerLog)
>>> NEW - possible breakdown of PowerPolicy for simpler implementations
>> PowerTimeout (OPTIONAL)
> - TimeoutID (key)
> - TimeoutRequestPowerState (requested new state on timeout trigger)
> - TimeoutStartPowerState (optional starting state, e.g., 'On')
> - TimeoutPredicate (for activity versus inactivity)
> - TimeoutSeconds (actual interval)
>> PowerCalendar (OPTIONAL)
> - CalendarID (key)
> - CalendarRequestPowerState (requested new state on calendar trigger)
> - CalendarIsOnetime (recurring versus one-time calendar triggers)
> - CalendarWeekday
> - CalendarMonth
> - CalendarDay
> - CalendarHour
> - CalendarMinute
>> PowerEvent (OPTIONAL)
> - EventID (key)
> - EventRequestPowerState (requested new state on event trigger)
> - EventName (trigger event name)
>>> NOTE - DMTF CIM and OASIS standards both depend on IETF Schedule MIB
> (along with all IETF System Policy standards), so I'm very strongly
> opposed to changing Calendar elements to be incompatible.
>> Comments?
>> Cheers,
> - Ira (Power Management editor)
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic at gmail.com> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> _______________________________________________
> wims mailing list
>wims at pwg.org>https://www.pwg.org/mailman/listinfo/wims>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.