Path: utzoo!mnetor!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (1: P1003.1 Final Balloting)
Message-ID: <176@longway.TIC.COM>
Date: 18 Apr 88 03:55:11 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 196
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update
An update on UNIX Standards Activities
April 17, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
[This report was written at the request of the Board of
Directors of the USENIX Association. In the interests of
reducing article sizes and making followups easier to
manage, I am posting it in three parts, divided according to
the following topics:
P1003.1 Final Balloting?
NBS POSIX FIPS
IEEE P1003 Activities
-mod]
This is the second in a series of reports on the UNIX
standards community. In this article I will give you a
summary of what happened at the March meeting of the POSIX
committees. I will also explain what happened during the
IEEE P1003.1 balloting, and why there is going to be another
round of review and comment during May. In addition I will
discuss what is going on with the National Bureau of
Standards (NBS) Federal Information Processing Standards
(FIPS), and how this will effect both implementors and
programmers in the short and long term. Those of you who
saw the first article in this series will remember that the
title was "An update on UNIX and C Standards Activities."
That changed this time because the ANSI X3J11 meeting isn't
until mid-April, and there hasn't been too much going on
between meetings (other than a public review). Next quarter
I will return to the C arena as well.
P1003.1 Final Ballot?
Those of you who saw the first issue of this column may
remember that I reported on the status of the P1003.1
balloting. At that time I stated that the standards would
be fully ratified in March... Well, I was wrong. Although
the IEEE review board gave the standard conditional
approval, it did not pass in it's first round of balloting,
nor did it pass in the first recirculation for review and
comment. Needless to say, I was a little surprised, but
there were many factors that figured into the problem, and
it just wasn't to be.
P1003.1 Balloting?, April 17, 198S8hane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
I have been asked by many people exactly what went on. In
the interest of clearing the air, below you will find a
chronological account of the balloting procedure. I have
also outlined what the IEEE requirements for balloting are,
and how P1003.1 worked within these constraints. Even
though you many finish reading the summary with an uneasy
feeling about the standards process, please keep in mind
that until recently there have been no large IEEE standards.
The procedures were designed for 4 page documents describing
the characteristics of three-phase power, not for 400 page
documents specifying all the characteristics of an operating
system.
On November 15th the Standard went out to the balloting
group. The balloting group consists of IEEE or IEEE
Computer Society members who have indicated an interest in
voting on this standard. When a balloter votes no, they
must return a document which states their specific
objections, and what can be done to resolve them. Although
specific wording is not required, it is encouraged.
On December 15th (actually, a little after) balloting on the
standard closed. The official IEEE length of a balloting
period is 30 days, or until 75% of the balloting group
members have returned a ballot, whichever is later. When
75% of the ballots had been returned, the standard did not
have the necessary percentage of yes votes (75%) for
approval. At this point the standard and the ballots were
turned over to the Technical Reviewers for resolution.
On January 15th (or so) the committee chair started to
assemble the ballot resolution documents for recirculation
to the balloting group. The resulting document was a
summary of all the changes made to the standard to resolve
balloting objections or comments. In all there were 140
pages of changes, and (unfortunately) they were poorly
organized and formatted. In my own defense (as a Technical
Reviewer) I can only say that the process was rushed a
little, and I procrastinated a little. Also, communication
between the Technical Reviewers was a little lacking, and
the guidelines for reviewing and acting on ballots were
unclear. This is all kind of tragic, but it was certainly
an educational experience for all concerned.
On February 5th the resolution document was resubmitted to
the balloting group for a 10 day review period that was to
start on the 15th. Unfortunately the mail was held up until
the 15th (or in some cases the 17th) and many balloting
group members did not receive the recirculation document
until the 20th or later, for return to the IEEE Standards
office by the 25th. Worse yet, the IEEE balloting
P1003.1 Balloting?, April 17, 198S8hane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
procedures state that if the technical reviewers have
resolved all objections in a ballot, that ballot
automatically becomes a yes. The balloter must specifically
indicate that his/her ballot is still negative. This was
not made very clear to the balloting group, and many people
did not resubmit a ballot.
Fortunately many people did complain about the short review
period and the problems with the recirculation document.
Eventually it was discovered that the 10 day period that
IEEE stipulates for reviews is a minimum, not a maximum.
There was a lot of finger pointing and complaining on all
sides, and in the end it was decided that even though the
standard had the necessary 75% approval, there would be a
second recirculation.
During the week of March 7th the IEEE Standards Board met.
In spite of all the problems with the standard, and all of
the letters of protest that they received (including one
from each of the Institutional Representatives, if I am not
mistaken), the board conditionally approved the standard.
[You're not mistaken: the Institutional Representatives of
all three of USENIX, /usr/group, and X/OPEN sent letters of
protest to the Standards Board; I also spoke to the
Standards Activities Group directly about the time limit
problem. -jsq] This conditional approval is an
unprecedented event (as far as I can tell) and means that
the standard can become fully ratified before the next
meeting of the standards board once the second recirculation
has been completed and it has sufficient positive ballots.
There was a lot of screaming about this as well, but somehow
it happened.
During the week of March 14th the POSIX committees met in
Washington D.C. Throughout the meetings the co-chair of
P1003.1 met with each of the Technical Reviewers and very
carefully went through their sections of the document,
making sure that all objections and comments had been
considered, processed, and responded to. This was an
incredibly time consuming and painful process, but I believe
that it resulted in a much better standard. During the last
few weeks the Technical Reviewers have continued to work
closely with the co-chair to get the second recirculation
document put together. It should be completed and sent to
the Technical Reviewers (as a safety check) in mid-April.
Once the Reviewers think that it is clean enough, it will be
sent out to the balloting group for a second review and
comment period.
The second recirculation will be handled quite a bit
differently than the first. All members of the balloting
P1003.1 Balloting?, April 17, 198S8hane P. McCarron, NAPS Inc.
Standards Update - 4 - USENIX Association
group will receive a new copy of the standard (Draft 12.3)
that will have change bars only in those places where
changes have been made as a result of balloting objections
or comments. In addition, each balloter will receive a
document detailing all of the unresolved objections, what
their nature is, and why they were not resolved. The
balloting group will have a longer period to respond to this
document (> 10 days), but they shouldn't need much more
time, as most of the changes in the document were already
detailed in the first recirculation document (although they
were not made in context - that is to say they were not in a
new draft, but rather listed as changes to draft 12). At
the end of this recirculation and balloting period it is
believed by most members of the committee that the standards
will be complete.
The time frame for all of this is late April/early May.
I apologize for the length of this summary, but I think it
is important that everyone know just what happened. Of
course, this is just one man's perspective, but I think that
it is a fair one. I believe that the completed standard
will be one which was carefully considered and designed,
even if it won't make everyone happy.
P1003.1 Balloting?, April 17, 198S8hane P. McCarron, NAPS Inc.
Volume-Number: Volume 14, Number 5
Path: utzoo!mnetor!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (2: NBS POSIX FIPS)
Message-ID: <177@longway.TIC.COM>
Date: 18 Apr 88 03:56:54 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 95
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update
An update on UNIX Standards Activities
April 17, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
NBS POSIX FIPS
As I reported last quarter, the National Bureau of Standards
has specified an Federal Information Processing Standard for
POSIX. This FIPS has now been called an Interim FIPS, and
is based on Draft 12 of the POSIX standard (the draft that
went to the balloting group). This is unfortunate, since
the post balloting draft is significantly different in a
number of areas. Also, the NBS has made some changes in
their requirements for the FIPS since I last reported them.
As of this writing the POSIX Interim FIPS for the System
Services Interface is not official. It is going through the
government signature maze within the Department of Commerce,
and is expected to emerge sometime in April.
This Interim FIPS will remain the standard until the P1003.1
standard is completed. Sometime after that the NBS will put
together a final FIPS based on .1. Unfortunately, this may
not be for several months after .1 is completed. In the
mean time government agencies will be generating Requests
for Procurement (RFPs) which stipulate the Interim FIPS.
What this means for systems implementors is not entirely
clear. The government will be requiring (at least for a
little while) a standard that is in many ways incompatible
with the final P1003.1 document. Obviously implementors
have two options: 1) put together POSIX conforming systems
and wait until the final FIPS is complete before selling any
systems, or 2) put together a FIPS conforming system and be
able to start selling immediately. Fortunately implementors
have an out here - many of them have release cycles lasting
anywhere from 6 to 18 months. By the time there is a POSIX
standard and they get their implementation ready to be
released, the FIPS will have changed to reflect the final
standard... Maybe.
What it means to application developers is a little more
obvious. Software that is in development today is probably
too far along to consider making it POSIX conformant - or
worse yet, ANSI C conformant. Software that is not yet in
programming is going to take quite a while to get to market,
so it can be made POSIX conformant without having to worry
about the Interim FIPS.
NBS POSIX FIPS, April 17, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
In addition to this first FIPS, the NBS has stated that it
is going to be releasing several more Interim FIPS based on
some of the other POSIX work in progress, as well as the
work of other groups (like AT&T and the SVID). During the
POSIX meetings in Washington, Roger Martin from the NBS (and
also chair of P1003.3 - Testing and Verification) made
presentations to the various committees, explaining what the
NBS intends to do in the next year with Interim FIPS:
In May or June an Interim FIPS for the Shell and Tools
interface (POSIX P1003.2) will be proposed. It will be
based on Draft 6 of the .2 document, and will contain (at
least) the command set from that document. It may also
contain text from that document, or in cases where the text
is felt to be immature, will contain text from the SVID or
some other source. This Interim FIPS will be based on Draft
6 until the final standard is completed sometime in later
1989.
In addition, the NBS will be releasing several other FIPS.
These will be in the areas of Terminal Interface Extensions,
System Administration, and Advanced Utilities. These are
all terms from the SVID, and relate to just the things that
you think they do. The Advanced Utilities FIPS may be
rolled into the P1003.2 FIPS, since .2 encompasses most of
those items that they wanted in there. The others will be
based directly on the SVID (as far as I know). These are
all to be in place by the end of 1988. This is an ambitious
schedule, even for NBS. However if they meet it, it will
mean that by the end of this year the government will have
standards on most aspects of the UNIX operation system, and
system implementors and application developers will have to
conform.
NBS POSIX FIPS, April 17, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 14, Number 6
Path: utzoo!mnetor!uunet!longway!std-unix
From: std-u...@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update (3: IEEE P1003 Activities)
Message-ID: <178@longway.TIC.COM>
Date: 18 Apr 88 03:59:48 GMT
Reply-To: std-u...@uunet.uu.net
Lines: 199
Approved: j...@longway.tic.com (Moderator, John S. Quarterman)
Standards Update
An update on UNIX Standards Activities
April 17, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
IEEE P1003 Activities:
As I mentioned above, the POSIX committees met in Washington
D.C. in March. For the first time, all 7 of the committees
met. As you can imagine, it was pretty difficult to catch
all of what went on, but here are the highlights:
P1003.0 - POSIX Guide Project:
This group met for the first time in Washington. Although
they didn't get a lot of tangible work done, they did
establish what their goals were, as well as starting to put
together a timetable for production of their guide document.
I don't have the details of this yet, but I will next
quarter.
P1003.1 - System Services Interface:
This group met to decide what we are going to be working on
in the future. We have a few items that must be handled by
the .1 group, and some that could be. Currently there are
three projects being worked on by members of the committee:
- Language Independent Description
The ISO POSIX Working Group has requested that a
language independent version of the .1 standard be
produced as soon as possible after completion of the
standard. Language bindings (like the current
descriptions that are in the standard and the work
being done by the .5 group) would be placed in
supplements to the main standard, or in chapters within
the standard itself.
- Improved Archive Format
Although the ISO community agrees that CPIO and USTAR
are fine for the first cut of the standard, they have
requested that .1 work on a more robust archive format
that doesn't have the technical drawbacks of either, as
well as one that takes into account the security
features needed for trusted systems.
IEEE P1003 Activities, April 17,S1h9a8n8e P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
- Terminal Interface Extensions
Yes - we mean curses/Terminfo. Well, not really, but
something very much like that. It will have to be
something that resembles current practice (I imagine),
but it could be improved in little ways. There was a
lot of sentiment in the group for throwing out all of
the Terminfo stuff and starting from scratch, but I
don't think it will happen. We will probably get some
proposals that are wildly different from existing
practice, but it is outside the group's charter to
totally supplant existing practice.
P1003.2 - Shell and Tools Interface:
The .2 Group got a lot of work done in Washington. They
went in with a 400 page draft 5, and by end of May a 450+
page draft 6 should be completed. This draft 6 will be used
as the basis of the interim FIPS that the NBS will be using
for their Interim FIPS on POSIX (see above).
The most significant developments in .2 were:
- Source Code Control
The committee felt that source code control was outside
the scope of the standard, and it was removed (it had
been added at the last meeting). A number of people
still feel that some form of source code control should
be in there, so the committee left a place in the
document where it could be put back in later. The real
danger here is that the RCS people and the SCCS people
will get into a religious war similar to the one that
erupted between the TAR and CPIO factions in the .1
group.
- Basic Shell Changes
There were many features of the Bourne shell that had
been included in .2 for historic reasons. At this
meeting the shell subcommittee agreed to remove some of
those anachronisms. This will make way for (possibly)
more enhancements to the basic shell mechanism in the
future (e.g., substring manipulation).
- Software Installation
Two drafts past there was a very complex system in the
standard that allowed software installation in a
portable way. This was removed in the December
meeting, and replaced at the March meeting by a very
IEEE P1003 Activities, April 17,S1h9a8n8e P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
simple interface that should be acceptable to everyone.
Although the details are not all clear, it looks like
this will consist of an implementation defined command
that will read the first file off of a POSIX conforming
archive (tape) and execute it. Anyway, something about
that difficult.
- Electronic Mail Interface
Mailx was added in Draft 5 as a proposed way to
portably transmit mail. Some committee members felt
that the way in which it was described was too
restrictive, while others felt that it was too liberal.
In a compromise move, another interface was defined
that allows very simple mail transmission in a portable
manner. It also has a name that doesn't conflict with
existing utilities.
P1003.3 - Testing and Verification:
At the March meeting the chair announced that they were on
target for completing the assertion lists for P1003.1, and
that the .3 standard for .1 would be ready to ballot just as
soon as the .1 standard was ratified. He also stated pretty
clearly that P1003.3 didn't want to work as hard when
generating verification standards for the other POSIX
committees. He asked that in the future the standards be
written in a way that makes it easier to develop assertion
lists. The .3 committee will be working closely with the .2
effort (which is a little too far along to fix now), but the
other committees will be changing their documents to reflect
what assertion tests can be made about each function or
command being defined. This should make it easier to
produce verification documents for those standards.
P1003.4 - Real Time:
This committee made a lot of progress in the March meeting.
However, they have a long road ahead of them, and I don't
know that anything earth shattering happened - certainly
nothing that I heard about. However, they have stated a
target of 1990 for completion, and at this point it is a
little early to draw any sort of conclusions.
P1003.5 - Ada Binding for the System Services Interface:
The Ada group is still a very young committee, but they are
moving right along. At the very least they are generating a
lot of paper, but it has some excellent stuff on it.
Although they haven't been a working group long, I expect to
see a draft from them in the next six months, and a standard
IEEE P1003 Activities, April 17,S1h9a8n8e P. McCarron, NAPS Inc.
Standards Update - 4 - USENIX Association
being balloted in a year. Although this may seem like a
long time, it is really short work for a standards
committee. Unfortunately, their work is very dependent on
.1 getting a language independent description of the System
Services Interface put together as quickly as possible.
They have already looked into ways of describing POSIX
independent of any language, and they will be helping .1 get
this firmed up.
P1003.6 - Security:
This was the first meeting of .6 as a real IEEE committee.
They defined their scope and objectives, set a tentative
production schedule, and defined the format of their
document. As a /usr/group technical committee they produced
a number of white papers, and I expect to see drafts coming
out of the group based on those papers shortly. The only
snag here is that the transition from a /usr/group technical
committee to an IEEE working group wasn't as smooth as
others have been. To help alleviate some of the tension
this caused, the next .6 meeting will be held in conjunction
with USENIX in San Francisco in June, instead of with the
POSIX committees in July. After that they will follow the
regular POSIX meeting schedule.
IEEE P1003 Activities, April 17,S1h9a8n8e P. McCarron, NAPS Inc.
Volume-Number: Volume 14, Number 7
|