May 2511, 2004
PWG Standards Development Process v2.0
The Printer Working Group
The Printer Working Group
Definition of the Standards Development Process
Version 2.0
Status: Last
CallStable
Abstract: This document defines the standards development process that guides and controls the work of the Printer Working Group, an organization developing open standards for the Print, Imaging, MFP and related Services industries. This document organizes the flow of standards creation from Brainstorming, Requirements gathering and Charter definition through Working Drafts, Candidate Standards and Standards. Herein are the guidelines for conducting Last Call, assuring interoperability and establishing levels of Formal Approval. PWG Process v2.0 builds on the original PWG process document but has been rewritten for greater clarity. Sections relating to Intellectual Property and Confidentiality are completely unaltered. This document defines PWG policy and process and does not define an industry standard.
This document is available electronically at:
ftp://ftp.pwg.org/pub/pwg/standards/process/lcrc-pwgprocess20-20040525.pdf
Upon formal approval, the adopted version of this document will be available electronically at:
ftp://ftp.pwg.org/pub/pwg/pwgadmin/adm-pwgprocess20-2004.pdf
Copyright
(C) 2004, The Printer Working Group. All rights reserved.
This document may be copied and furnished to others, and derivative works that comment on, or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice, this paragraph and the title of the Document as referenced below are included on all such copies and derivative works. This document may not be modified in any way, including removal of the copyright notice or references to the Printer Working Group, a program of the IEEE-ISTO.
Title: The Printer Working Group Definition of the Standards Development Process
The IEEE-ISTO and the Printer Working Group DISCLAIM ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED INCLUDING (WITHOUT LIMITATION) ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The Printer Working Group, a program of the IEEE-ISTO, reserves the right to make changes to the document without further notice. The document may be updated, replaced or made obsolete by other documents at any time.
The IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO take no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
The IEEE-ISTO and the Printer Working Group, a program of the IEEE-ISTO invite any interested party to bring to its attention any copyrights, patents, or patent applications, or other proprietary rights, which may cover technology that may be required to implement the contents of this document. The IEEE-ISTO and its programs shall not be responsible for identifying patents for which a license may be required by a document and/or IEEE-ISTO Industry Group Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Inquiries may be submitted to the IEEE-ISTO by e-mail at:
info@ieee-isto.org
The Printer Working Group acknowledges that the IEEE-ISTO (acting itself or through its designees) is, and shall at all times, be the sole entity that may authorize the use of certification marks, trademarks, or other special designations to indicate compliance with these materials.
Use of this document is wholly voluntary. The existence of this document does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to its scope.
About the IEEE-ISTO
The IEEE-ISTO is a not-for-profit corporation offering industry groups an innovative and flexible operational forum and support services. The IEEE Industry Standards and Technology Organization member organizations include printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, and print management application developers. The IEEE-ISTO provides a forum not only to develop standards, but also to facilitate activities that support the implementation and acceptance of standards in the marketplace. The organization is affiliated with the IEEE (http://www.ieee.org/) and the IEEE Standards Association (http://standards.ieee.org/).
For additional information regarding the IEEE-ISTO and its industry programs visit:
About the Printer Working Group
The Printer Working Group (or PWG) is a Program of the IEEE-ISTO. All references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” The PWG is chartered to make printers and the applications and operating systems supporting them work together better. In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, data models, procedures and conventions. Printer manufacturers and vendors of printer related software would benefit from the interoperability provided by voluntary conformance to these standards.
In general, a PWG standard is a specification that is stable, well understood, and is technically competent, has multiple, independent and interoperable implementations with substantial operational experience, and enjoys significant public support.
Contact information:
The Printer Working Group
c/o The IEEE Industry Standards and Technology Organization
445 Hoes Lane
Piscataway, NJ 08854
USA
PWG Web Page: http://www.pwg.org/pwg PWG Mailing List: mailto:pwg@pwg.org
Instructions for subscribing to the PWG mailing list can be found at the following link:
http://www.pwg.org/mailhelp.html
Members of the PWG and interested parties are encouraged
to join the PWG and IPP WG mailing lists in order to participate in
discussions, clarifications and review of the WG product.
TABLE OF CONTENTS:
2.4 PWG Communications Infrastructure
3 PWG Standards Development and Maintenance
4 Formal PWG Standards-track Process
4.2 Organizing and Naming Documents
5 Informal Supporting PWG Documents
5.1 White Papers, Technical Briefs and Other Non-normative Documents
7 Publication of PWG Documents
8.3.2 Formal Approval Voting Rights
8.4 Publishing Of Approved Document
8.5.1 Working Group Decision Process
8.5.2 Working Group Voting Eligibility
8.6.1 PWG Plenary Approval Process
8.6.2 PWG Plenary Approval Voting Rights
10 Intellectual Property and Confidentiality
10.2 Intellectual Property Procedures
Table 1 - Three Phases to developing a PWG
Standard.................................................................................. 109
Table 2 – Status keywords........................................................................................................................... 1110
1 Introduction
This document establishes the process that is followed as the Printer Working Group develops open industry standards. The Printer Working Group (or PWG) is a Program of the IEEE Industry Standards and Technology Organization (ISTO) and all references to the PWG in this document implicitly mean “The Printer Working Group, a Program of the IEEE ISTO.” The PWG is an alliance among printer manufacturers, print server developers, operating system providers, network operating systems providers, network connectivity vendors, print and print management application developers chartered to make printers and the applications and operating systems supporting them work together better. In order to meet this objective, the PWG will document the results of their work as open standards that define print related protocols, interfaces, procedures and conventions. Printer manufacturers, vendors of printer related software and the consuming public would benefit from the interoperability provided by voluntary conformance to these standards.
A PWG standard is a specification that is stable, well understood, technically competent and has multiple, independent implementations with substantial operational experience, demonstrated interoperability and significant public support. The PWG may issue a standard as a PWG standard and/or when appropriate submit the standard to other standards organizations, such as the IETF, ISO, ITU, W3C, IEEE, or ECMA. In developing a standard, a working group of the PWG may define durable documents such as WSDL, Schema or common industry semantics that need to have well known, persistent filenames and file paths.
This process document establishes
1. The phases a PWG standards project will go through from Charter and Requirements through Drafts, Candidates and Standard to the final, Maintenance phase of an established standard.
2. Working documents naming and versioning
3. Standards naming and numbering
If this policy document is updated, the new version is subject to Last Call and Formal Approval as described, herein. As long as section 10, Intellectual Property and Confidentiality, is not modified, the new version may be approved through the Formal Approval process described in section 8.3.1. If section 10 is modified, 100% of all PWG members must approve the new document (abstentions/non-votes are not allowed).
2 Organization of the PWG
The Printer Working Group is composed of representatives
from printer manufacturers, print server developers, operating system
providers, network operating system providers, network connectivity vendors,
and print and print management application developers. Member Oorganizations are
those companies, individuals or other groups (i.e. a university) that have
agreed to participate and operate under the processes and procedures of the
IEEE-ISTO by-laws, the Printer Working Group Program Participation Agreement
and this document and have paid the annual assessment. Multiple individuals employed by the same
company or other organization cannot join the PWG as individual members. Associates or affiliates of member
organizations which are beneficially controlled or owned by said member
organization with more than fifty percent (50%) of the voting stock or equity
shall not be considered a separate entity and are not eligible for separate
membership in the PWG. The annual
assessment is set each year by the PWG itself.
2.1 PWG Officers
The PWG has a Chair position responsible for organizing the overall agenda of the PWG. The PWG chair is elected in odd numbered years by a simple majority of the PWG members to a two-year term of office that begins on September 1st. Responsibilities of the PWG chair include creating working groups, appointing working group chairs, assuring that working groups maintain adequate leadership, making local arrangements for PWG meetings (this may be delegated as appropriate), setting the high level PWG agenda, chairing the PWG plenary session, ensuring that the PWG web and FTP site are maintained, and assisting working group chairs to accomplish their tasks. The PWG Chair must be a representative of a PWG Member Organization. The PWG Chair is an ex officio member of all working groups.
The PWG Vice Chair is elected in odd numbered years by a simple majority of the PWG members to a two-year term of office, beginning September 1st. The Vice Chair’s responsibilities are to act in the absence of the chair and provide assistance to the Chair in carrying out his or her role, as required. The PWG Vice Chair must be a representative of a PWG Member Organization. The PWG Vice Chair is an ex officio member of all working groups.
The PWG Secretary is elected in odd numbered years to a two-year term of office by a simple majority of the PWG members. It is the Secretary’s responsibility to record and distribute the minutes of all PWG plenary sessions and other meetings, as required, to support the PWG chair. The PWG Secretary must be a representative of a PWG Member Organization. The PWG Secretary is responsible, in cooperation with the IEEE ISTO, for managing number blocks for standards naming and maintaining a PWG Member Organization roster including contact and company profile information, including logo, as it pertains to representation on the PWG web site. The PWG Secretary is the only member authorized to install submissions or make changes to the “standards”, “candidates” or “informational” top-level permanent file directories of the PWG.
The PWG Steering Committee is composed of the PWG Chair, Vice Chair, Secretary, and chairs of all active working groups. The Steering Committee shall meet upon the call of the PWG Chair or by a majority of its members to discuss matters of concern of the PWG. Where matters come to a vote in the Steering Committee, decisions are made by simple majority of the entire committee (abstentions/non-votes are counted as no votes), with one vote per person.
2.2 Working Group Officers
Under the PWG Chair are a number of working groups (WG), which are chartered for the purpose of developing a specific standard. Working groups are chartered as required to address specific areas of standardization. A working group is considered active until it satisfies its charter or is otherwise terminated by the Working Group Chair with the agreement of the Steering Committee.
The PWG Chair appoints the Chair of a WG, with approval (simple majority) at a PWG plenary. The WG Chair’s term is indefinite and would normally extend through the period of time during which there is active maintenance on the standard(s) developed by the working group. The Working Group Chair must be a representative of a PWG Member Organization. The working group Chair is responsible for appointing a Vice Chair and Secretary for the WG, creating the WG Charter, setting the agenda for meetings of the WG, chairing WG meetings, appointing editors for WG documents, driving the work of the WG to completion, and reporting status of the WG at PWG plenary sessions.
The WG Chair appoints the Vice Chair of a WG, with approval (simple majority) of the WG. The WG Vice Chair’s term is indefinite. The Vice Chair acts in the absence of the Chair and assists, as appropriate, in carrying out the responsibilities of the Chair.
The WG Chair appoints the Secretary for a WG, with approval (simple majority) of the WG. The term of office is indefinite. The responsibilities of the WG Secretary are to record and distribute minutes of working group meetings and to record attendance for members of that working group.
2.3 PWG Meetings
The annual face-to-face meeting schedule for the PWG is set in October of each year. As a guideline, it is common to hold face-to-face meetings every 6 to 10 weeks with phone and web based conferencing during the interim. Face-to-face meetings are to be distributed geographically to try and normalize the travel burden among members. Meeting schedule and locations are determined through a proposal / consensus process and no other specific process or guarantees are implied. Meeting location details are to be published at least 4 weeks in advance of meetings. New documents must not be introduced under any circumstances less than 1 week prior to a face-to-face as this only leads to confusion and ineffective meeting results.
Non-standards related administrative and procedural decisions made at PWG administrative, business, or plenary meetings require a simple majority, 1 vote per member organization.
Dial-up and web conference details, agenda and reference materials are to be published at least 48 hours in advance when work is being conducted via remote conferencing.
2.4 PWG Communications Infrastructure
The PWG will maintain
1. A PWG web site http://www.pwg.org where PWG working group information, meeting schedules and document links and other pertinent information may be found.
2. A PWG ftp site ftp://ftp.pwg.org where PWG working drafts, standards, procedures, schema, templates and other useful and necessary documents may be accessed.
3. An e-mail reflector, including archive, for each active project. Instructions for subscribing to the PWG mailing lists can be found at the following link: http://www.pwg.org/mailhelp.html
3
PWG Standards Ddevelopment and Mmaintenance
There are 3 main phases to standards development in the PWG – Charter, Development and Maintenance (Table 1). These phases are a guideline to the activities and types of documents a working group should expect to encounter. There are no specific exit criteria from these phases. Exit criteria apply to PWG standards-track documents and are outlined in section 4.
Table 1 - Three Phases to developing a PWG Standard
|
Phase |
Activities in this Stage |
Internal Documents |
PWG Standards Documents |
|
Charter |
Identify need Brainstorm Develop Charter Gather Requirements |
White Papers |
Charter Requirements Statement Preliminary Working Draft |
|
Development |
Develop PWG Working Drafts Prototype Promote to Candidate Standard Demonstrate Interoperability Promote to PWG Standard |
White Papers Proposals Developer Guides Interop Test Plans Interop Test Results |
PWG Working Drafts Candidate Standards Supporting durables such as WSDL, Schema
|
|
Maintenance |
Maintain PWG Standard Maintain PWG Candidate Standard |
Errata Registration of new keywords, enums |
Standard Supporting durables |
4
Formal PWG Sstandards-track Pprocess
Standards development consists of the progression of documents used to define and articulate standards. PWG project documents consist of the Charter, a set of Requirements, Working Drafts, Candidate Standards and the Standard, itself. Publication of completed PWG Candidate Standards, Standards and Best Practice documents requires Last Call and Formal Approval as described in Section 8. Technical briefs and proposals relating to a standard, while helpful and encouraged, are not treated as formal documents and do not require Last Call or Formal Approval. The life cycle and organization of PWG standards-track and other project documents is defined below. For current best practice on the formulation of file namespace and file path names see
ftp://ftp.pwg.org/pub/pwg/informational/pwg-document-namespace-policy.pdf
4.1 Editing Documents
The Working Group Chair will appoint an editor for each standards-track document. The editor will be approved by a simple majority vote of the working group. Normally an editor will work in this capacity throughout the life cycle of the standard, although exceptions may occur. Editors are responsible for reflecting the decisions of the working group, rather than their own personal views. Ultimately, the editor has responsibility for the quality of the document, making sure that it is readable and has a coherent style, even when it has multiple authors or contributors.
4.1.1 Document Status Levels
A PWG document SHALL be labeled with a status level that will appear on the title page as follows:
Status: <keyword>
|
Status keyword |
Indicates |
|
Initial |
Initial attempt to specify the standard. |
|
Interim |
Standard in development. Significant changes to the standard expected in the future. |
|
Prototype |
Content of the standard is functionally complete and ready for prototyping. |
|
Stable |
Standard is very close to completion. Standard is either getting ready for, is in, or has completed Last Call. |
|
Approved |
The document has successfully completed PWG Formal Approval (see 8.3) |
|
Obsolete |
The document has been obsoleted by another PWG standard or industry standard. The obsolete PWG document is deprecated and should not be implemented. |
|
Superceded |
The document has been superceded by another PWG standard or industry standard. The superceded PWG document is substantially technically correct and may be implemented for compatibility. |
“Approved”, “Obsolete” and “Superceded” status are only applicable to documents that have successfully completed PWG Formal Approval.
Normally, a Working Draft will progress through each status level from “Initial” to “Stable”. Status levels may be skipped for some limited standards efforts. It is possible for a Working Draft to achieve reduced status if an unexpected, serious problem is found, for example, during prototyping.
The status of a Working Draft will be established via working group consensus.
4.2 Organizing and Naming Documents
Early versions of a working group Charter, Requirements, whitepapers and other supporting documentation may circulate on the pwg@pwg.org e-mail reflector. During formalization of their Charter and Requirements, a working group will chose an abbreviation (usually 2 to 4 characters), to preface their document names. This must be accomplished before the first Working Draft is published. The working group abbreviation is subject to approval by the PWG Steering Committee.
4.3 Working Group Charter
The first order of business for any working group is to create a Charter that clearly describes the scope of their work. Brainstorming, fact-finding, guest speakers and other enlightening activities often precede or coincide with Charter development. In addition to scope, the Charter should define milestones and schedule, including an expiration date. The PWG Steering Committee, based on perception of progress and commitment of the working group, may grant extensions. In some cases the working group may choose to publish their standard in affiliation with an outside standards organization such as the IETF or W3C. If this is evident, the Charter should indicate the desire for formal affiliation with another standards organization and include a liaison plan with the other organization. Charter definition, requirements gathering and outlining a preliminary Working Draft may occur simultaneously. In many cases, this is encouraged, as new information gleaned from these activities may alter perception of the Charter.
A Working Group Charter requires Formal Approval (see Section8.3).
4.4 Statement of Requirements
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 associated 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.
A Working Group Statement of Requirements requires Formal Approval (see Section8.3).
4.5 Working Draft
When rough consensus has been reached on the Charter, Requirements, and there is sufficient information to begin writing a standard, the initial Working Draft will be written. Charter and Requirements must reach Formal Approval prior to completion of the first Working Draft. A PWG Working Draft facilitates reaching consensus on how to approach the PWG Standard and provides a backdrop for discussion and agreement on details of the specification. The initial Working Draft, when reasonably complete, provides a foundation for further work on the Standard.
Working Drafts correspond to a specific version of the Standard they are defining. Unless the working group is engaged in an effort to revise an existing PWG Standard, the Working Drafts are always defining PWG Standard Version 1.0.
A PWG Working Draft cannot progress ahead of any given normative reference that it contains.
A PWG Working Draft requires Last Call, and Formal Approval to transition to PWG Candidate Standard.
4.6 Candidate Standard
When agreement has been reached among the participants about the details of a Standard, the current Working Draft is ready to transition to a PWG Candidate Standard. A Working Draft MUST NOT be approved as a Candidate Standard unless it is supported by 1 or more prototype and is thought to be ready for implementation. The purpose of prototyping is to generate information that will help design or perfect the final standard. As each type of standard may differ, the PWG process does not define specific, measurable prototype criteria beyond the commonly held notion of a test-of-principle model or early version of a technological device or process. A PWG Candidate Standard MUST NOT progress ahead of any Normative Reference that it contains.
A PWG Candidate Standard forms the basis for comments from outside of the working group and the PWG, and provides the foundation for initial product development and interoperability testing. Implementations can comfortably proceed from a PWG Candidate Standard, knowing that it will not undergo significant change as it matures to a PWG Standard. However, if changes to a Candidate Standard become necessary, these changes will be accomplished via Working Drafts that must once again go through Last Call and Formal Approval. The Working Draft will then and only then regain Candidate Standard status.
Candidate Standards correspond to a specific version of the Standard they are defining. Unless the working group is engaged in an effort to revise an existing PWG Standard, the Candidate Standards are always defining PWG Standard Version 1.0.
When a document becomes a Candidate Standard, it is assigned an IEEE-ISTO standard number, which it keeps forever. To indicate the standard is at Candidate Standard status, the prefix “CS” is attached to the standard number, resulting in a number such as “PWG CS 5105.2”. If the Candidate Standard goes back to Working Draft status, “WD” replaces the prefix “CS”, resulting in a number such as “PWG WD 5105.2”. IEEE-ISTO standard numbers are tracked and assigned by the PWG Secretary.
A PWG Candidate Standard requires Last Call, demonstration of Interoperability and Formal Approval to transition to PWG Standard.
4.7 Standard
When a PWG Candidate Standard has passed Last Call, demonstrated interoperability and acquired Formal Approval, it is promoted to the final status of a PWG Standard. At this point, “STD” replaces the prefix “CS” in the IEEE-ISTO standard number and “PWG” is replaced by “IEEE-ISTO”, resulting in a number such as “IEEE-ISTO STD 5105.2”.
4.8
Maintenance
of Sstandards
When a document has reached the PWG Candidate Standard or PWG Standard status, maintenance activity may occur on that standard. Such revision or extension documents start immediately at Working Draft status and then follow all rules above for progression to Candidate Standard and Standard. Note that the extension to a Candidate Standard cannot progress to Standard before the Candidate Standard it is revising or extending has progressed to Standard.
It is also possible that the PWG will decide to formalize PWG extensions for any (IETF, IEEE, or other printing industry) external standard (e.g. RFC2911). As above, such extension documents start immediately at Working Draft status and then follow all rules in earlier sections above for progression to Candidate Standard and Standard.
4.9 Best Practices
Best Practice documents reflect policy and advice from the PWG. Such documents, while not normative, are often referenced for clarification of PWG and related standards. Because we want Best Practice to be reliable and accurate, we treat these as formal Working Group documents that undergo naming, Last Call and Formal Approval just like a Working Draft.
5
Informal Ssupporting PWG Ddocuments
The following are considered informal, working documents that contribute to the development or clarification of a PWG Standard. As such, these documents require no Formal Approval process.
5.1
White
Papers, Technical Briefs and Oother Nnon-normative
Ddocuments
During the standards process, PWG members are encouraged to document proposals, clarifications or otherwise useful documents such as machine generated MIB fragments and XML schema as a White Paper or Technical Brief. These documents provide an informal means of communicating technical proposals among PWG members. It is strongly recommended that any topic open for discussion on the PWG agenda have supporting documentation made available for review at least one week prior to the meeting where the paper is to be discussed. Technical Briefs are particularly useful when two or more approaches to a standard exist and need to be debated. White Papers and Technical Briefs (treated the same) may be updated to reflect group consensus or individual positions on a particular topic. Since a White Paper represents current thought and individual contribution, they do not require any form of approval and have no formal status. White Papers, Technical Briefs and other documents, such as FAQ, are subject to change or withdrawal at any time. These documents should be posted to the PWG FTP site and announced on the working group mailing list prior to discussion at a PWG meeting. Discussion will be most fruitful when people have taken adequate time to review the papers prior to the meeting.
6
Exceptions to Pprocess
To handle exceptional cases, the Steering Committee may decide that one or more of the steps in the standards process may be shortened or eliminated. Such an exception to this PWG Standards Process must be approved by unanimous consent of the entire PWG Steering Committee.
7
Publication of PWG Ddocuments
All of the PWG standards-track and supporting documents described in sections 4 and 5 must be available in either PDF or HTML format (others may be provided as well) and published on the PWG FTP site. Any document identified as PWG Charter, PWG Requirements, PWG Working Draft, PWG Candidate Standard or PWG Standard represents a formal PWG approved document, which will be published in a durable location with well-known path after achieving the appropriate Last Call and/or Formal Approval. Listed are examples of the directory structure using v1.0 Standards as an example. In use, “[working group]” would be replaced by the abbreviation for a particular working group (e.g., pwg, pmp, ipp, etc). Note the prefix conventions established for these documents as reflected in the file name prefix in the examples below.
Charter – ftp://ftp.pwg.org/pub/pwg/[working group]/charter/ch-[working group]10-yyyymmdd.pdf
Requirements (active) – ftp://ftp.pwg.org/pub/pwg/[working group]/wd/wd-[working group]req10-yyyymmdd.pdf
Requirements (final) – ftp://ftp.pwg.org/pub/pwg/informational/req-[working group]req10-yyyymmdd.pdf
Best Practices – ftp://ftp.pwg.org/pub/pwg/informational/bp/bp-[working group]10-yyyymmdd.pdf
Working Drafts – ftp://ftp.pwg.org/pub/pwg/[working group]/wd/wd-[working group]10-yyyymmdd.pdf
Candidate Standards – ftp://ftp.pwg.org/pub/pwg/candidates/cs-[working group]10-yyyymmdd-510n.m.pdf
Standards – ftp://ftp.pwg.org/pub/pwg/standards/std-[working group]10-yyyymmdd-510n.m.pdf
For current best practice on the formulation of these names see ftp://ftp.pwg.org/pub/pwg/informational/pwg-document-namespace-policy.pdf
Standards are not published in the Working Group path. PWG Standards are given a unique number and are published in one, flat, namespace, managed by the PWG Secretary, for ease of access, accuracy and durability.
Supporting documents (see Section 5) are posted in the root Working Group path or a subdivision of that path as appropriate. Filename prefixes for common supporting documents are:
White Paper and Technical Brief – tb
FAQ – faq
Last Call Review Comments - lcrc
Internal working versions of PWG documents should be available in an agreed upon, widely available word processing format, to provide for collaboration between document editors and contributors. For example, Microsoft WORD and HTML are common revisable formats in use, today.
When documents are posted to the PWG FTP site, a notice should also be posted to the Working Group mailing list. It is recommended that Working Groups provide a web site where information about their activities is provided. The Web site should provide links to current, relevant documents.
8 Approval
8.1 Last Call
Last Call represents a final opportunity for issues to be raised against a document. During this period all PWG members are encouraged to review the final working draft for both technical and editorial content and to provide comments to the working group. The WG Chair announces a Last Call on a document with rough consensus of the working group. Last Calls are posted to all members of the PWG via the PWG-ANNOUNCE mailing list. The Last Call period may vary, based upon the content, complexity, holidays or other circumstances, but must be at least 16 full working days (minimum 22 calendar days). A working day is a normal business day and is considered to end at 10 PM USPST (Los Angeles, CA, USA). . Every Last Call must conclude at a PWG Plenary meeting with an overview of the draft or standards document and a review of detailed issues and their resolutions. All issues raised during Last Call must be either resolved or rejected as follows:
· Resolved - Document updated to reflect the resolution
· Rejected - No change required in the document
All issues and their resolution from the most recent Last Call must be published in the Formal Approval announcement.
8.2 Last Call Formal Review
Last Call results must be reviewed by the PWG Steering Committee to validate that the Last Call process has been conducted properly, prior to the start of Formal Approval.
8.3 Formal Approval
8.3.1 Formal Approval Process
Once all of the Last Call issues have been resolved or rejected, and the PWG Steering Committee has reviewed Last Call, the PWG Secretary must announce a vote for Formal Approval to transition the document to the next status level. Formal approval voting must be announced and conducted via the PWG-ANNOUNCE mailing list and the announcement must contain all issues and their resolution, which occurred during Last Call. The Formal Approval period must last at least 16 full working days (minimum 22 calendar days) and may be longer at the discretion of the WG Chair. A working day is a normal business day and is considered to end at 10 PM USPST (Los Angeles, CA, USA).
The PWG Secretary will administer the Formal Approval process with the assistance of the working group chair and the ISTO.
8.3.1.1 Permissable Votes
Following are the 3 possible votes allowed by the PWG Formal Approval process.
· YES – MAY be accompanied by editorial comments
· ABSTAIN – MUST NOT be accompanied by any comments
· NO without Strong Opposition – MUST be accompanied by explanation of technical opposition
· NO with Strong Opposition– MUST be accompanied by explanation of technical opposition
8.3.1.2 Formal Approval
Formal Approval requires
· A minimum of 25% of eligible members casting a vote
·
YES votes by 66%2/3 of those casting
votes
cast (not including abstentions) when there is no Sstrong
Oopposition
·
YES votes by 80% of those casting votes cast (not
including abstentions) when there isin the face of Sstrong
Oopposition
·
A minimum of 50 percent of votes cast
(including
abstentions included) must be YES.
· In computing votes,fractional portions are rounded down in all cases
Strong opposition occurs when one or more
companies formally calls for an 80% vote. It is the responsibility of the
WG chair to ensure that the results of a vote are fair and representative. If a
member of the PWG has an issue with a WG Chair decision, he or she can appeal
that decision to the PWG Steering Committee (first) and then to the membership
of the PWG at large if necessary.
A NOno vote on a
standards-track document requires the voter to state the technical reasons
for the NOno
vote, and a description of the changes that would be required to the document
to turn the NOno vote to a YESyes.
These will be
documented on the PWG-ANNOUNCE mailing list.
When a Working Draft, Candidate Standard or other formal PWG document passes Last Call but does not achieve Formal Approval during the initial voting period, due to lack of quorum, voting is automatically extended by, up to, two 30 calendar day Formal Approval extension periods. This gives the WG Chairman and PWG Steering Committee time to interact with PWG members who may require additional time or education regarding the proposed standard.
A vote is not considered final until the end of the Formal Approval period (PWG Member Organizations may change their vote during the Formal Approval process).
If, for any reason, the attempt at Formal Approval fails, a WG has the option to resolve the technical issues and repeat Last Call and Formal Approval, or to revise their Charter and begin again, or to abandon the document.
Formal approval is not granted until the PWG Steering
Committee reviews the process used to achieve Last Call and Formal ApprovalVote
insuring the PWG process was followed with fidelity.
After the Formal Approval process has completed editorial corrections will be made to the document and the document will be published. All technical comments should be posted to the WG mailing list, addressed by the Working Group and the responses archived in the PWG FTP site in the form of a lcrc- document draft.
8.3.2
Formal Approval Vvoting Rrights
The following voting rights policy applies to all Formal Approval voting:
· A voter must be a representative of a PWG Member Organizationin good standing.
·
Only one vote may be cast by each PWG Member
Organization. Votes are counted on an organization basis.
8.4 Publishing Of Approved Document
The PWG Secretary, with assistance from the WG Chair, must edit documents that have passed Formal Approval to update the document number, format and the final publication date. The PWG Secretary must then publish the document in the appropriate locations with the appropriate file names (see section 7).
8.5
Working Group DecisionsApproval with a Working
Group
8.5.1
Working Group Decisionapproval
Pprocess
There is no Formal Approval process that applies to Working Groups and voting is not necessary to validate working group decisions. If the WG does resort to voting the following must be met for the vote to be considered binding:
1. A simple majority of those casting votes (not including abstensions) on administrative and operational issues
2. A 66% majority of
those casting votes (not including abstensions) on For
technical issues, a 2/3 majority of
those casting votes (abstentions do not count) is required. A simple majority of those casting votes
(abstentions do not count) is required to pass on administrative and
operational issues.
It is the responsibility of the WG chair to ensure that the results of a vote are fair and representative. If a member of the PWG has an issue , the WG Chair decision may be appealed to the PWG Steering Committee.
8.5.2
Working Group approval Vvoting
Eligibilityrights
The following voting rights policy applies to all voting done within the PWG Working Groups:
· A voter must be a representative of a PWG Member Organization in good standing.
·
Only one vote may be cast by each PWG Member
Organization.Votes are counted on an organization basis.
·
At times it may become necessary to conduct a vote
on internal WG matters. If so, eEligibility
is determined by an organization attending two of the previous four
face-to-face meetings or , or two of the previous four
conference calls. It is the responsibility of the WG Secretary to
maintain the list of eligible voters.
·With a simple
majority vote, the working group may confer voting rights to an individual or
organization that is not otherwise eligible to vote due to lack of attendance.
This is done on a case-by-case basis and is intended to address those
individuals or companies who have made significant, on-going contributions to
the group – but have not been able to attend the required number of
meetings. In no case may a
representative of a non-member company be conferred voting rights by the action
of a working group.
· A Working Group Chair may declare that a sufficient quorum does not exist for voting purposes if at least 50% of potential voting members are not present during the vote.
· Voting is not a requirement for declaring rough consensus, unless specifically requested by a member with voting rights.
8.6 Approval at a PWG Plenary
8.6.1
PWG Plenary Aapproval Pprocess
A simple majority of those casting votes (abstentions do not count) is required.
8.6.2
PWG Plenary Aapproval Vvoting
Rrights
The following voting rights policy applies to all voting done within the PWG plenary:
· A voter must be a representative of a PWG Member Organization.
·
Only one vote may be cast by each PWG Member
Organization.Votes are counted on an organization basis.
· Plenary voting occurs at plenary sessions, so participation in the plenary is required for voting.
· Voting is not a requirement for declaring rough consensus, unless specifically requested by a member with voting rights.
9 Maintenance
Many PWG standards are extensible and provide the ability for additional keyword or enumerated values to be registered. When approved, these have the same status as the standard to which the feature is being added. In addition, as implementation work proceeds, clarifications may be required to guarantee interoperability. This section addresses the process to be followed for:
· Registrations of new operations and type 2 enums, keywords, and attributes, and
· Clarifications of the standard and any approved registrations
Major changes or additions to a standard are not considered maintenance, but require engagement of the PWG standards development process described above.
Proposals for registrations and clarifications will follow the following process:
1. Each WG will appoint a Maintenance Editor for their PWG Standard.
2. Anyone can initiate a proposal for a clarification or registration by starting a discussion on the appropriate project mailing list.
3. After there is some agreement on the mailing list for the need of a clarification or the suitability of a registration, the proposer and the standard’s Maintenance Editor work out a proposal. Such a proposal should include:
· Status of the proposal, including previous reviews.
· A description of the requirement being met or the problem being solved.
· Description of the proposed solution.
· The exact text to be incorporated into the standard at some future date.
4. To make the status of proposed registrations and clarifications clear to PWG participants and others, the Maintenance Editor will keep them in the appropriate sub-directory
ftp://ftp.pwg.org/pub/pwg/[working group]/proposed-registrations
ftp://ftp.pwg.org/pub/pwg/[working group]/proposed-clarifications
where [working group] is the project acronym.
5. All
proposals must be published according to section 76
of this document.
6. Reviews of proposed registrations and clarifications may occur at a meeting or on the WG MAILING LIST.
7. The proposal will undergo sufficient reviews and updates until, in the opinion of the WG Chair, there is rough consensus that the proposal is ready for Last Call as described in section 8.1 followed by Formal Approval as described in section 8.3.
8. If,
in the opinion of the WG Chair, the Last Call discussions and Formal Approval
meet the voting requirements described in section 8.3.1.20,
the Maintenance Editor will forward move the approved
registration or clarification to the PWG Secretary who will move it to the appropriate
sub-directory for each project
ftp://ftp.pwg.org/pub/pwg/[working group]/approved-registrations
ftp://ftp.pwg.org/pub/pwg/[working group]/approved-clarifications
and announce the Formal Approval to the entire PWG via the PWG-ANNOUNCE MAILING LIST.
9. Periodically, the Maintenance Editor will incorporate the approved registrations and clarifications into the version of the standard that the PWG keeps to record all approved registrations and clarifications. Such an updated version of the standard will have a new minor version of the standard, along with a Change History Appendix that lists each change.
10 Intellectual Property and Confidentiality
Note: The Intellectual Property and Confidentiality section has been preserved in its entirety. During the evolution of PWG Process Document versions, this section has remained unchanged so as not to disrupt established legal reviews and approvals established among out members.
10.1 Ownership of IP rights:
All patents, copyrights, or other intellectual property owned or created by any Member or member’s affiliates (“hereinafter “Member or Associate) outside the PWG or its work within the PWG shall remain the property of that Member or Associate thereunder and shall not be affected in any way by the Member or Associate’s participation in the PWG.
The PWG may, through its activities, generate intellectual property, and license such property to the Members and/or Associates on reasonable and nondiscriminatory terms, conditions and prices; provided, however, that Members and Associates receive more favorable pricing than non-Members or non-Associates.
All information and materials, and all copyrights thereto, contributed by Members and Associates and their representatives and incorporated into a PWG Standard and Specification (here after “the Standard”) shall be owned by the contributing Member or Associate. The contributing Member or Associate shall grant PWG and its Members and Associates an irrevocable license to use, reproduce, modify, distribute and sublicense the copyrighted work(s) incorporated in the Standard on non-discriminatory basis and within reasonable terms and conditions. Notwithstanding the above, any intellectual property independently created by a Member or Associate, but not incorporated into a PWG standard, should remain the exclusive property of the original owner and no mandatory license should be imposed.
Participants in the standard setting procedure shall disclose any known patents whose use would be required for compliance with a proposed PWG standard. Prior to PWG's approval of the proposed standard, the PWG should receive a written patent statement from the patent holder as described below in section 10.3.
10.2 Intellectual Property Procedures
The PWG is not in a position to give authoritative or comprehensive information about evidence, validity or scope of patents or similar rights, but it is desirable that any available information should be disclosed. Therefore, all PWG members shall, from the outset, draw PWG's attention to any relevant patents (hereinafter defined) either their own or of other organizations including their Affiliates (hereinafter defined) that are known to the PWG members or any of their Affiliates, although PWG is unable to verify the validity of any such information.
· “Relevant Patents” means any issued or registered patent, without use of which a Proposed PWG Standard cannot be practiced.
· “ Proposed PWG Standard” means each proposal towards each PWG specification, which proposal is submitted to PWG after the date of acceptance of these Procedures (hereinafter the Effective Date).
· “Affiliates or Associates,” with respect to section 10.2, means any entity that as of the Effective Date directly or indirectly is controlled by the PWG member, so long as such control exists, where “Control” means beneficial ownership of more than fifty percent (50%) of the voting stock or equity in an entity.
10.3 Patent Statement
If a Proposed PWG Standard is submitted to the PWG, three different situations may arise with respect to the relevant Patents:
(1) In the event the PWG Proposed Standard is adopted to become a PWG Standard, the patent holder waives his rights under the Relevant Patents owned by him and hence, the Proposed PWG Standard is freely accessible to everybody; no particular conditions, no royalties due, etc., with respect to such Relevant Patents. The PWG Standard means any PWG specifications that are officially published by PWG after October 1, 1999.
(2) In the event a PWG Proposed Standard is adopted as a PWG Standard, the patent holder is not prepared to waive his rights under the Relevant Patents owned by him but would be willing to grant licenses to other parties on a non-discriminatory basis and on reasonable terms and conditions, provided a similar grant under the licensee's patents within the scope of the license granted to the licensee is made available. Such license grants are left to the parties concerned.
(3) In the event the Proposed Standard is adopted to become a PWG Standard, and the patent holder is not willing to comply with the provisions of either paragraph 10.3 (1) or (2), in such a case the Proposal cannot be established as a PWG Standard.
(4) Whichever option from among paragraphs 10.3 (1), (2) or (3) is chosen, any PWG member must provide a written statement to be filed on behalf of itself and its Affiliates at the PWG secretariat with respect to the Relevant Patents that are owned by the PWG member or any of its Affiliates and known to the PWG member or any of its Affiliates. This statement must not include additional provisions, conditions, or any other exclusion clauses in excess of what is provided for each case in paragraphs 10.3 (1), (2) and (3).
(5) If no Relevant Patents that are owned by the PWG member or any of its Affiliates are known to the PWG member or any of its Affiliates, an affirmative disclosure to that effect must be submitted before the end of the Patent Statement deadline in lieu of the Patent Statement. Any Relevant Patents that are owned by the PWG member or any of its Affiliates and are found after the Patent Statement deadline are automatically subject to either paragraph 10.3 (1) or (2) as described above.
(6) Format of Patent Statement/Patent Notice
(i) A Patent Statement should be submitted by all the PWG members for all Relevant Patents which are known to the PWG members and their Affiliates and are owned by the PWG members or their Affiliate, providing the following information:
1. Proposal Name
2. Organization: The organization that holds the patent which could include administrations, universities, etc., and its contact address.
3. Tel. No.: The contact telephone number of the organization.
4. Fax. No.: The contact fax number of the organization.
5. Patent Policy and Remarks: The declared patent policy of the organization in its communication to the PWG. Most often the patent policy is given as "Pat. Policy. 10.3 (2)”, which would mean that the organization subscribes to paragraph 10.3 (2) of the PWG bylaws.
6. Patent Title: The title of a patent
7. Patent Number: The number of the patent.
8. Patent Country: The country in which the patent has been obtained. If the patent is held in several countries, a list of those countries is given.
9. Signature: Signature of an authorized representative of the company.
(ii) Further, a Patent Notice should be submitted by all the PWG members for Relevant Patents which are known to the PWG members and their Affiliates and are not owned nor controlled by the PWG members or their Affiliate, providing the following information:
1. Proposal Name
2. Organization: The organization that holds the patent which could include administrations, universities, etc., and its contact address.
3. Patent Title: The title of a patent
4. Patent Number
5. Patent Country: The country in which the patent has been obtained. If the patent is held in several countries, a list of those countries is given.
6. Signature: Signature of a representative of the company
(7) All members must submit a written patent statement according to section 10.3(6) between the proposal deadline and the commencement of voting period.
10.4 Non-Confidentiality.
The participation in the PWG by the Members and the Associates and their appointed representatives shall be on a non-confidential basis; however, a PWG Member may with the approval of the Steering Committee, wherein such approval shall not be unreasonably withheld, enter into written confidentiality agreements with all other PWG Members which restricts the dissemination of specified confidential information and/or materials provided by any of such Member, to Persons who are not Members or Associates.
Subject only to valid patents and copyrights, all PWG Members and Associates shall be free to use all information received or publicly disclosed from the PWG, its Members or Associates in connection with the normal business including the processes described herein, without obligation regardless of markings including but not limited to “Proprietary” or “Confidential.”
11 PWG Process Diagram
12 Author’s Address:
Dennis Carney
IBM Printing Systems
6300 Diagonal Highway
Boulder, CO 80301
Phone: 303 924 0565
Fax: 303 924 7434
e-mail: dcarney@us.ibm.com
Lee Farrell
Canon
e-mail: Lee.Farrell@cda.canon.com
David Hall
Hewlett-Packard
Vancouver Division
18110 SE 34th Street
Vancouver, WA 98683
Phone: 360 212 4228
Fax: 360 212 6886
e-mail: dhall@hp.com
Harry Lewis
IBM Printing Systems
6300 Diagonal Highway
Boulder, CO 80301
Phone: 303 924 5337
Fax: 303 924 7434
e-mail: harryl@us.ibm.com
Additional contributors:
Alan Berkema, HP
Elliott Bradshaw, Oak Technology
Tom Hastings, Xerox
Ira McDonald, High North
Gail Songer, Peerless
Jerry Thrasher, Lexmark
Bill Wagner, NetSilicon
Don Wright, Lexmark
Peter Zehler, Xerox