<p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;
mso-list:l2 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>1.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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.<o:p></o:p></span></p>

<p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;
mso-list:l2 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>2.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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.<o:p></o:p></span></p>

<p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;
mso-list:l2 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>3.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Addressing Harry&#8217;s
question, I will try to make the &#8220;out of scope&#8221; area clearer and less
restrictive. &nbsp;At this point, I do not want to &nbsp;prejudge what we want
to do without better understanding of both user/administrator and manufacturer viewpoints.<o:p></o:p></span></p>

<p class=MsoListParagraph style='margin-left:1.25in;text-indent:-.25in;
mso-list:l2 level2 lfo2'><![if !supportLists]><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>a.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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 &nbsp;more detailed sub states to
an application which understands them.<o:p></o:p></span></p>

<p class=ListBullet1 style='margin-left:1.25in;mso-list:l2 level2 lfo2'><![if !supportLists]><span
style='font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>b.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-family:"Arial","sans-serif"'>Regardless, we certainly need to address
how the standard states apply to &nbsp;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 &nbsp;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, &nbsp;reboot
require, safe to disassemble &nbsp;etc.<o:p></o:p></span></p>

<p class=MsoListParagraph style='margin-left:1.25in;text-indent:-.25in;
mso-list:l2 level2 lfo2'><![if !supportLists]><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>c.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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.<o:p></o:p></span></p>

<p class=MsoListParagraph style='margin-left:1.25in;text-indent:-.25in;
mso-list:l2 level2 lfo2'><![if !supportLists]><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'><span style='mso-list:Ignore'>d.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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. &nbsp;But the Power Management Elements Spec should be
protocol agnostic.<o:p></o:p></span></p>

<p class=MsoNormal><br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Ira, great
start! Couple observations.</span> <br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>1. As written,
adding or changing power state definitions is out of scope. Should the
objectives include &quot;interpretation&quot; or mapping of defined power
states as they relate to imaging devices? </span><br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; - For
example - are we going to standardize which &quot;power level&quot; relates to
fuser or scanner lamp readiness etc?</span> <o:p></o:p></p>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
&lt;ira&gt;<br>
My two cents.<br>
<br>
There was strong concensus at the last two face-to-face BOFs<br>
NOT to allow any but standard (CIM/ACPI) or vendor-defined <br>
power states - no site-defined power states - however, each<br>
power state should have an attribute for power consumption <br>
(in watts) - ACPI and CIM do NOT manage the absolute<br>
power level - they manage a *small* set of standard power<br>
states.<br>
<br>
Therefore, the power *state* that relates to fuser or scanner<br>
lamp readiness is in-scope for WIMS Power, but the exact <br>
power consumption should NOT be changeable by the site.<br>
<br>
Site-defined Power Policy (when to go to sleep after idle<br>
or a time-of-day) that can be changed is in-scope.<br>
&lt;/ira&gt;<o:p></o:p></p>

<p class=MsoNormal><br>
<br>
<span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>2. Should the
subtask have its own reflector? (we can't pass up the opportunity for <a
href="mailto:POW@PWG.ORG" target="_blank">POW@PWG.ORG</a>!)</span> <o:p></o:p></p>

</blockquote>

<div>

<p class=MsoNormal><br>
&lt;ira&gt;<br>
No - we should continue to use the single WIMS reflector<br>
(as we have done for 4 years for CIM without problems).<br>
&lt;/ira&gt;<br>
&nbsp;<o:p></o:p></p>

<p class=MsoNormal>-- <br>
This message has been scanned for viruses and <br>
dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>,
and is <br>
believed to be clean. <tt><span style='font-size:10.0pt'>_______________________________________________</span></tt><span
style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt>wims mailing list</tt><br>
<tt><a href="mailto:wims@pwg.org" target="_blank">wims@pwg.org</a></tt><br>
<tt><a href="https://www.pwg.org/mailman/listinfo/wims" target="_blank">https://www.pwg.org/mailman/listinfo/wims</a></tt><br>
</span><br>
<br>
_____________________________________________________________________________<br>
&quot;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.&quot;
_____________________________________________________________________________<o:p></o:p></p>

</blockquote>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body>