Document Number: AUSTIN/118 Title: XBD/ft/2 Aardvark Change Request Report Revision Date: 2002-06-26 Source: Andrew Josey, Chair Action: for review This report contains the draft dispositions of the aardvark comments submitted against the XBD/ft/2 (2nd batch of FT aardvark) text. Aardvark Summary Table ______________________ ERN 1 Accept as marked ERN 2 Accept _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 SHwareSyst@aol.com XCU (rdvk# 2) {020617-01} Tue, 18 Jun 2002 01:58:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is not seen as a problem with the existing text, no action is required. We had considered document style and synced with the various editors including ISO at various stages, and even recently they ITTF did not identify this as a problem - now the doc is registered as FDIS. However we will consider how to summarize options better for a future revision. _____________________________________________________________________________ Page: 1 Line: 1 Section: 1, Problem: Defect code : 1. Error XBD ERN 38 raised a problem of inconsistency of usage of margin codes to map appropriately the scope of an Option Identifier in unistd.h and other Option Labels in other parts of XBD with the appropriate content in other portions of the standard, as exemplified in the Conformance Requirements Section. This aardvark is to change the classification to objection from editorial, rather than just continue ERN 38. My research indicates the Action proposed in ERN 38, suitably formatted and cross- referenced, is required for the standard to satisfy an overriding standard, the ISO Directives, and a few guidelines. I feel the use of a TC item that addresses this mandate can be held as the standard being fully compliant, at least in spirit, rather than forcing a mandatory thumbs down vote so the work needed for it to qualify both in spirit and to the letter may be completed, with the attendant time delay. To what extent this problem may deviate from IEEE standards I have not investigated. For some reason, my web client setup and their server appear to be incompatible, so I cannot access any content that is nominally no-fee material. As I am not an IEEE member, the members only areas are certainly not accessible to me, as are OpenGroups and ISOs member areas. To wit, The ISO Directives, Part 2, currently Edition 4, specifies the format a draft standard shall have for it to be acceptable as a valid submission for voting approval. Given the complexities inherent in the merging of the prior standards, each of which was satisfactory in themselves to their sponsoring organizations, I can only see that the combination as currently formatted does not match what is permissable leeway to a standard of this complexity by the ISO; and somewhere along the way sight was lost that it was divergent. That the Directives are not listed as either an informative or normative reference leads me to believe they were presumed to have been satisfied by use of the ISO templates, not verified as such in the planning phases of the document - a case of the forest being lost for the trees, as it were. The templates are listed as a starting point for compliance, however, not a guarantor. The standard is complex enough, with multiple layers of Optional Requirements, that it requires and devotes an entire Section to the Requirements Clause, which is nominally an Optional Element. This Clause is formatted in a manner the Directives deems shall NOT be acceptable, and is lacking required content as well! The entire document is formatted incorrectly also, as it does not support the mandates placed on this Clause to enable standard cross-referencing to be used. Rationale: >From ISO Directives, Part 2: --- begin quote --- 6.3.3 Requirements This element is optional. If present, it shall contain the following: a) all characteristics relevant to the aspects of the products, processes or services covered by the document, either explicitly or by reference; b) the required limiting values of quantifiable characteristics; c) for each requirement, either a reference to the test method for determining or verifying the values of the characteristic, or the test method itself (see 6.3.5). A clear distinction shall be made between requirements, statements and recommendations. --- snip --- 6.6.7 References 6.6.7.1 General As a general rule, references to particular pieces of text shall be used instead of repetition of the original source material, since such repetition involves the risk of error or inconsistency and increases the length of the document. However, if it is considered necessary to repeat such material, its source shall be identified precisely. References shall be made in the forms indicated in 6.6.7.2 to 6.6.7.5 and shall not be made to page numbers. --- end quote --- The main area where the Conformance Requirements Section does not match these Requirements is that the notion "Everything not an Optional Requirement is a base Requirement" is an Inference, not a Reference or Explicit List of the Characteristics of the base Requirements, that forces a reader to disambiguate recommendations and statements from Requirements. The use of option identifiers and respective margin codes as a means of specifying References to Optional Requirements is inherently contrary to the formats 6.6.7 dictates SHALL be used. The margin codes, structurally, are only an Informative Element, not a Normative Element usable as a Reference. They would be valid Abbreviated References if there were some item specifying all Sections where the Optional Requirement each denotes is used. The corollary is everywhere a Margin Code currently appears requires a section number suitable for cross Part references. For those places where codes appear in the middle of sentences, those sentences require rewording. The only real option is to get a formal dispensation of the Directives from the ISO Secretariat, and incorporate this as part of the Foreward to XBD. In the interests of allowing other standards to easily reference this one, however, if it were up to me I would disapprove granting such a dispensation. I would allow, as stated above, that a commitment to incorporate the fix into TC1 by the sponsoring organizations may let a thumbs up vote based on the other merits of the content be granted. This is a case where context matters almost as much as content, though, because it must be considered within a larger context than just the confines of the document. That it defers much of its base Requirements to ISO 9899:2001 is the most prominent example; that XCURSES defers to it wholly as it's primary normative reference the other. Commentary: Another matter brought out by the discussion on XBD ERN 38 I feel should be mentioned is Part 1 of the ISO Directives specifies that resources needed to accomplish the work of formatting and drafting a standard shall be allocated or acquireable by the sponsoring organizations prior to commencement of the work, and it is up to them to insure that work is done in a timely fashion. It is not the responsibility of the target audience to allocate their own resources to do this work on their behalf. Thus, the argument resources aren't available to perform this work is disallowed, despite the scope of the change and attendant increase in size of TC1. In my case, even if I wanted to allocate the full resources needed to do this aspect of the work, I don't have or can acquire all of them to satisfy the Directives, Guidelines and Standards of ISO, IEEE, and OG. I can provide ad hoc recommendations, nominally, as I have been doing and which this aardvark is also, based on my prior experience in drafting smaller standards that conformed to other Directives, but it's not incumbent or even legitimate for me to do more. Action: I defer to the ISO Guidelines that aren't available gratis as to how these recommendations should be finalized by the editorial team. Without these, anything definitive I might propose would be very lucky to not be controversial in some aspect. While the format outlined in ERN 38 for which tables should be included was off the cuff on my part, and based more on the standard of prior industry practice, it does match fairly well with what the Directives and ISO Guide 2 mandate as Titles for the types of Requirement as it pertains to the standard. The format of each table can follow that of APIs.html, with an additional "column" for relevant section numbers. At the least, I feel section numbers for each header, interface and utility shall be assigned. I'm ambiguous on whether subsections must be assigned numbers also, but they should be to better pinpoint references. I feel it would be useful if additional subsections, like environment variable and structure usages, were collated by requirement type also. The margin codes abbreviations reference should include cross-references to sections also, and may take the place of the additional "column", perhaps. Codes for mandated, normative, and previously optional requirements should be created and applied, to satisfy consistency of usage requirements, and satisfy better the split of requirement text from recommendations. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 2 wollman@lcs.mit.edu Defect in XBD (rdvk# 1) {GAW-2002d} Tue, 11 Jun 2002 20:06:52 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 360 Line: 12795 Section: Problem: Defect code : 1. Error The text states ``ST_NOSUID Does not support setuid( )/setgid( ) semantics.'' setuid() and setgid() act upon processes, not files or filesystems. Action: Replace with: ST_NOSUID Does not support the semantics of the ST_ISUID and ST_ISGID file mode bits. [Ed recommendation: TC1 candidate]