IEEE TCOS, New Orleans, January 1991: EurOpen IR's report
Dominic Dunlop
domo at tsa.co.uk
Thu Jan 31 22:51:34 AEST 1991
Submitted-by: domo at tsa.co.uk (Dominic Dunlop)
Standards Column to be Published in
EurOpen Newsletter, Spring 1991
Dominic Dunlop -- domo at tsa.co.uk
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
(julf at penet.fi) and Henk Hesselink (henk at ace.nl).
--
Dominic Dunlop
Volume-Number: Volume 22, Number 92
More information about the Comp.std.unix
mailing list