From rjmartin@eng.Sun.COM Tue Dec 23 19:18:43 1997 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id TAA09063 for ; Tue, 23 Dec 1997 19:18:42 +0100 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA13638 for ; Tue, 23 Dec 1997 10:18:10 -0800 Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id KAA08961; Tue, 23 Dec 1997 10:18:07 -0800 Received: from rjmartin.eng.sun.com (dhmpk17-088-007 [129.146.88.237]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id KAA09572; Tue, 23 Dec 1997 10:18:07 -0800 (PST) Message-Id: <3.0.32.19971223101215.0074754c@jurassic.eng.sun.com> X-Sender: rjmartin@jurassic.eng.sun.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Dec 1997 10:14:40 -0800 To: sc22wg15@dkuug.dk From: Roger Martin Subject: re: (pasc-gen 181) Future of POSIX Cc: rjmartin@jurassic.eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Dec 1997 13:00:39 -0800 To: pasc-gen@pasc.org From: Roger Martin Subject: (pasc-gen 181) Future of POSIX I support the proposed resolution regarding no further amendments to POSIX.1 and POSIX.2 We must stabilize the POSIX.1 and POSIX.2 standards as the base functionality and address each new standard as an expansion of the POSIX family of standards, not as extensions and changes to the base. When POSIX.1-1990 was adopted, it was embraced and implemented by all of the major vendors and became part of the baseline of technology for the industry (even Windows NT claims POSIX.1 conformance). Subsequently, the POSIX.1-1996 was accepted and incorporated into existing products. However, every time we have amended POSIX.1 we have broken the existing specification which has necessitated the creation of another PAR to fix the newly created bugs. POSIX.1-1996 has bugs, but it is stable and has been implemented by the major vendors. We need to make the necessary "bug" fixes, but we should not destabilize it further by making more extensions to it. The current crop of planned amendments have differing styles and target audiences. Forcing them into POSIX.1 will, in my opinion, not only destabilize POSIX.1, but also existing implementations and applications. It is time to draw a line under POSIX.1 and POSIX.2 as proposed in the draft resolution. ******************************************************* Additional notes/comments: (1). As Jim Isaak pointed out, this debate is not about limiting what becomes part of the POSIX family of standards, but rather is about stabilizing the existing POSIX.1 and POSIX.2. (2). Some of the issues which have been identified in the discussion to date include: 1. How will future standards be built with respect to their relationship to POSIX.1 and POSIX.2? 2. How will PASC ensure that future POSIX standards do not break POSIX.1 and POSIX.2? 3. How will defects be handled? 4. Should some of the existing work in progress (e.g. .1a, .1h, .1j, .1d, .1q) be "grandfathered in" and be completed as amendments? 5. What is the business case (cost-benefit) for going forward with this proposal? I suggest that we establish different threads of discussion for each of these issues (and any other issues which are raised) but carry the entire discussion out via both the pasc-gen and pasc-sec lists. It is important that we go into the Ft. Lauderdale meeting in January with either strong consensus or well-reasoned viable alternative choices. In my opinion, it is essential that we leave the January meetings with firm, workable decisions ... resolution of this issue must not be further delayed or postponed. (3). WG15 has also expressed concern/interest in this debate, so I will encourage interested WG15 participants to contribute to this discussion. ******************************************************* ....roger martin