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.2722.900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff size=2>I 
agree with Harry that there was significant effort put into preparing the 
current process. The effort&nbsp;should first &nbsp;be to understand and, if 
necessary clarify the presently defined process rather than to change 
it.&nbsp;&nbsp;Also,&nbsp;questions of document format, although important, must 
be separated from the standards development process 
discussion.</FONT></SPAN></DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff size=2>There 
were several points brought out in the plenary, and since I have not yet 
released the minutes, it may be germane to state them separately. They are not 
necessarily law, but they seem reasonable.</FONT></SPAN></DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff size=2>1. one 
must distinguish between versions of a&nbsp;standard and versions of a document. 
It is quite possible to have, for example two versions of a protocol, each fully 
documented and each implementable. However, for document versions&nbsp; that 
deal with corrections, additional information, new insights, each version will 
obsolete the previous version.&nbsp;There have been some good suggestions on 
keeping track of document versions, particularly those that including the date 
in the title. I suggest that work on different&nbsp;versions of a 
standard&nbsp;&nbsp;be treated as distinct activities. That is, &nbsp;if we have 
Printing Protocol, that has advanced to Draft Standard, and we have a need for 
and have either created a new charter or revised charter for Printing Protocol 
2, then Printing Protocol 2 becomes the title, it advances though 
the&nbsp;document stages as a separate project, and it is distinct from any 
version of Printing Protocol.</FONT></SPAN></DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff size=2>2. The 
levels of standards are defined. (Proposed Standard, Draft Standard and 
Standard). The steps to reach each stage are defined. There is an approval 
process for each stage. Once a document is reaches a certain stage, it cannot be 
revised or updated as a document at&nbsp;that stage; that would violate the 
sense of the approval process.&nbsp;&nbsp;A new series of working drafts can be 
done for the next stage. Or the document can be invalidated in which case a new 
project&nbsp;may be started at the lowest level to address the fatal 
flaw.</FONT></SPAN></DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff size=2>3. The 
interim documents to reach&nbsp;a&nbsp;standard of a given level&nbsp;are 
working drafts of a document to eventually become a standard&nbsp;at that level. 
That is, an interim document of a&nbsp; Printing Protocol Draft Standard should 
include in the title Working Draft - Printing Protocol Draft Standard. It can be 
assumed that there will be multiple working drafts&nbsp; and therefore, 
conceptually, versions of&nbsp;the working draft. I suggest that the &nbsp;date 
distinguishing scheme be used for these working drafts.</FONT></SPAN></DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff size=2>Bill 
Wagner</FONT></SPAN></DIV>
<DIV><SPAN class=210382121-30012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=210382121-30012003>&nbsp;</SPAN><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Harry Lewis 
[mailto:harryl@us.ibm.com]<BR><B>Sent:</B> Thursday, January 30, 2003 4:12 
PM<BR><B>To:</B> pwg@pwg.org<BR><B>Subject:</B> PWG&gt; PWG 
Process<BR><BR></DIV></FONT>
<BLOCKQUOTE><BR><FONT face=sans-serif size=2>The SM f2f discussion of PWG 
  Process was quite painful. It is obvious there are a multitude of varying 
  perspectives on how to conduct the progression of a standards specification. 
  We opened the process topic because we realized some conflicting information 
  and need for clarification in our document. &nbsp;I don't have a problem 
  citing other organizations in search of "best practice" but I would like us to 
  consider applying newfound reason to clarify our process, not redefine 
  it!</FONT> <BR><BR><FONT face=sans-serif size=2>Our existing process 
  distinguishes the key stages of Chartering, Proposing, Specifying, 
  Implementing and Maintaining an industry standard. It recognizes supporting 
  documents for this activity such as White Papers, Working Drafts and 
  Standards. It also acknowledges activities such as Brainstorming, Requirements 
  gathering, prototyping, implementing and testing. </FONT><BR><BR><FONT 
  face=sans-serif size=2>The process, as written, is an attempt to organize 
  these activities and supporting documents in such a way that streamlines the 
  progression from concept to final standard... something we hadn't seen in 
  other venues. One of the key elements of the existing process is that there 
  are ONLY 3 LAST CALLS. Each last call (if passed) makes a distinct transition 
  to a more stable level of the standard. This is signified by the STATUS 
  (reflected in the name) of the standard... not the version. Versioning was not 
  discussed in the current PWG process (which is a flaw) but was assumed to be a 
  linear progression on the working drafts that supported the standard 
  progression. </FONT><BR><BR><FONT face=sans-serif size=2>Several ideas for 
  updating our process were floated in the phone conference today. I am not 
  opposed to updating the process... if one thing was proven by today's call it 
  is that there is very little agreement on how the standard should be 
  interpreted. I do feel compelled to remind that a great deal of similar 
  discussion went into creation of the current process. I do wonder how much 
  effort we are likely to expend only to come up with a process with new naming 
  and versioning that diagrams out to nearly what we have, today. 
  </FONT><BR><BR><FONT face=sans-serif size=2>I recommend anyone who has a 
  proposal which they were trying to hash out in the call but who feels like, 
  perhaps, their point did not get assimilated or would like to expose their 
  concepts to a wider audience, go ahead and describe your idea here, for 
  discussion on the PWG.org reflector &nbsp; &nbsp; &nbsp; &nbsp;</FONT> 
  <BR><FONT face=sans-serif 
  size=2>---------------------------------------------- <BR>Harry Lewis <BR>IBM 
  Printing Systems <BR>---------------------------------------------- 
</FONT></BLOCKQUOTE></BODY></HTML>