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>Hi,</DIV> <DIV> </DIV> <DIV>Thanks Jerry - and the next two sentences after your highlighting are also</DIV> <DIV>important.  A Design Requirements document (or section) can say "The</DIV> <DIV>Foobar design SHOULD support...", but the v1.0 Protocol or Interface</DIV> <DIV>standard doesn't have to satisfy every requirement - it just needs to </DIV> <DIV>document what and why for requirements that are NOT satisfied.</DIV> <DIV> </DIV> <DIV>And I agree that will Bill that the Use Models need to be moved to</DIV> <DIV>section 1.  I was following the style of the existing section 3 Use Models </DIV> <DIV>in the Port Mon MIB (which will now also have to be moved, Jerry).</DIV> <DIV> Cheers,</DIV> <DIV>- Ira</DIV> Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221  Grand Marais, MI  49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com <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>-----Original Message----- From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of thrasher@lexmark.com Sent: Monday, June 13, 2005 3:31 PM To: wims@pwg.org Subject: WIMS> Re: WIMS Counter Spec Requirements...requirements.. </DIV> Here's the text from the Process Document Section 4.4 "Prior to completion of the first Working Draft, a clear statement of requirements for the standard to be produced is required.  A requirements statement documents the best effort collection of known requirements on a particular protocol, interface, procedure or convention.  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. 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. " 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.  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. 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. 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.  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.  And the first sentence of the definition is messed up as well...... Jerry Thrasher, Lexmark <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD> <TD>wamwagner@comcast.net Sent by: owner-wims@pwg.org 06/13/2005 01:09 PM <TD>                To:        wims@pwg.org         cc:                 Subject:        WIMS> June 15 Conference Call</TR></TBODY></TABLE> <TT>The next WIMS conference call is at 12 noon EDT on 15 June. Agenda will concentrate on Counter Spec: ftp://ftp.pwg.org/pub/pwg/wims/wd/lcrc-wimscount10-20050603.pdf ftp://ftp.pwg.org/pub/pwg/wims/wd/lcrc-wimscount10-20050603rev.doc </TT> <TT>Dial In: 1-866-365-4406 Passcode: 2635888# </TT> <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. </TT> <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  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  design requirements are in section 1. It would seem that the "Why" should precede the  how. </TT> <TT>With the resolution of the "requirements"  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. </TT> <TT>Bill Wagner, Chairman, WIMS WG</TT> </BLOCKQUOTE></BODY></HTML>