Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v22/092/text0000.txt

Text File | 1991-03-07 | 12.9 KB | 404 lines

Submitted-by: [e-mail] (Dominic Dunlop)


            Standards Column to be Published in
              EurOpen Newsletter, Spring 1991

              Dominic Dunlop -- [e-mail]

                  The Standard Answer Ltd.


     Production of this article was funded by EurOpen,
     the European Forum for Open Systems (formerly
     EUUG).  Copyright EurOpen, 1991.


For the past couple of years, these columns have discussed
events and developments in the POSIX-related activities of
the International Organization for Standardization (ISO).
This time, I'm going to look at a lower -- but arguably
equally important -- level in the standards development
process: the Institute of Electrical and Electronic
Engineers' Computer Society Technical Committee on Operating
Systems Standards Subcommittee.  Let's just call it
IEEE-CS TCOS SS, or, better still, TCOS.

Last October, EurOpen agreed to provide funding for an
institutional representative who would attend the quarterly
meetings of TCOS, and provide a means of routing input from
European users of open systems into the bewilderingly large
variety of POSIX standards being developed by working groups
under TCOS.  I am that representative, and, since I'm
spending your money, I'd better tell you what is going on,
why it's important, and how you can help me out.

        POSIX_Development_--_Top_Down_or_Bottom_Up?

I've referred to the IEEE in my reports on ISO matters,
since it is the IEEE which actually develops the standards.
The IEEE routes its documents to ISO via ANSI, the American
National Standards Institute.  Translating this into ISO-
speak, ISO has designated ANSI, its U.S.  member body, as
the development agency for the POSIX standards.  ANSI, in
turn, has delegated the work to the IEEE, an accredited body
which it considers competent to create operating system
standards through a consensus process which allows all
interested parties to comment.

This makes the process of standards development look as
though it proceeds from the top down: somebody associated
with ISO decides that the time is right for a POSIX
standard, identifies a means of getting the job done, and
controls the process in an orderly, structured manner.

Life is not like that.  No matter how much those who work at
the ISO level would like to believe that they are, and
always have been, in the driving seat, the movement towards
POSIX started from the bottom and drifted up.  It started in











                           - 2 -



the early nineteen-eighties with /usr/group, a U.S.-based
organization of suppliers and commercial users of open
systems, now known as UniForum.  This group created The 1984
/usr/group Standard, a minimal definition of an operating
system interface corresponding broadly to the unprivileged
services offered by AT&T's UNIX System III, together with
selections from the Kernighan & Ritchie C language library.
Slim but seminal, this document was passed into the IEEE
(specifically, to the newly-formed TCOS) to provide the
foundation of the POSIX standards.  It also gave important
input to ANSI in the creation of a standard for the C
language.

Despite the fact that neither the IEEE nor ANSI puts any
nationality requirement on the individuals (in the case of
the IEEE) or the organizations (for ANSI) participating in
the creation of their standards, both POSIX and C initially
developed in the U.S. with little international input.  The
costs of travel and of assigning English-speaking technical
experts to the task was (and is) one disincentive; another
is the feeling, particularly in Europe, that standards
activity should begin at home, rather than in the U.S.

By 1987, the international demand for standards for POSIX
and C was obvious, and it was natural that ISO should get
involved.  To be pedantic -- and the standards world is
nothing if not pedantic -- it was natural that Joint
Technical Committee 1 (JTC1) of ISO and the International
Electrotechnical Commission (IEC) should get involved.
(JTC1 had been formed in the mid-eighties to end wrangles
between ISO and the IEC over the right to create standards
for information technology.)  It was also natural that the
project for the international standardization of the C
language should be handled by JTC1's Subcommittee (SC) 22,
which is concerned with programming languages.  SC22 Working
Group (WG) 14 was duly set up to do the job.

It was less natural for POSIX to be assigned to WG15,
another new group under SC22.  An operating system
interface, after all, is hardly a programming language.
Nevertheless, after an attempt to set up a new SC to handle
system interfaces had failed for political reasons, SC22
picked up the work1.  Both WG14 and WG15 appointed ANSI as


__________

 1. SC21, which is responsible for the higher layers of OSI,
    for SQL and for office document architectures and the
    like, might have been a candidate, but, after a false
    start with OSCRL (see my last column), was not











                           - 3 -



the development agency for their respective standards,
leaving us with today's situation.

At this point, I shall have to stop discussing C
standardization, as it is not a field in which I am active2.
But I can tell you more than you probably want to know about
the activities of IEEE TCOS, which is at the work-face of
POSIX development.

                     POSIX_in_the_IEEE

When TCOS was set up in 1985, it had just one IEEE standards
creation project under its control -- project 1003, known as
P1003.  (Other well-known IEEE standards projects are 754
for floating point formats, and 802 for local-area
networks.)  P1003 quickly split into two sub-projects:
P1003.1 for the operating system interface, and P1003.2 for
the shell and tools.  (Recently, these have come to be known
as POSIX.1 and POSIX.2.)  A working group was associated
with each.  The working groups were named after the
projects: 1003.1 and 1003.2.

This splitting has continued, with around 30 projects
currently active.  Whenever a possible new POSIX-related
standards activity is identified, its promoters can draw up
a Project Authorization Request (PAR), and submit it to the
Sponsor Executive Committee (SEC) of TCOS3.  If approved
(sponsored in IEEE terminology), and subsequently rubber-
stamped by the  IEEE Computer Society's Standards Activities
Board (SAB), a new project is created.  Most become sub-
projects of the original 1003 project; some initiate new
projects, such as P1201 on windowing environments.

If the subject of a new activity is closely associated with
the interests of an existing working group, it is assigned
to that group; if it is not, a new working group is set up.
This means that there are fewer working groups than


____________________________________________________________

    interested.

 2. Although I can tell you that ISO 9899, the C standard,
    went to the printers late in 1990, but, at the time of
    writing, has yet to emerge.  It is functionally
    identical to the U.S. standard, ANSI X3.159-1989.

 3. PARs can also be used to request changes to the goals
    and terms of reference of existing projects.












                           - 4 -



projects.  As an example, the 1003.0 working group is
concerned solely with the 1003.0 guide to the POSIX
environment, but the 1003.1 working group now handles
1003.1, the operating system interface; 1003.16, C language
bindings to operating system services; and 1003.18, a
profile for a "traditional" POSIX-based system.

Once a working group has been formed, its job is to draft
standards, making sure that they meet the needs of both
suppliers and users of information technology.  This is done
through a somewhat baroque balloting process:

   - Associated with each working group is a balloting
     group.  The balloting group is typically formed shortly
     before the circulation of the first complete draft of
     the first standard developed by the working group.

   - Balloting groups are drawn from the membership of a
     balloting pool.  The pool has three types of member:
     individual members of the IEEE who have specifically
     applied to join the pool4; institutional
     representatives (IRs) accepted by the IEEE-CS SAB (see
     below); and national heads of delegation to the ISO
     POSIX working group.

   - All members of the balloting pool are sent notice of
     the formation of each new balloting group.  Those who
     respond become members of the group, subject to
     considerations of maintaining a balance between user
     and supplier representatives.

   - Once a balloting group has been formed, it persists
     indefinitely with a static membership.  Only if there
     are problems in getting the required 75% response to
     ballots is the membership of a group reviewed.

   - It is almost never possible to join a balloting group
     after it has formed.

   - Individuals or organisations outside the balloting
     group can make objections to, or comments on, the
     content of draft standards, just as can balloting group
     members.  All objections from whatever source must be


__________

 4. The requirement for IEEE membership appears recently to
    have been dropped, although the rule book has yet to be
    amended.












                           - 5 -



     handled through a formal resolution process.  However,
     only members of the balloting group can vote for or
     against the acceptance of a draft (or indeed,
     completed) standard.

   - A draft is considered approved if it is accepted by 75%
     or more of those who vote either for it or against it5.

Simple, huh?  And I haven't even mentioned the appeals
procedure!

Membership of a balloting group is a considerable
responsibility:  following notice of a ballot, IEEE rules
give just 30 days to review a document which may run to
almost a thousand pages, and to return any comments or
objections to the ballot coordinator.  And unless over 75%
of the membership of the ballot group responds, the result
is held to be invalid.  When one considers that a document
is likely to go through a dozen drafts before it becomes an
approved standard, it is clear that balloters have to work
hard (even if not all of the drafts are balloted).
Recirculation ballots, initiated when changes are made to a
draft in response to an initial ballot, increase the work-
load further.

In order to make the task a little easier, TCOS has adopted
a procedure called a mock ballot to handle the early drafts
of a document.  These are similar to mock examinations: the
procedures are identical to the real thing, but it doesn't
matter so much if it is flunked.  In particular, no alarm
bells start ringing in the IEEE's offices if a 75% response
is not achieved.

           What_has_all_this_to_do_with_EurOpen?

EurOpen feels that it is important that the views of its
membership are represented in two forums.  Firstly, on the
SEC, which decides on the authorization of POSIX-related
projects and controls their development and coordination;
and secondly, in the balloting pool from which those who
vote on the content and acceptance of standards are drawn.




__________

 5. If more than 30% of those who return their ballots
    abstain, things get more complicated.  Let's not go into
    that.












                           - 6 -



The first objective has already been met:  I am happy to be
able to tell you that the SEC has unanimously accepted
EurOpen's request for me to become its institutional
representative6.  I join existing IRs from a number of user
groups and industry bodies:  the Open Software Foundation,
OSSWG (a group developing a real-time kernel for embedded
systems), SHARE (the IBM user group), UniForum, UNIX
International, USENIX and X/Open7.  (UniForum and USENIX
were particularly helpful in the preparation of EurOpen's
application.)

Gaining IR status in the balloting pool takes longer, as
EurOpen's request must be discussed by the SAB, but I hope
to be able to report in the Spring Newsletter that it has
been approved.

Luckily, this delay gives me a little breathing space to
make a request.  I need help from volunteers.  If you feel
competent to help EurOpen's newly-formed Standards
Activities Management Group (SAMG) in formulating responses
to IEEE POSIX ballots, please contact me at the mail address
at the head of this article8.  In particular, could experts
on secure operating systems please get in touch, as the
working group concerned with this aspect of POSIX, 1003.6,
is in the process of forming a balloting group.

I hope to see you at the standards birds-of-a-feather
session at EurOpen's spring conference in Tromso, where
members of the SAMG will be reporting on the latest
developments in the  Europe, the U.S.A. and the world at
large.








__________

 6. Actually, the acceptance was "by acclamation", which is
    even better.

 7. The Free Software Foundation (FSF) is likely to join the
    list later this year.

 8. The other members of the SAMG are Johan Helsingius
    ([e-mail]) and Henk Hesselink ([e-mail]).










--
Dominic Dunlop



Volume-Number: Volume 22, Number 92