From: n...@usenix.org (Nicholas M. Stoughton)
Subject: Standards Update, The Decline and Fall of POSIX?
Date: 1996/06/13
Message-ID: <4pqb36$16t@cygnus.com>
X-Deja-AN: 160054641
sender: s...@cygnus.com
x-submissions: std-u...@uunet.uu.net
organization: USENIX Standards Report Editor
reply-to: std-u...@uunet.uu.net
newsgroups: comp.std.unix
Submitted-by: n...@usenix.org (Nicholas M. Stoughton)
Nicholas M. Stoughton < n...@usenix.org>, Report Editor
The Decline and Fall of POSIX?
Nicholas M. Stoughton < n...@usenix.org> reports on The
Decline and Fall of POSIX?
Mine's Bigger Than Yours
The March Internet Engineering Task Force (IETF) Meeting in
Los Angeles attracted well over 1100 attendees. They ranged
from those who wanted to find out more about the Internet
(i.e. were using it as an educational vehicle), through
interested observers, wanting to report back latest
developments to their companies, to a number of real
developers, actively building new standards.
Meanwhile, the IEEE Portable Applications Standards
Committee (PASC) continues to have a declining membership,
now down to well under 100 for the last three meetings
(actually 64 at the most recent meeting).
The IETF churn out large numbers of standards, with each
working group producing two or three a year. PASC has slowed
to a trickle, or so it seems. Actually, looking at the
output of the two groups side by side, the picture is not
nearly as dark as it first appears.
The average IETF standard is thirty or forty pages long. It
is written by engineers for engineers. Few application
developers need worry overtly about the nitty gritty of the
lower levels of the protocols between the parts of their
application, so long as they work. Most IETF standards have
working reference implementations to assist in describing
behavior. Therefore, the language in the standard need not
be as precise as required by a POSIX standard.
The average PASC standard is three or four hundred pages of
extremely carefully reviewed material. It takes between
three and six years to develop one of these beasts. Its
audience is a much wider proportion of application
developers and system implementors. It must be couched in
unambiguous terms, and not rely on anyone's ``common sense''
to determine the meaning of what is written.
IETF standards are built on ``rough consensus'' and
``working code''. Rough consensus is not actually defined
anywhere, and it is often up to the working group chair to
see how many heads in the room are nodding; ``a good hum''
is all that's needed. It does then go through various
- 2 -
subsequent levels of inspection and implementation before
becoming a full standard. The working code is often the
arbiter in cases of interpretation; if your implementation
can talk to mine, then it's probably OK.
PASC standards on the other hand have a very tightly defined
idea of consensus. The rules are rigidly applied. The ballot
groups are often large (POSIX.1a for example has 127
members) who have a small finite window to vote on a
particular draft. If 75% of the respondents approve (and 75%
of the group has to respond), then the draft is approved.
Most large standards go through about twelve drafts. IETF
documents (Requests for Comment, or RFCs) probably go
through four or five before they become ??draft?? standards.
So in fact, the POSIX process is roughly equivalent in
output to the IETF, but the resulting output is far more
formal a document. The reaction time -- the time from idea
to something concrete -- is a major problem, but the rate at
which work gets done is not substantially different.
But the shrinking size of PASC has other, more sinister,
connotations. Does a working group of four or five people
really represent the industry as a whole? Isn't some
commercial concern, such as X/Open, doing a better job,
faster, with more representation, than PASC?
I would argue strongly against this idea. I hope you will
agree with me too! The strength of PASC lies in the fact of
its openess, and its cross industry participation. X/Open,
while having a User Council, is basically funded and run by
and for the vendors. It does a fantastic job for them, and I
am not in any sense knocking that. PASC, on the other hand,
is not about the Working Groups themselves, but the wider
audience of people involved in building standards -- the
ballot groups in particular. Anyone can join a ballot group
(even non members of the IEEE, though their ballot need not
be regarded as binding). Anyone can influence a POSIX
standard provided the consensus agrees. End users of the
standards, both application developers and the implementors,
are able to voice their opinions, and can try to ensure that
the result is useful and acceptable. I can't do that to the
Single Unix Specification. But I can, and have, influenced
the content of POSIX.1, for example.
The debate on the declining attendance of PASC meetings is
raging around me as I write this. The three options we are
discussing are
+ Make no changes, we are doing OK
+ Stop developing new POSIX standards, our job is done
there. Change PASC to become purely a care and
maintenance group for the finished work.
- 3 -
+ Alter PASC's scope to take in other, sexier, work and
attract more people
That third option may have some merit. But PASC has done a
good job in defining application program interfaces for
portability. To branch out into other areas, like languages
or protocols, is not only a step into the unknown, but also
treads on the toes of other existing groups.
The current scope of PASC is based on the interfaces needed
to develop portable applications. They describe the
interface between the application and the environment in
which it is to run. The real question is how much has that
environment changed in the last 12 years or so that has
been working. Are we only working a small percentage of our
scope?
As a part of this debate, a new study group is to form at
the next meeting to look at some new functionality that
might be within our scope to work with. A notice for this
group appears in this issue.
The debate will continue for some months, I'm sure. Please
feel free to mail me with your opinions.
|