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
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>
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!)
<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
<http://www.infoprint.com/> infoprint.com
P Think before you print
Ira McDonald <blueroofmusic at gmail.com>
Sent by: wims-bounces at pwg.org
05/11/2009 12:54 PM
To
wims at pwg.org, William Wagner <wamwagner at comcast.net>, Ira McDonald
<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
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
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 <http://www.mailscanner.info/> MailScanner, and is
believed to be clean. _______________________________________________
wims mailing list
wims at pwg.orghttps://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, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/wims/attachments/20090511/0665782a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 590 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20090511/0665782a/attachment-0001.gif>
