Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!purdue!bu.edu!snorkelwacker!usc!cs.utexas.edu!longway!std-unix From: jsh@usenix.org Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.0: POSIX Guide Message-ID: <626@longway.TIC.COM> Date: 13 Apr 90 04:28:25 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Lines: 183 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.0: POSIX Guide Update Charles Severance reports on the January 8-12, 1990 meeting in New Orleans, LA: Dot zero is producing a guide to the POSIX Open System Environment (OSE). The guide will bring existing and evolving standards together to provide specifications for all aspects of an OSE -- everything from application programming interfaces to user interfaces and system management. It will give users an overview of the 1003, and other, related standards, describe their interrelationships, and help them select the subset of available standards necessary for any particular application. Draft Six Review This meeting, the group reviewed draft six. Points of special interest were: + the formal definition of ``open system'' + internationalization + an editorial review of the entire document to insure a consistent style + a review of some high-level architecture diagrams, proposed to make Chapter 3 (``Overall Architecture'') easier to understand, The only one of these discussed by the entire group was the definition of ``Open System.'' To simplify the definition we created a definition for ``Open Standard'' which was used in the Open System definition. Here is the definition we finally agreed on: Open System: A system that implements sufficient Open Specifications for interfaces, services, and supporting formats which enable properly engineered applications software: a) to be __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.0: POSIX Guide - 2 - ported across a wide range of systems with minimal changes, b) to interoperate with other applications on local and remote systems, and c) to interact with users in a style which facilitates user portability. Open Specification: A public specification which is maintained by an open, public, consensus process to accommodate new technologies over time and consistent with international standards. The group won't define ``user portability'' until next meeting, but the idea is that users should see a consistent interface from application to application, both within and across systems. Public user-interface standards should simplify both user training and vendor documentation. The other issues were handled in small working groups. 1. Internationalization The internationalization group identified parts of the document affected by internationalization and other ``cross-component'' issues, such as system management and security. They promise to present new, draft text for the internationalization sections by the next meeting. 2. Editorial review The editorial review group tackled the no-fun jobs of reviewing the entire draft for style and identifying areas that had too much, or too little detail. Along the way, they proposed a style guide and template for sections of Chapter 4. 3. Architectural overview The architecture group continued work on Chapter 3 to complete the text of the chapter. Also the group worked to simplify the chapter to make it easier to understand. The CCTA (UK) presented a high-level classification scheme called ``MUSIC'' (Management, User Interface, System Interface, Information Interchange, and Communication) as a potential contribution to chapter 3. The chapter will have extensive modifications and additions for the next meeting. Application profiles Next meeting we'll discuss exactly what must be in a POSIX Application Environment Profile (AEP). Profiles will affect and generate procurement issues, so this will be a key discussion. January 1990 Standards Update IEEE 1003.0: POSIX Guide - 3 - Profiles specify a set of standards for specific computing areas, such as supercomputing. Not all standards will be required for all areas; a profile lists the subset of the standards necessary for a particular area. The biggest point of contention in this discussion will probably be whether 1003.1 [Editor: the system interfaces set out in the Ugly Green Book] will be required for all profiles. Should vendors be allowed to advertise compliance to, say, 1003.11 (transaction processing), if they've implemented that standard on an underlying system that doesn't support lower-level POSIX calls like fopen()? (There isn't a standard for 1003.11 yet, but you get the idea.) One argument advanced for requiring 1003.1 is that it will force vendors to adopt it more quickly. I don't think that 1003.1 needs any help in that area. Another is that requiring compliance will insure that vendors who want to advertise POSIX-compliant systems are following the general POSIX direction and not just implementing the simplest standard so they can claim that their system implements ``some POSIX.'' An argument made against the requirement is that it may damage implementations. For example, real-time systems may lack even a file system, and may want a very limited subset of the POSIX interface to keep the implementation as small as possible. If all of 1003.1 is required, vendors may have to add costly and unnecessary features just to claim POSIX compatibility. When the dust settles, I think 1003.1 will be strongly suggested but not required, because 1003.1 is a pretty arbitrary subset of any list of ``required system interfaces.'' [Editor: We disagree. 1003.1 is a set of applications programming interfaces carefully chosen to be necessary and sufficient to make an operating system UNIX-like for the C programmer. Providing standards for a UNIX-like operating system should be the goal of the POSIX standards, and attempts by vendors uncomfortable with UNIX to dilute the effort should be cut off at the pass.] [Author: POSIX must evolve a set of independent standards that have UNIX as their heritage. POSIX standards are all evolving as UNIX-like standards. Why discourage a vendor from implementing some subset of UNIX-like standards just because the vendor is not ready to provide a complete 1003.1 implementation? ] January 1990 Standards Update IEEE 1003.0: POSIX Guide - 4 - Want to go to a POSIX meeting? This was my first POSIX meeting. In case you haven't been and are thinking of going, here are a couple of things you'll want to know. New people and their new ideas, are welcomed. As a practical matter, it helps to stick with a group for the entire week. It's tough to understand much if you come into an advanced discussion, cold, It would help if each group summarized its purpose and listed the big issues at the beginning of each meeting, to get everyone in the proper frame of mind, but that doesn't always happen. Still, you'll be granted a sort of first-time armor to protect you when you ask naive questions or need clarification. For extra insurance, use the phrase ``I will take an action item...'' often. January 1990 Standards Update IEEE 1003.0: POSIX Guide Volume-Number: Volume 19, Number 56