Standards Update, IEEE 1003.0: POSIX Guide

[jsh at usenix.org]

From: <jsh at usenix.org>


            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 <crs at convex.cl.msu.edu> 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