[WIMS] Draft of Charter of WIMS Power Mgmt Project

[WIMS] Draft of Charter of WIMS Power Mgmt Project

[WIMS] Draft of Charter of WIMS Power Mgmt Project

Ira McDonald blueroofmusic at gmail.com
Mon May 11 23:45:48 UTC 2009


Hi Harry,

I think we generally agree that knowing that
a Marker (for example) has to be in the CIM
power state "On" (i.e., ACPI state G0 or S0)
to be immediately operational should be a
part of the PWG standard.

Likewise the difference (in RELATIVE warm-up
time) between the two CIM power states:

"Sleep-Soft" (Standby - ACPI S1 or S2)
"Sleep-Deep" (Suspend - ACPI S3)

Allowing vendor-unique primary power states
(not defined in CIM and ACPI) would be very
bad for interoperability.

Allowing a separate power substate attribute
would be OK - though perhaps confusing to
real customers - certainly not interoperable.

Certainly a power state message attribute
should be as explicit as possible for the
end user.

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 49839
 906-494-2434

On Mon, May 11, 2009 at 7:12 PM, Harry Lewis <harry.lewis at infoprint.com>wrote:

>
> Thanks Bill and Ira.
>
> To be clear, I am not suggesting defining any new power states. The
> question is whether or not the PWG WIMS-POW effort will document a MAPPING
> or INTERPRETATION of EXISTING power states.  As Bill indicates, probably no
> need to get to this level of detail in the project statement.
>
> Regards,
> Harry
> *
> Harry Lewis*
> Program Manager - Intellectual Property & Open Standards
> Phone: 720-663-3456
> e-mail: harry.lewis at infoprint.com
> infoprint.com <http://www.infoprint.com/>
>
>
> P Think before you print
>
>
>  *"William Wagner" <wamwagner at comcast.net>*
> Sent by: wims-bounces at pwg.org
>
> 05/11/2009 04:16 PM
>   To
> <wims at pwg.org>  cc
>   Subject
> RE: [WIMS] Draft of Charter of WIMS Power Mgmt Project
>
>
>
>
> Ira et al,
>
> Thank you for your suggestions. My thoughts on the subject:
>
> 1.     Although a project statement is necessary for with Power Management
> effort, I do not think that a charter is. My plan was to pass a project
> statement past the working group and the SC for comment, but not to go
> through a charter process.
> 2.     Similar to what was done for other projects, I will create a new
> subdirectory under WIMS, but no new mailing list. I intend to place the
> existing power management information and the project statement in this
> directory, as well as non-specification draft documents. Working Draft
> documents for this effort will go under the WIMS/WD directory. But quite
> frankly, I foresee most of the immediate term effort being in gathering and
> documenting information of requirements and constraints rather than coming
> out with spec drafts.
> 3.     Addressing Harry’s question, I will try to make the “out of scope”
> area clearer and less restrictive.  At this point, I do not want to
>  prejudge what we want to do without better understanding of both
> user/administrator and manufacturer viewpoints.
> a.     In general, adding power state definitions beyond what is in ACPI is
> out of scope, although I would not immediately preclude providing for
> manufacturer defined sub-states. That is, the state must be one of the
> standard ones; but we may want to allow for a manufacturer to provide more
> details so he could effectively identify  more detailed sub states to an
> application which understands them.
> b.    Regardless, we certainly need to address how the standard states
> apply to  imaging devices in such a way that an identified state has a
> consistent meaning across all products. Determining just what this meaning
> is will be a major task. It is not immediately clear to me that there is an
> absolute power-range  level associate with each state rather than a relative
> level or other aspects such as the ACPI Global state definitions include;
> e.g., , the latency from external events to application response,  reboot
> require, safe to disassemble  etc.
> c.     We touched upon whether we will identify power states for just
> systems, or subunits or a services or some combination. Ira suggested that
> we start with systems (which I am included to agree with)) and absolutely
> avoid Services (which I am not so definite about). If at all possible, we
> need to get user/administrator input, and we may find that although users
> think in terms Devices (Fax, Scanner, Printer), when dealing with an MFD,
> they are really concerned with Services. At this point, I think we need to
> listen more than dictate.
> d.    Although it may be obvious, developing a protocol is out of scope and
> tying the elements to a specific protocol is to be avoided. We recognize
> that defining a working binding is necessary for prototype, and the obvious
> choice at this point is SNMP. Nor do I believe that just mapping to a
> binding is a valid prototype of the elements spec.  But the Power Management
> Elements Spec should be protocol agnostic.
>
> Thanks,
>
> Bill Wagner
>
>
>
>
> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com] *
> Sent:* Monday, May 11, 2009 5:01 PM*
> To:* Harry Lewis; Ira McDonald*
> Cc:* William Wagner; wims at pwg.org*
> Subject:* Re: [WIMS] Draft of Charter of WIMS Power Mgmt Project
>
> Hi Harry,
>
> Thanks for the comments - my replies are inline below.
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: *blueroofmusic at gmail.com* <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
>
> On Mon, May 11, 2009 at 4:44 PM, Harry Lewis <*harry.lewis at infoprint.com*<harry.lewis at infoprint.com>>
> wrote:
>
> Ira, great start! Couple observations.
>
> 1. As written, adding or changing power state definitions is out of scope.
> Should the objectives include "interpretation" or mapping of defined power
> states as they relate to imaging devices?
>  - For example - are we going to standardize which "power level" relates to
> fuser or scanner lamp readiness etc?
>
> <ira>
> My two cents.
>
> There was strong concensus at the last two face-to-face BOFs
> NOT to allow any but standard (CIM/ACPI) or vendor-defined
> power states - no site-defined power states - however, each
> power state should have an attribute for power consumption
> (in watts) - ACPI and CIM do NOT manage the absolute
> power level - they manage a *small* set of standard power
> states.
>
> Therefore, the power *state* that relates to fuser or scanner
> lamp readiness is in-scope for WIMS Power, but the exact
> power consumption should NOT be changeable by the site.
>
> Site-defined Power Policy (when to go to sleep after idle
> or a time-of-day) that can be changed is in-scope.
> </ira>
>
>
> 2. Should the subtask have its own reflector? (we can't pass up the
> opportunity for *POW at PWG.ORG* <POW at PWG.ORG>!)
>
> <ira>
> No - we should continue to use the single WIMS reflector
> (as we have done for 4 years for CIM without problems).
> </ira>
>
>
> Regards,
> Harry*
>
> Harry Lewis*
> Program Manager - Intellectual Property & Open Standards
> Phone: 720-663-3456
> e-mail: *harry.lewis at infoprint.com* <harry.lewis at infoprint.com>*
> **infoprint.com* <http://www.infoprint.com/>
>
>
> P Think before you print
>
>  *Ira McDonald <**blueroofmusic at gmail.com* <blueroofmusic at gmail.com>*>*
> Sent by: *wims-bounces at pwg.org* <wims-bounces at pwg.org>
>
> 05/11/2009 12:54 PM
>
>   To
> *wims at pwg.org* <wims at pwg.org>, William Wagner <*wamwagner at comcast.net*<wamwagner at comcast.net>>,
> Ira McDonald <*blueroofmusic at gmail.com* <blueroofmusic at gmail.com>>  cc
>   Subject
> [WIMS] Draft of Charter of WIMS Power Mgmt Project
>
>
>
>
>
>
>
>
> Hi Bill,
>
> Attempting to more constructively help out...
>
> I just posted a draft of a charter for WIMS Power Mgmt Project:
>
>  *ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspower-charter-20090511.htm*<ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspower-charter-20090511.htm>
>
> I followed the format approved by the PWG in IPP PSX project
> and more recently the MFD WG (basically the same idea).
> Especially, it includes a specific Out-Of-Scope section.
>
> Please add a brief Problem Statement (replace <tbd>).
>
> The Milestones during Definition Phase (Initial draft, Prototype
> draft, and PWG Last Call for each of Model and Binding specs)
> are the ones the PWG Steering Committee agreed on for MFD
> - the SC specifically do not want a milestone such as 'PWG CS',
> because a WG can't project that.
>
> Comments?
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: *blueroofmusic at gmail.com* <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* <http://www.mailscanner.info/>, and is
> believed to be clean. _______________________________________________
> wims mailing list*
> **wims at pwg.org* <wims at pwg.org>*
> **https://www.pwg.org/mailman/listinfo/wims*<https://www.pwg.org/mailman/listinfo/wims>
>
>
>
> _____________________________________________________________________________
> "This message and any attachments are solely for the intended recipient and
> may contain confidential or privileged information. If you are not the
> intended recipient, any disclosure, copying, use, or distribution of the
> information included in this message and any attachments is prohibited. If
> you have received this communication in error, please notify us by reply
> e-mail and immediately and permanently delete this message and any
> attachments. Thank you."
> _____________________________________________________________________________
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. _______________________________________________
> wims mailing list
> wims at pwg.org
> https://www.pwg.org/mailman/listinfo/wims
>
>
>
> _____________________________________________________________________________
> "This message and any attachments are solely for the intended recipient and
> may contain confidential or privileged information. If you are not the
> intended recipient, any disclosure, copying, use, or distribution of the
> information included in this message and any attachments is prohibited. If
> you have received this communication in error, please notify us by reply
> e-mail and immediately and permanently delete this message and any
> attachments. Thank you."
> _____________________________________________________________________________
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/wims/attachments/20090511/5d6e87f1/attachment-0001.html>


More information about the wims mailing list