Document Number: AUSTIN/112r1 Title: Committee Maintenance Procedures for the Approved Standard Revision Date: 2002-05-21 Source: Andrew Josey, Chair Status: SUPERSEDED BY AUSTIN/112r2 Action: for information Purpose The purpose of this document is to describe the operational procedures for the Austin Group's maintenance of its set of consensus specifications. This includes how aardvark defect reports are generated and accepted, production of responses to aardvark defect reports, including production of technical corrigenda, interpretations and a policy on new work items proposed for a future revision. This document does not define how the participating organizations will ballot any resulting corrigenda or publish interpretations/defect reports. The intent is that the outputs will be suitable for entering into the formal process (the Joint Procedures Committee document should be consulted for further information). ----------------------------------------------------------------------- Part 1 - Defect Reporting Procedures 1. PARTICIPATION IS ELECTRONIC. THERE IS NO PAPER. 2. The final standard can be obtained from sponsoring organizations in electronic format . There is also a html version freely available on the world wide web. Proposed technical corrigenda, when available, will be available with line numbers for the purpose of review. 3. The defect reporting format is the Aardvark format. (see URL http://www.opengroup.org/austin/aardvark/ ) Tools are provided to generate Aardvark format comments (a C tool and a web page) Defect reports that do not follow the required format for aardvark need not be accepted at the Chairs discretion. 4. All members of the review group for defect reports should be on the review reflector, which is a separate reflector to the general austin-group discussion list. The purpose of the review reflector is for submission of comments in aardvark format. The review reflector is not a general discussion list. Additional participants may join the review reflector at any time and participate in defect report reviews. 5. All defect reports shall be submitted electronically to the review reflector in the Aardvark format, including the following subject line Subject: Defect in (Note that a Subject line of "BUG" in place of "Defect" is also acceptable) Where can be one of XSH XCU XBD XRAT These must refer to the final approved standard, or proposed technical corrigenda (when available). Additional names will be added for the technical corrigenda when available. The full aardvark submission format is described at http://www.opengroup.org/austin/aardvark/ It is important that the guidelines be followed. The Chair has the discretion to reject aardvarks that do not follow the guidelines. The approved standard includes line numbers which should be used when submitting defect reports. In the absence of the line numbers, for example if using the html version, exact URLs and a description of the paragraph number within a subsection are needed to identify the problem. All review comments shall be collated and made publically available on a web page as they come in. Reviewers should ensure that they are familiar with the detailed scope of the project when submitting comments. 6. A review resolution meeting shall occur periodically to review the defect reports. For those who submit comments you are urged to attend the review resolution meeting or to be available via email and/or telephone during a meeting to respond to any queries related to your review comments. [Note that this means that meeting hosts should be willing to provide telephone connectivity for voice and data communications] The meeting shall review each aardvark comment and record a disposition Accept Accept as marked below Duplicate Reject A rationale is recorded with each aardvark for rejected or partial changes. 7. After a review meeting, a change request report shall be sent back to the main Austin Group reflector. 8. It is the responsibility of individual reviewers to check the change request report to find out the disposition of their individual review comments. If a reviewer disagrees with the disposition he or she should (1) either raise it with his or her Organizational representative or (2) raise it during the next review resolution meeting. ----------------------------------------------------------------------- Part 2 - Defect Reporting Response Everything starts out as an aardvark defect report, unless raised during a plenary session when the ORs are present. There are four possible outcomes to an aardvark defect report : 1.The committee agrees with the aardvark defect report and is proposing a change for inclusion in a technical corrigenda. 2.The committee agrees with the aardvark defect report and is proposing to enter the report and response into the interpretations process. 3. This appears to be a new work item and is thus out of scope of maintenance, and cannot be addressed through technical corrigenda or interpretation. The response to the aardvark defect report closes this item. 4.No action arising , the response to the aardvark defect report closes this item. The rest of this section describes the criteria for technical corrigenda, the interpretations process, and recommendations for how new work items are addressed. Technical Corrigenda A technical corrigenda item can change the meaning of the standard, as such all technical corrigenda require formal approval by the sponsoring organizations (usually through a formal ballot process). The following are the criteria for a Technical Corrigenda (TC) item: a. It has to be in the scope of the original Austin Group project. (see http://www.opengroup.org/austin/docs/austin_9r6.txt) b. It should be non-controversial ( a TC is intended to pass ballot at the first attempt) c. It contains no new APIs (functions/utilities), however it may add enumeration symbol and non-function #defines and reserve additional namespaces. d. Typically a TC is used to fix contradictions between different parts of the standard, add consistency between the standard and overriding standards, and to fix security-related problems. Interpretations Interpretation processing occurs concurrently as part of processing defect reports. It is important to make sure that any interpretation has received the concurrence of a balance of interests. For this reason, the Austin Group is not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. An interpretation does not change the meaning of the standard. Notes to the editor (not part of the formal interpretation) are expected to be considered in the next revision of the standard. An interpretation may be controversial. Interpretation requests are reviewed and evaluated by an official interpretations group (the Austin Group reflector). The following set of guidelines are provided to ensure requests are processed appropriately. There are three over-riding rules related to interpretations: Rule 1) THE STANDARD IS WHAT IT SAYS. The words actually approved by the balloting group reflect the requirements set forth by that document. If the words are substantively wrong, then corrective action can be taken via the technical corrigenda process with the full backing of the consensus process. Interpretations must be a comment on what the standard actually does say, not what it should say, nor what it says incorrectly. These are mechanisms for quick revision of the standard (TC), and these must be used to make changes to "how things should be". Rule 2) If THERE IS AMBIGUITY in what the standard calls for; then interpretations must favour a looser conformance requirement rather than a more restrictive one. This will allow some "weirdnix" implementations to conform to a current standard. Again, corrective action can be taken via the technical corrigenda process and eliminate this ambiguity with the full backing of the consensus process. Rule 3) If THERE IS A CONTRADICTION between two sections of the standard, and there is reason to believe that one part is correct, then the rationale should be elucidated and the technical corrigenda process applied. Pro-forma responses In order to follow the guidelines, interpretations make use of the following pro-forma responses to guarantee uniformity of the process. Note, stating the conformance implications is important, and offers a way to distinguish between requirements placed on implementations, applications, and test methods. 1.THE UNAMBIGUOUS SITUATION: "The standard clearly states....,and conforming implementations must conform to this" 2.THE "DEFECT" SITUATION (i.e. the balloting group appears to have gotten it wrong): "The standards states..., and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor." 3.THE AMBIGUOUS SITUATION: "The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." 4.THE UNADDRESSED ISSUE: "The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." 5.CONDITIONAL INTERPRETATION BASED ON OTHER STANDARD(S): "The required behaviour of this xxx standard is dependent on the requirements of the yyy standard. If yyy requires aaa then xxx requires bbb, whereas if yyy requires ccc then xxx requires ddd. A request for interpretation of the yyy standard is being forwarded to the yyy committee." 6.SUBSTANTIALLY IDENTICAL TO PREVIOUS INTERPRETATION: "This request is substantially identical to interpretation #aaa, and the resolution of that interpretation applies in this case." 7.SUBSTANTIALLY IDENTICAL TO PRIOR REQUEST, BUT WITH CRITICAL NEW PERSPECTIVE: "This request is substantially identical to interpretation #aaa, however in considering it appears that the previous interpretation should be superseded. The current interpretation for this situation, (which does affect the previous conclusion) is...". In this case an attempt should be made to notify the previous requester. 8.REQUEST FOR INTERPRETATION OF A DIFFERENT DOCUMENT (draft..): "This request is for interpretation of xxx, the approved standard is yyy, the requester is asked to re-submit this request if the question(s) are still pertinate to the approved standard." 9.REQUEST IS UNCLEAR : "This request is not sufficiently clear to permit an appropriate interpretation. The Requester is asked to submit a rephrased or more specific request." New Work Items From time to time, an aardvark defect report may propose new work items that are outside the scope of maintenance of the Austin Group specifications. This section addresses how these are handled. The Austin Group is not a development body for new material apart from integration issues arising from the merger of the approved standards that were the Base documents into the revision. The Austin Group expects to take a similar approach for a future revision. Thus if an aardvark defect report raises the possibility of new interfaces for inclusion, the standard response will be that it is out of scope for either a TC or Interpretation, and that if the new material were to meet the some criteria it may be considered for inclusion in a future revision subject to the agreed scope determined at that time, although there is no guarantee. The recommended criteria for development of new interfaces to enable them to be considered for inclusion in a future revision are as follows: 1.There must be a written specification that has undergone a formal consensus based approval process and is suitable for inclusion. Parties interested in submitting new work items through one of the three organizations within the Austin Group (The Open Group, IEEE, WG15) should contact the appropriate Organizational Representative for further information and advice on how each organization handles new work items. Submissions from other organizations will also be considered. Items 2 through 4 below apply to all submissions regardless of origin. 2.There must be an implementation, preferably a reference implementation. 3.The specification must be "sponsored" by one of three organizations (The Open Group, IEEE, WG15) within the Austin Group, i.e. they would support and champion its inclusion. 4.Submitters must provide an outline plan of the editing instructions to merge the document with the Austin Group specifications, and assistance to the Austin Group editors as required to complete the merger. For an example, see http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=434