Committee Maintenance Procedures for the Approved Standard
Document Number: AUSTIN/112r3
Revision Date: 2009-08-07
Source: Andrew Josey, Chair
Action: for information
112r1: Initial updates after review.
112r2: Minor updates to remove references to WG15.
112r3: Updates to switch defect reporting to using Mantis/
The purpose of this document is to describe the operational procedures
for the Austin Group's maintenance of its set of consensus
This includes how defect reports are generated and accepted, production
of responses to 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. Defect reporting is online using a Mantis defect tracker at
For advice on defect reporting please see
4. All members of the review
group for defect reports should be on the main Austin Group
reflector. All inbound defect reports are sent to the main reflector.
Please keep primary discussion of issues concerning the
Specifications on the Mail List. Add notes to a defect report only for
cogent and specific information.
5. All defect reports shall be submitted electronically using the defect tracker at
Select an appropriate "Project" for the bug report.
Defect reports must refer to a final approved standard, or proposed technical corrigenda (when available).
If you feel there is a problem with the defect tracker select the project "Aardvark Bugs"
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 are made publically available at the Austin Group defect tracker 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 defect comment and record a disposition
Accepted As Marked
A rationale is recorded with each defect report for rejected or partial changes.
7. During a review meeting,
updates are made in the defect tracker to record the decisions made in
the meeting. The defect tracker sends details of these changes to
the main Austin Group reflector.
8. It is the responsibility of
individual reviewers to check the updated defect reports (or query the
defect tracker system) to find out the disposition of their individual
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, or submit an
additional comment into the defect tracker system.
Part 2 - Defect Reporting Response
Everything starts out as a defect report, unless raised during a plenary session when the ORs are present.
There are four possible outcomes to a defect report :
1.The committee agrees with the defect report and is proposing a change for inclusion in a technical corrigenda.
2.The committee agrees with the 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 defect report should be the "Future Enhancement" resolution
4.No action arising , the response to the 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.
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
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.
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
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
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.
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 standard 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
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
appropriateinterpretation. The Requester is asked to submit a rephrased
or more specific request."
New Work Items
From time to time, a 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 a 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,
ISO/IEC) 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
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, ISO/IEC) 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