Rick,
To attempt to address your question directly, it is my understanding that Version number is to provide an indication of Specification Maturity. This apparently is adopted from other standards groups, where there is some significance to certain version numbers rather than them just being consecutive numbers. (It would be useful to have that correlation specified.) Indeed, as you may recall from the plenary, evidence of specification maturity to convince one's management to proceed with prototyping was one of the motivations for the process change. Those individuals who voiced that problem seem pleased with the proposed change, which suggests that their management just needed a maturity indicator different from what we had.
My problem is a little different, since it is not my management that I must convince but my customers. And a sequence such as you outline (or the original process) makes it easier to do this than the currently proposed process. However, it appears that I am in the minority.
Bill Wagner/NetSilicon
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Saturday, February 22, 2003 2:54 PM
To: 'Rick Seeler'; pwg@pwg.org
Subject: RE: PWG> PWG Process update
Hi Rick,
I understand your concern, but the process really is intended to have
prototyping (preferably by more than one company although not necessarily,
in the case of an open source prototype) BEFORE voting to promote to
Candidate Standard.
Historically, PWG developed standards (Job MIB and IPP) have always
been prototyped during the working draft stage by one or more
vendors and their results have driven the specification stage.
In the IETF/W3C processes, a later Working Draft is deemed complete
enough by email concensus on a Working Group's mailing list to be
prototyped - it has NO official status outside the Working Group.
In order to actually be moved forward to IETF Proposed Standard
or W3C Candidate Recommendation, viable prototypes are strongly
recommended to have been completed and results published.
The PWG Process 2.0 shortens the IETF process to align with the
W3C, ISO, and many other standards organizations who have some
official "Candidate" phase followed by "Standard".
The need you're articulating is covered in the ISO process
which has the following steps:
TN - Technical Note (our PWG Working Draft)
CD - Committee Draft (passed WG 'last call' but NOT a formal vote)
DIS - Draft Int'l Std (our PWG Candidate Standard)
IS - Int'l Std (our PWG Standard)
Using 'CD' wouldn't be good for PWG (conflicts in meaning with 'CS').
And really we want prototyping long BEFORE a working group would
'last call' their SD (Stable Draft) or whatever.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Rick Seeler [mailto:rseeler@adobe.com]
Sent: Saturday, February 22, 2003 12:28 PM
To: pwg@pwg.org
Subject: RE: PWG> PWG Process update
One question about the new process:
How does one know that the specification is at a stable enough state to
begin developing prototypes? I believe it may be hard to convince any
company to invest in prototype development when there's no guarantee (or
voting process) to keep the standard from changing wildly in the interim.
If that step is "Candidate Standard", then the prototyping should come after
voting to go to "Candidate Standard" and not before.
Maybe that was the intent and it's just not stated properly. If the
statement "A Candidate Standard should not be approved unless it is
supported by prototypes and thought to be ready for implementation." were
moved out of section 4.5 and into section 4.6 (and the word "Candidate" were
removed), I'd withdraw my objection.
I saw the process as this:
1) Write the Requirements.
2) Vote on the Charter.
3) Write/modify the Specification. Once it seems solid...
4) Vote on the spec.
5) If the vote fails, go back to step 3.
6) If the vote passes, it's now a "Candidate Standard".
7) Find companies willing to do prototype work.
8) Create/modify prototypes.
9) If problems with spec are found, go to step 3 or create/modify an errata
document and go to step 8.
10) Do interop testing. If it fails, go back to step 8.
11) if interop passes, vote.
12) if the vote fails, go back to step 3 or create/modify an errata document
and go to step 11.
13) If vote passes - it's now a "Standard".
14) Celebrate!
Does this not seem reasonable?
(I'm sure there will be no shortage or responses to this question. ;-)
-Rick
-----Original Message-----
From: owner-pwg@pwg.org [mailto:owner-pwg@pwg.org] On Behalf Of Harry Lewis
Sent: Friday, February 21, 2003 9:42 PM
To: pwg@pwg.org
Subject: PWG> PWG Process update
An update has been posted. Thanks to Dennis for adding some corrections,
observations and pointing out some issues (yellow). We've also added a
diagram like we had in the old process. Hope it is helpful.
ftp://ftp.pwg.org/pub/pwg/general/process/pwg-process20-20030221.doc
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
This archive was generated by hypermail 2b29 : Mon Feb 24 2003 - 14:48:26 EST