To: SC22/WG15 TCOS SEC Sept 16, 1992 From: Jim Isaak RE: Interpretations Synchronization plan for 1003/9945 work some suggestions References: - SC22/WG15 - IEEE CS TCOS (POSIX) Synchronization plan (SC22 N897; WG15 N121; TCOS SEC N...) - SC22 N1236: ISO/IEC JTC1/SC22 Procedures for Handling Defect Reports Background: ---------- SC22, at their Aug. 92 meeting, concluded a year long ad hoc project to identify how to deal with interpretations of SC22 standards, and the context for synchronization of these with standards where the National Bodies are doing development work under SC22 Administrative resolution assignment. This affects the SC22/WG15 and IEEE TCOS POSIX work, and relates to how Interpretations of the common documents between these groups are handled. Below is an outline of how this process can be synchronized based on the current JTC1, SC22 and IEEE procedures. I would propose that this concept be addressed at the Oct. TCOS SEC and WG15 meetings with the objective of reaching agreement in principle to the concepts, and that an updated Synchronization plan be developed for approval of the appropriate groups early in 1993. (Approval needed of TCOS (April), WG15 (May), IEEE Transcom or CS/SAB (June) and SC22 (Sept.)) SC22 N1236 is a statement of SC22 procedures for defect reports. This is a method for dealing with interpretations that utilizes existing JTC1 mechanisms of "Defect Reports" and "Technical Corrigenda", defining procedures for dealing with these that are focused on this problem space. IEEE has established procedures and constraints on dealing with interpretations, and these need to also be taken into consideration. Here are the key concepts, and suggestions on how to synchronize processes: (areas in N1236 where, in my opinion, synchronization is not needed are not expanded on here. This includes log details, acknowlegements, etc.) 1. Reporting and logging of interpretations requests: 1.1 In JTC1: A request is called a "Defect Report", there is an existing form for submitting these. N1236 specifies that these can only come from a National Body, a Liaison organization (ISO or IEC), an SC22 WG, or the Project Editor, and that these should be submitted to the WG15 convener (in this case), who logs this and initiates the response process. Defect Reports include more than interpretations, so some further categorization needs to be done to cover all cases. 1.2 In IEEE: A request for Interpretation is sent by any interested party to the Secretary of the IEEE Standards Board, this is forwarded by the IEEE Standards Department to the TCOS SEC Vice Chair for Interpretations (in this case), who logs this and initiates the interpretations process. 1.3 Synchronization issues: 1.3.1 All IEEE interpretations requests need to be forwarded to WG15 which can be done either though the U.S. National Body or via the Project Editor, as Defect Reports. 1.3.2 All WG15 Defect reports which warrant treatment as interpretations and are not IEEE interpretation requests, need to be forwarded to IEEE as requests for interpretation. Since the WG15 Convener is an interested person, this can be done directly by the convener. 2. Developing a response 2.1 in WG15: N1236 calls for the WG to develop and approve a response to the defect report. 2.2 in TCOS: The appropriate Interpretations Subgroup develops a response on which they must concur. It is important to note that IEEE "interpretations" are not permitted to make normative changes in the text of the standard. (Editorial corrections are possible). For normative changes, a supplement or revision process needs to be initiated, and this would follow the existent synchronization plan. 2.3 Synchronization suggestions: 2.3.1 WG15 can request that the IEEE group provide a recommendation on all interpretations, then take action on these recommendations. 2.3.2 Interested WG15 experts can participate in the applicable Interpretations Subgroups. These groups do most of their work by electronic mail, which should simplify some of the travel and time zone issues. It may be useful to have "observers" in this context, who are not expected to be part of the IEEE "concurrence" process, but can help National Bodies to take advantage of that dialogue at the WG15 level. 3 Publication Process 3.1 In JTC1 Defect report responses can be batched together, and submitted to SC22 for publication as "Technical Corrigenda" by WG15. Technical Corrigenda must change the text of the standard. [N1236 also identifies a "Record of Response" document that can be used by SC22 to publish responses to Defect Reports that do not result in changes to the standard.] 3.2 In IEEE All interpretations are published on a regular basis to insure that these are visible to all interested parties. 3.3 Synchronization suggestions: It is important that the IEEE interpretations publication have a JTC1 counterpart with identical text, and ideally with the same sequence, etc. The "Record of Response" document could be used, although it does not have JTC1 standing/visibility/publication. An informative annex could be maintained in each standard that accumulates the interpretations responses over time. Since changes to this annex are "changes to the standard", the JTC1 Technical Corrigenda process is applicable. Since changes to this annex are not normative, this is consistent with the IEEE interpretations process. As re-printing of the standard occurs, the annex would include the interpretations to date, and prior to that time, would be available as a separate document. 4. Incorporating normative changes to the standards as a result of interpretations or Defect Reports. 4.1 in SC22 Normative changes could be made via Technical Corrigenda, however, the traditional synchronization process (revision and ballot at the IEEE level) would be needed. Certainly all recommendations for changes out of the process need to be referred to the U.S. Member body for consideration as part of the revision process, with whatever guidance WG15 wishes to provide. 4.2 In IEEE Interpretations responses are forwarded to the responsible working group for consideration in future revisions of the standard. 4.3 Synchronization suggestions: Since interpretations would have been forwarded though IEEE in all cases, these would already be directed to the applicable working group. Other Defect Reports need to be distributed to WG15 members, and the U.S. Member Body should make these available to the applicable working groups as well. Given this process, the appropriate synchronization activities are for WG15 to provide guidance to the U.S. with respect to Defect Reports, and track these against future revisions to make sure they are handled in an appropriate way. 5. categorization of Defect Reports Unfortunately, the JTC1 form for Defect Reports (Form 14) item 8 "Qualifier (e.g. Error, omission, clarification required)" does not provide a fully enumerated list of options for the submittor. However, these three should be able to cover most submissions 5.1 Suggestion for categorization/initiation of action: In all cases, it is my hope that the convener can provide some initial categorization as part of the defect report logging process, and indicate in distribution to WG15 and the submitter what course of action is implied by that categorization. If the submitter, or any WG15 National Body feels a Defect Report should be treated as an interpretation, I would suggest it be re-classified as such and the interpretations process followed. (This can be used to make sure the report and response are made visible in the interpretations publication.) 5.1.1 - Error There are a few forms that we can anticipate: - editorial error - which can be corrected as noted above, these would be referred to the Project Editor, and with a recommendation that the U.S. National Body initiate an editorial correction in the appropriate manner. The response in this case would be "referred to Project Editor for appropriate correction." [No further feedback to submitter.] - Un-ambiguous reporting of an error, hopefully accompanied by a recommended change to the document. Here, the Submitter, and presumably WG15 experts, do not question the interpretation or clarity of the standard, but the assertion is made that it is not correct. Correction of such an error requires normative changes, and could either be incorporated into a revision or amendment in progress, or a new amendment initiated. Response: "referred to working group for consideration as an amendment or in a future revision." [No further feedback to submitter.] - Errors where there is a question of clarify or interpretation will be treated as interpretations. Response to interpretation will be forwarded to submitter upon WG15 approval. - Omission (Or request for additional capabilities) will be submitted to WG15 for consideration in the next revision of the document. Response: "referred to working group for consideration as an amendment or in a future revision." [No further feedback to submitter.] - Clarification/Interpretation: will be treated as interpretations. Response to interpretation will be forwarded to submitter upon WG15 approval. - Others: will be re-classified into one of the above if possible, if not: referred to WG15 for guidance and subsequent response sent to the submitter. Subject: SC22 N1236 1 Introduction 1.1 Purpose The purpose of this document is to set forth the procedures by which Defect Reports, including requests for interpretations, are handled by ISO/IEC JTC1/SC22 (SC22). 1.2 Scope These procedures conform to and amplify the requirements and definitions specified in the ISO/IEC JTC1 Directives (6.13). They span the full range of documents originated by SC22, including standards and technical reports, The procedures cover all aspects of SC22 processing including: a) flow of documents b) development and approval c) publication d) synchronization with member body activity 1.3 Guiding Principles Several principles have given rise to these procedures. They have been derived from comments made to documents distributed within SC22 and from the JTC1 Directives. These principles are: a) Identification - All requests for interpretation identify some lack of clarity in the document, and as such these can be viewed as one form of Defect Report, and can be addressed under the defect resolution procedures in accordance with the JTC1 Directives and this document. b) Technical Content - The SC22 working group (SC22/WG) that is responsible for the document for which a Defect Report has been received is responsible for the development of the response. c) Responsiveness - The process should be sufficiently rapid as to allow as little time as possible to pass between the time of receipt of a Defect Report and the time the requestor receives an interim response. d) Visibility - The procedures should provide for appropriate visibility of the response to the reported defect among all users of the document. e) Stability - Substantive changes should be made to a document only when demonstrably necessary to correct a significant defect. Frequent or gratuitous changes may complicate compliance and synchronization with other documents. f) Limitation of Scope - These procedures do not grant SC22/WGs license to make substantial alterations to the functionality described by a document. 2 Submitter Procedures This section identifies sources for Defect Requests, and the actions to be taken by the submitter. 2.1 Sources of Requests Defect Reports may be submitted only by: a) a National Body of ISO or IEC b) an SC22/WG c) the project editor for the document d) an organization in liaison with ISO/IEC 2.2 Submission Procedures The submitter of a Defect Report shall prepare and submit ISO/IEC Form 14 (see attachment 1) in accordance with the instructions on the form. 3 Processing This section details the processing of a Defect Report, and assigns specific respon- sibilities to SC22/WGs and to SC22. The SC22 working group (SC22/WG) that is responsible for the document for which a Defect Report has been received is responsible for the development of the response. 3.1 Overview The responsible SC22/WG shall develop the response to a Defect Report. It shall maintain a log of all Defect Reports and their responses. The response to the Defect Report shall result in a contribution either to a Technical Corrigen- dum (TC) or to a Record of Response. a) Handling Requests Without a Responsible WG Where no SC22/WG exists with responsibility for a document that is the subject of a Defect Report, SC22 shall establish an ad hoc group to act as a WG for the purpose of developing a response. This group shall perform all of the actions required by a SC22/WG according to these procedures. Results shall be recorded by the SC22 Secretariat which shall maintain a Defect Report Log for each document for that purpose. 3.2 SC22/WG Actions The SC22/WG Convener is responsible for ensuring that all SC22/WG actions specified by these procedures are performed by the SC22/WG. a) Tracking Each SC22/WG shall maintain a log of Defect Reports for each of its documents as required by the JTC1 Directives (6.13.3.7). Each entry in this log shall include: i) the unique Defect Report number assigned by the SC22/WG, ii) full identification of document numbers (including CCITT referencs in joint projects) iii) status of the Defect Report, iv) date when submittal occured, v) date when response is required, vi) date when ballot terminates, vii) date of publication of response to the Defect Report. The interim response to the submitter, and all other correspondence on this Defect Report, shall include the unique Defect Report number. Maintaining the following additional information may prove useful to the SC22/WGs: i) description of reported defect ii) response iii) references within the document, and references to other relevant documents iv) classification (per internal SC22/WG classification scheme) The Convener shall submit the up-to-date Defect Report index to the SC22 Secretariat immediately before each SC22 meeting. b) Developing The responsible SC22/WG shall develop a response to the Defect Report, in accordance with these procedures. Once the SC22/WG has approved the response to the Defect Report, the SC22/WG shall forward an interim response to the submitter. This response should refer to the original submitter's correspondence, include the SC22/WG identification number, and the response to the Defect Report. This response should also make clear that this is an interim response, and a final response must be approved by SC22. c) Publishing For each document, the responsible SC22/WG shall construct responses to Defect Reports as follows: i) Responses requiring normative changes to a document shall specify the textual amendments to be applied. ii) Responses not requiring normative changes may specify textual amendments to an informative annex. Responses requiring textual amendments, as deemed necessary by the responsible SC22/WG, shall be incorporated into a Technical Corri- gendum, for publication by SC22. Where the response to a Defect Report is not incorporated into a TC, it shall be incorporated into a Record of Response, for publication by SC22. d) Batching A Technical Corrigendum or a Record of Reponse may include responses to several Defect Reports. The content and timing of publication is the responsibility of the SC22/WG. Any batching shall take into account the number and significance of the responses and the SC22/WG's plans for revision of the document. e) Distribution Once the resolution has been approved by SC22, the SC22/WG shall send to the submitter of each Defect Report, under cover of a final re- ply letter, a copy of the approved response to that Defect Report. SC22 Actions The SC22/WG shall forward draft Technical Corrigenda to the SC22 Secre- tariat, requesting a letter ballot by SC22 and simultaneous distribution to JTC1 for review and comment on the draft Technical Corrigenda by those P- Members of JTC1 that are not P-members of SC22. The SC22/WG shall forward draft Records of Response to the SC22 secretariat, requesting a default letter ballot with a seventy-five day response time. Distribution of the TC or Records of Response shall be accomplished by the SC22 Secretariat consistent with ISO/IEC JTC1 Directives and SC22 procedures. 4 Synchronization This section ensures that Defect Report resolutions to SC22 Standards and Technical Reports are handled the same in the national bodies. This is of particular importance for those SC22 documents that were developed by SC22 member bodies. 4.1 Member Body Development For those SC22/WGs that use national body development, the SC22/WG shall recommend to SC22 those changes to its synchronization plan which accommodate the handling of Defect Reports. SC22 shall review and approve those changes. The same changes are required to be approved by the appropri- ate National Body organization.