attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 6.00.2800.1491" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff size=4>Thanks 
Jerry - and the next two sentences after your highlighting are 
also</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>important.&nbsp; A Design Requirements document (or section) can say 
"The</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff size=4>Foobar 
design SHOULD support...", but the v1.0 Protocol or 
Interface</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>standard doesn't have to satisfy every requirement - it just needs to 
</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>document what and why for requirements that are NOT 
satisfied.</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff size=4>And I 
agree that will Bill that the Use Models need to be moved to</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>section 1.&nbsp; I was following the style of the existing section 3 Use 
Models </FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff size=4>in the 
</FONT></SPAN><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>Port Mon MIB (which will now also have to be moved, 
Jerry).</FONT></SPAN></DIV>
<DIV><BR><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff 
size=4>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=043585718-14062005><FONT face=Arial color=#0000ff size=4>- 
Ira</FONT></SPAN></DIV>
<P><FONT size=2>Ira McDonald (Musician / Software Architect)<BR>Blue Roof Music 
/ High North Inc<BR>PO Box 221&nbsp; Grand Marais, MI&nbsp; 49839<BR>phone: 
+1-906-494-2434<BR>email: imcdonald@sharplabs.com</FONT> </P>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> owner-wims@pwg.org 
  [mailto:owner-wims@pwg.org]<B>On Behalf Of 
  </B>thrasher@lexmark.com<BR><B>Sent:</B> Monday, June 13, 2005 3:31 
  PM<BR><B>To:</B> wims@pwg.org<BR><B>Subject:</B> WIMS&gt; Re: WIMS Counter 
  Spec Requirements...requirements..<BR><BR></FONT></DIV>
  <P><FONT face="Times New Roman" size=3>Here's the text from the Process 
  Document</FONT> 
  <P><FONT face="Times New Roman" size=3>Section 4.4 </FONT>
  <P><FONT face="Times New Roman" size=3>"Prior to completion of the first 
  Working Draft, a clear statement of requirements for the standard to be 
  produced is required. &nbsp;A requirements statement documents the best effort 
  collection of known requirements on a particular protocol, interface, 
  procedure or convention. &nbsp;</FONT><FONT face="Times New Roman" color=blue 
  size=3>The requirements statement is important as it leads to a clear, common 
  understanding of the goals, provides a guide for developing the standard, and 
  can be used as a final test to measure the completeness of the resulting 
  specification</FONT><FONT face="Times New Roman" size=3>. It is not necessary 
  that the resulting standard meet every stated requirement, but the standard 
  should be explicit about which requirements it does not meet, and why. 
  Requirements may be updated during the development of the standard, as they 
  become clearer. As with Charter (above), brainstorming, fact-finding and 
  associate! d activities frequently accompany the process of requirements 
  gathering. Often, at the beginning of a project, the Charter, Requirements and 
  early versions of an initial Working Draft are all undergoing simultaneous 
  revision until a clear direction emerges and the Charter and Requirements are 
  formally approved. "</FONT> 
  <P><FONT face="Times New Roman" size=3>We clearly have already streached 
  letter of the process document by not formally approving a statement of 
  requirements prior to the completion of the first Working Draft. &nbsp;That 
  being said I would think that a statement of requirements could contain both 
  the use cases and scenarios that demonstrate the need for standardization of 
  something as well as the particular design requirements placed on the 
  development of the specification.</FONT> 
  <P><FONT face="Times New Roman" size=3>That being said I personally think that 
  the use cases text that Ira has offered would be better placed as Section 1.1, 
  followed by Section 1.2 Overview of Counters followed by Section 1.3 Design 
  Requirements for Counters.</FONT> 
  <P><FONT face="Times New Roman" size=3>I also have a comment about the term 
  "Down Mode"...........I'm not sure how long this term has been in the document 
  but it's not actually used anywhere else in the document...and it should be 
  "Down State" or something other than Mode in my opinion. &nbsp;I would think 
  there are very few printer vendors that have a "User Mode", a "Maintenance 
  Mode" and a "Down Mode" in thier respective products. &nbsp;And the first 
  sentence of the definition is messed up as well......</FONT> 
  <P><FONT face="Times New Roman" size=3>Jerry Thrasher, Lexmark </FONT>
  <P>
  <P>
  <P><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>wamwagner@comcast.net</B></FONT> 
        <BR><FONT face=sans-serif size=1>Sent by: owner-wims@pwg.org</FONT> 
        <P><FONT face=sans-serif size=1>06/13/2005 01:09 PM</FONT> <BR></P>
      <TD><FONT face=Arial size=1>&nbsp; &nbsp; &nbsp; &nbsp; </FONT><BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; 
        &nbsp; &nbsp;wims@pwg.org</FONT> <BR><FONT face=sans-serif size=1>&nbsp; 
        &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</FONT> <BR><FONT 
        face=sans-serif size=1>&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; 
        &nbsp; &nbsp; &nbsp;WIMS&gt; June 15 Conference 
  Call</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT size=2><TT>The next WIMS 
  conference call is at 12 noon EDT on 15 June. Agenda will concentrate on 
  Counter 
  Spec:<BR>ftp://ftp.pwg.org/pub/pwg/wims/wd/lcrc-wimscount10-20050603.pdf<BR>ftp://ftp.pwg.org/pub/pwg/wims/wd/lcrc-wimscount10-20050603rev.doc<BR></TT></FONT><BR><FONT 
  size=2><TT>Dial In: 1-866-365-4406<BR>Passcode: 
  2635888#<BR></TT></FONT><BR><FONT size=2><TT>This draft includes changes 
  agreed to at last conference call although the "requirements" item still needs 
  to be addressed. Ira's message of 7 June should be discussed as to need, 
  required detail, and who will generate the new 
  material.<BR></TT></FONT><BR><FONT size=2><TT>I find the "requirements" 
  requirement of the PWG process unclear with respect to whether these deal with 
  requirements for the proposed items (Why have are counters needed ?) or Ira's 
  interpretation that it is a detailed identification of the requirements of the 
  proposed &nbsp;items. It would be helpful if Jerry (as protagonist for 
  inclusion) could clarify his interpretation of the process document. At any 
  rate, it seems odd having the more general use models (which touch on 
  requirements for) in section 3 , while the &nbsp;design requirements are in 
  section 1. It would seem that the "Why" should precede the 
  &nbsp;how.<BR></TT></FONT><BR><FONT size=2><TT>With the resolution of the 
  "requirements" &nbsp;question, I believe that the WG group has gone well 
  beyond addressing voiced last call issues, and although we would continue to 
  strive toward perfection, I think we had better concentrate on wrapping this 
  up and getting it ready for a vote.<BR></TT></FONT><BR><FONT size=2><TT>Bill 
  Wagner, Chairman, WIMS WG</TT></FONT> 
<BR><BR><BR></P></BLOCKQUOTE></BODY></HTML>