std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (01/25/88)
Standards Update
An update on UNIX and C Standards Activities
January 21, 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 four parts, divided according to
the following topics:
Overview
X3J11 and the X3.159 C Programming Language Standard
NBS FIPS
IEEE P1003 Subcommittees
-mod]
The Standards community isn't necessarily a closed entity,
but it is one that is hard to look into. There are so many
different activities going on all over the place that it is
difficult for the most people to get involved. I suppose
this is as it should be, since if everyone were involved,
nothing would ever get accomplished. However, it is always
good to know what is going on at a macro level, even if the
details pass you by.
That is where this report comes in - I am going to try and
summarize what has transpired in the Unix and C standards
areas during the previous three months. As anyone who has
been involved in a standards committee can tell you, not a
lot will happen in a quarter in any one committee, but over
several committees the cumulative effect can be daunting.
Before I start summarizing what went on in the last quarter
on 1987, I should define the scope of this report. I am not
going to try to touch on all of the technical discussions
that go on. These are often boring, and if you have that
level of interest, you should really be on the mailing list
for the group in question. Instead, I am going to give an
overview of some of the key issues that were raised and the
important milestones that were reached or passed.
In addition to the activity at the December meetings of
P1003, a few other things happened that are worth noting:
- P1003.1 Final Ballot
Overview, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
On November 15th the P1003.1 document went out for its
full use ballot. The balloting period was 30 days, and
closed around December 15th. When ballot resolution is
completed, the first full use standard from a 1003
group will have been ratified. This should be around
March, 1988.
- New P1003 Working Groups
There are three new working groups under the P1003
committee (.0, .5, and .6). Since I haven't talked
about all of these before, here is a list of all of the
POSIX working groups:
1003.0 - POSIX Guide
1003.1 - Systems Interface
1003.2 - Shell and Tools Interface
1003.3 - Verification and Testing
1003.4 - Real Time
1003.5 - Ada Binding for POSIX
1003.6 - Security
- IEEE Standards Board
At the December meeting of the IEEE Standards Board,
the Board approved the IEEE Technical Advisory Group
Procedures document. This was a major event in that it
allowed the first meeting of the United States TAG on
POSIX to take place "in wedlock".
- US Technical Advisory Group on POSIX
The first meeting of the US TAG on POSIX was held in
conjunction with the P1003 meetings in December. A TAG
is a group that exists in each International Standards
Organization (OSI) member country that is interested in
a particular ISO working group (in this case, WG15 of
Suncommittee 22). The TAG recommends to the ISO
standards body for that topic in that country what the
countries' position should be on the issue. In this
case the standards body is the IEEE, and the issue is
POSIX. In a future report, I hope to spend more time
talking about what it means to be in the International
Standards Organization, and how it effects POSIX.
Since it was the first meeting, the members present
elected a chair and secretary, and learned about what
it means to be a TAG. In addition to this, the TAG
established what the US position on POSIX should be.
Basically this boils down to "The US recommends that
Overview, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
POSIX be accepted as a Draft Proposed Standard, but any
changes made to the standard by IEEE P1003.1 should be
incorporated into the ISO document." It would be very
bad form not to recommend our own standard :-)
Overview, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 2std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (01/25/88)
Standards Update
An update on UNIX and C Standards Activities
January 21, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
- C Language Standard
In addition to the P1003 standards activities, the work
of the X3J11 standards committee holds particular
interest for people in the un*x community. This is the
group that is defining the ANSI X3.159 C Language
Standard. They have been working on this for quite a
while now, and are very close to resolution. They went
into their first public review period last spring, and
have just recently finished responding to all of the
comments that were submitted at that time.
Based on information I have about the December meeting
of X3J11, here is what is happening in the future:
- Around January 8th, 1988 the second public review
draft will be completed.
- Soon after that, the second (2 month) public
review period will begin. As with last time, the
standard will be available to the public through
Global Press in Washington, DC.
- This public review will close in time for the
comments to get out to the committee members
before the April meeting.
- At that meeting, the committee will break down
into subgroups and review the comments. There
will be great resistance to making any substantive
(non-editorial) changes to the standard. If there
are any substantive changes made, it will result
in another public review period, which will delay
the standard for at least one calendar year.
- Assuming that there are no substantive changes to
the standard after the next public review period,
there should be a ratified standard before the end
of 1988.
If the C Language Standard can be completed before the
end of the year, it could mean a lot for POSIX system
implementors. Since the .1 standard will not be really
C Language, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
a standard until June, it is unlikely that vendors will
be able to complete an implementation before the end of
1988 in any event. If they could release a system that
supported both Standard C and POSIX, it would be a real
shot in the arm for application developers. A delay of
another year on Standard C would mean that application
developers must write code under POSIX that could very
well be broken under an ANSI C Conforming compiler.
C Language, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 3std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (01/25/88)
Standards Update
An update on UNIX and C Standards Activities
January 21, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
- NBS POSIX FIPS
One other item that is of concern to system
implementors and application developers alike is the
POSIX FIPS that is being announced by NBS this month.
This FIPS will be used by most federal agencies when
drafting Request for Proposals (RFPs) for many classes
of applications.
Just what is NBS going to require? Well, the NBS POSIX
FIPS is based on POSIX D12, the draft that went out to
the balloting group. The final POSIX standard may be
considerably different than this, but NBS has assured
the .1 working group that they will incorporate the
substantive changes in the standard into their FIPS
when the standard is complete.
So, if NBS is going to specify POSIX as the FIPS, what
are we worried about? Well, in order to increase
consensus and support as many existing implementations
as possible, POSIX has a lot of "options" in it. NBS
felt that these "options" made it difficult for
applications developers to write applications that used
the nice facilities of POSIX (they are right), so they
are requiring that many of these options be included in
a FIPS conforming implementation. For systems
implementors, this means that you had better include
all of these options if you want to sell to the federal
government. For applications developers, it means that
if your customer base is the federal government, you
can use these facilities without fear - they will be
there.
What are these options? Well, the following is an
excerpt from the NBS POSIX FIPS draft specification.
As an aside, it is important to note that many of these
so-called "options" are not really options at all, but
rather cases in which there was some ambiguity as to
how the system would function. I will indicate in the
following list some examples of real options and their
opposites for clarity.
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
- The term appropriate privileges shall be
synonymous with the term super-user.
This is not really an option, but rather a
clarification being introduced by the NBS people.
The term "appropriate privileges" was introduced
into the standard to provide for secure
implementations of POSIX. By indicating that
certain facilities of POSIX require "appropriate
privilege", the door was left open for
implementations where processes could have subsets
of the power normally granted to a monolithic
"super-user". In fact, the above requirement is
incorrect. You could not simply replace the term
"appropriate privileges" with the term "super-
user" throughout the standard and have it make any
sense. However, we get the idea.
- A null pathname shall be considered invalid and
generate an error (2.10.3, lines 894 - 896).
- The use of the chown() function shall be
restricted to a process with super-user privileges
(2.10.4, lines 924 - 926).
This is an example of a real option in POSIX. If
the macro _POSIX_CHOWN_RESTRICTED is defined, it
means that only a process with "appropriate
privilege" can change to owner of a file. This is
in conflict with the current System V definition
of how chown works, btu is more in line with
trusted implementations. Users should not be able
to "give away" files.
- Only the super-user shall be allowed to link or
unlink directories (2.10.4, lines 938 - 939).
Another useful option. A portable application may
need to know whether it requires "approprite
privileges" to move directories around.
- The owner of a file may use the utime() function
to set file timestamps to arbitrary values
(2.10.4, lines 943 - 945).
- The implementation shall support a value of
{NGROUPS_MAX} greater than or equal to eight (8)
(2.9.2). An implementation may provide an option
for setting {NGROUPS_MAX} to a value other than
eight (8).
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
The POSIX standard is still in the ballot
resolution process. When it went to ballot it
defined the BSD-style supplementary groups
feature. this says that there is a group-id
associated with a process, but that there may be
additional, supplementary groups also.
As of this writing, the definition has been
changed to a more flexible definition. There will
now be an array of group IDs associated with a
process. Although this change has not been
accepted by the full balloting group yet, I think
that it will be.
- The implementation shall support the setting of
the group-ID of a file (when it is created) to
that of its parent directory (2.10.4, lines 934 -
937). An implementation may provide a
programmable selectable means for setting the
group-ID of a file (when it is created) to the
effective group-ID of the creating process.
This is another example of a true option. Here
the FIPS is specifying the BSD method of creating
files. This method make a lot of sense in a
multiple group per process environment. However,
they also allow the System V behavior.
- The use of chown() shall be restricted to changing
the group-ID of a file to the effective group-ID
of a process or when {NGROUPS_MAX} > 0, to one of
its supplementary group-IDs (2.10.4, lines 927 -
930).
- The exec() type functions shall save the effective
user- ID and group-ID (2.10.3, lines 902 - 903).
This mirrors the System V behavior.
- The kill() function shall use the saved set user-
ID of the receiving process instead of the
effective user-ID to determine eligibility to send
the signal to a process (2.10.3, lines 891 - 893).
This is also similar to System V.
- When a session process group leader executes an
exit() a SIGHUP signal shall be sent to each
member of the session process group (2.10.3 lines
880 - 883).
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 4 - USENIX Association
- The terminal special characters defined in
Sections 7.1.1.10 and 7.1.2.7 can be individually
disabled by using the value specified by
_POSIX_V_DISABLE (2.10.4, lines 946 - 949;
7.1.1.10; 7.1.2.7).
- The implementation shall support the
_POSIX_JOB_CONTROL option 2.10.3, lines 884 -
886).
Although I have not described how Job Control
works under POSIX, suffice it to say that it is
confusing at best. The ballot resolution group is
still trying to decide how to resolve the problems
pointed out during balloting.
- The implementation shall provide a single utility
for reading and writing POSIX data interchange
format files (10.). This utility shall be capable
of reading USTAR and CPIO data interchange formats
without requiring the format to be specified. The
implementation shall write CPIO data interchange
format when no option on format type is specified.
- Pathnames longer than {NAME_MAX} shall be
considered invalid and generate an error (2.10.4,
lines 940 - 942).
- When the rename(), unlink() or rmdir() function is
unsuccessful because the conditions for [EBUSY]
occur, the implementation shall report the [EBUSY]
errno (5.5.1.4, lines 481 - 482; 5.5.2.4, lines
523 - 524; 5.5.3.4, lines 593 - 594).
- When the rename() function is unsuccessful because
the conditions for [EXDEV] occur, the
implementation shall report the [EXDEV] errno
(5.5.3.4, lines 593 - 594).
- When the fork() or exec type function is
unsuccessful because the conditions for [ENOMEM]
occur, the implementation shall report the
[ENOMEM] errno (3.1.1.4, line 54; 3.1.2.4, lines
175 - 176).
- When the getcwd() function is unsuccessful because
the conditions for [EACCES] occur, the
implementation shall report the [EACCES] errno
(5.2.2.4, lines 148 - 149).
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 5 - USENIX Association
- When the chown() or wait2() function is
unsuccessful because the conditions for [EINVAL]
occur, the implementation shall report the
[EINVAL] errno (3.2.1.4, line 272; 5.6.5.4, line
857).
- The implementation shall detect an [EFAULT] errno
condition (2.5, lines 554 - 558). The
implementation must state as part of the required
documentation; (1) the conditions when an [EFAULT]
is detected and an [EFAULT] errno is generated and
(2) those conditions, if any, when [EFAULT] may
not be detectable.
- The tcsetattr() function shall only set the
parameters supported by the underlying hardware
associated with the terminal (7.2.1.2, line 502).
- An interrupted write() function shall return a
count of the number of bytes successfully
transferred from the application program to the
system (6.4.2.2, lines 195 - 196; 6.4.2.4. lines
240 - 242).
- An implementation may provide errno [ENOEXIST] in
place of errno [EACCES].
- A POSIX FIPS implementation shall successfully
PASS the NBS-PCTS validation suite.
From all of these options, I am sure that it is obvious
that there is room for considerable variation in the
POSIX standard. The FIPS goes a long way towards
firming up an otherwise wishy-washy document. Since
many system implementors want to sell to the US
Government, it is probable that all of the above
requirements will be available on a majority of POSIX
conforming systems. This is excellent news for
application developers who want to take advantage of
some of the additional facilities introduced in POSIX
as optional.
NBS FIPS, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 4std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (01/25/88)
Standards Update
An update on UNIX and C Standards Activities
January 21, 1988
Written for the USENIX Association
by Shane P. McCarron, NAPS Inc.
Status of the IEEE P1003 Working Groups:
- 1003.1 - System Services Interface
The .1 working group has reached an interesting point
in its life. Since the standard they have produced is
now in final ballot and ballot resolution, the working
group in effect has nothing more to do. At the
December meeting they tried to decide what, if
anything, should be done by this body in the future.
Although no decision on this was made, many good
options were suggested.
Most promising among these is the design of a language
independent description of POSIX. One of the
requirements that ISO made of POSIX when it was adopted
as a Draft Proposed Standard last fall was that at some
point in the future it be described in such a way that
they functionality could be understood without an
understanding of the C language. ISO recognized that
it was unrealistic to make this a requirement before
adopting the standard, but felt that it was reasonably
important. I feel that this is something the working
group will be taking on soon after the Full Use
Standard is approved by IEEE.
- 1003.2 - Shell and Tools Interface
The Shell and Tools group is operating under a very
ambitious schedule. The National Bureau of Standards
(NBS) has indicated that they are going to declare a
Federal Information Processing Standard (FIPS) based on
the command set in the .2 standard, and that they are
going to do so in the summer of '88. This working
group only started serious work 1 year ago, and has
already produced a larger document than the .1 group
did in 4. The group is working hard to make sure that
the command set is locked down before the deadline
being imposed by NBS.
Unfortunately, this has the consequence that many
decisions are being made as rapidly as possible. I am
afraid that the resulting standard may be one that is
IEEE P1003, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 2 - USENIX Association
flawed, if only because the group is moving forward too
fast. On the other hand, the .1 group was guilty of
exactly the opposite, and NBS pressure has forced that
group to really get its act together. It has proven to
be a boon there, and it may do so here as well.
The Shell and Tools group has a milestone schedule
something like:
Date Milestone
Mar '88 Command Selection frozen;
75% described.
Jun '88 100% commands described;
functional freeze
Oct '88 Clean-up, slack; produce
"mock ballot" for draft (#8);
international signoff.
Jan '89 Resolve mock objections;
produce balloting draft (#9)
Apr '89 Resolve ballot objections;
produce final standard.
Jul '89 Final standard approved by IEEE
This may not appear to be all that hectic a pace, but I
can assure you that it is. When I say that the
commands are 100% described, it means that the current
functionality of each command that has been included in
the standard (a substantial part of the current "un*x"
command set) is described in painful detail. The goal
of the standard is to describe each command in such a
way that a person who has never seen a un*x machine can
write the commands from scratch. It's a lot of text.
With about 75% of the commands in, and those being
about 75% described (albeit incorrectly in some cases)
the document is now approaching 400 pages. In a future
report I will tell you just what is involved in a
command description. We don't have the space this time
:-)
- 1003.3 - Testing and Verification
This is another group that has been very active in the
last year or so. They have the dubious honor of
figuring out how to test that implementations of the .1
standard are actually conforming. Although the IEEE is
IEEE P1003, January 21, 1988 Shane P. McCarron, NAPS Inc.
Standards Update - 3 - USENIX Association
not going to be providing any validation services or
rating and systems, P1003 thought that it was important
that they define what parts of the system should be
tested in what ways.
The .3 group seems to be on track for balloting within
the next 6 to 9 months. There work is very far along,
and a verification suite is already being worked on by
the NBS based on the .3 assertion list about POSIX.
Although the .3 document will not be as earth-
shattering as POSIX, it is a still a very important
step - actually showing how to test conformance to a
standard at the same time you are defining one.
- 1003.4 - Real Time
Until recently, all the real time considerations in
POSIX were being looked into by a /usr/group technical
committee. Last fall that committee decided that their
research was mature enough that they could actually
start the work of producing a standard about it. The
real time work promises to add much of the
functionality that I and many others feel is absolutely
necessary in POSIX. Things like semaphores, shared
memory, and event processing. All of those inter-
process communication things that were left out of the
.1 standard because they just did not have the time.
Unfortunately, there is quite a bit of dissension as to
how all of these things should be implemented. Not
just IPC, but also contiguous files, timers, and those
things that a real time application would need to
really be real time. After talking to some of the
people who attended the December meeting, I would guess
that this group has a long way to go.
However, what will happen when they get there? At this
time I'm guessing that the .4 document will be
positioned as a supplement to the .1 standard. It
should require no changes to the .1 standard, and will
probably be a set of optional facilities, as job
control and some others are already. When this
standard is finally produced, it will answer many of
the objections we have heard to POSIX all along. I am
sure that it will be well received. Let's hope that it
can be timely enough to be useful.
IEEE P1003, January 21, 1988 Shane P. McCarron, NAPS Inc.
Volume-Number: Volume 13, Number 5guy@Sun.COM (Guy Harris) (01/25/88)
From: uunet!Sun.COM!guy (Guy Harris)
This may want to be forwarded to Shane, rather than posted; unfortunately,
I don't remember his email address.
[ He's ahby@bungia.mn.org or uunet!rutgers!umn-cs!bungia!ahby,
but this looks like a useful correction of a technical detail
(one I missed on review) that should be posted. -mod ]
- Only the super-user shall be allowed to link or
unlink directories (2.10.4, lines 938 - 939).
Another useful option. A portable application may
need to know whether it requires "approprite
privileges" to move directories around.
No portable application needs "appropriate privileges" to move directories
around; it can use "rename()". The correct way to move anything under a POSIX
implementation is to use "rename()", not "link()" and "unlink()".
Volume-Number: Volume 13, Number 6ahby@bungia.bungia.mn.org (Shane P. McCarron) (01/28/88)
From: ahby@bungia.bungia.mn.org (Shane P. McCarron) In article <116@longway.TIC.COM> guy@sun.com (Guy Harris) writes: >From: uunet!Sun.COM!guy (Guy Harris) > >This may want to be forwarded to Shane, rather than posted; unfortunately, >I don't remember his email address. > >[ He's ahby@bungia.mn.org or uunet!rutgers!umn-cs!bungia!ahby, >but this looks like a useful correction of a technical detail >(one I missed on review) that should be posted. -mod ] > > - Only the super-user shall be allowed to link or > unlink directories (2.10.4, lines 938 - 939). > > Another useful option. A portable application may > need to know whether it requires "approprite > privileges" to move directories around. > >No portable application needs "appropriate privileges" to move directories >around; it can use "rename()". The correct way to move anything under a POSIX >implementation is to use "rename()", not "link()" and "unlink()". Mea culpa, mea culpa :-) Of course Guy is right. No portable application may ever require appropriate privilege and still be portable. Especially since that privilege will be very hard to define (or come by) in a trusted environment. What I was trying to imply was that if appropriate privilege is required to link() and unlink() directories, and an application needs that ability for some unforseeable reason, then it should probably fail to compile on that instance of that implementation. The rename() call is sufficient for changing the name of a directory, but is hardly sufficient for creating multiple links to the same directory, or some other arcane use. It occurs to me that this may only be possible today using symbolic links, but you get the idea. My advice to application developers is to not even try to write code that requires anything that could be percieved as an option under POSIX. If you stick to the minimal set, you will be safe. Your application won't do anything, but... :-) Thanks for pointing out that rather glaring error. I must be getting senile. -- Shane P. McCarron UUCP: ahby@bungia.mn.org Systems Analyst ATT: +1 612 224-9239 Volume-Number: Volume 13, Number 10
jc@minya.UUCP (John Chambers) (02/16/88)
From: jc@minya.UUCP (John Chambers) [ This one got misplaced as I prepared to go to USENIX. I don't really understand the question, but if it's whether the rename function can be used to move directories, the answer is yes (although the user command is mv). -mod ] > >No portable application needs "appropriate privileges" to move directories > >around; it can use "rename()". The correct way to move anything under a POSIX > >implementation is to use "rename()", not "link()" and "unlink()". > > The rename() call is sufficient for changing the name of a directory, ... One thing I've wondered is whether the standard will require implementors to make things like rename("foo/bar/x","foo/x") work correctly. This is a serious omission in a great many Unix releases. It's not at all a hypothetical issue. I've seen a lot of cases where a user (myself included) uses tar or cpio or some such to unpack a bunch of files, intending them to go into foo/bar, and ending up with them all in foo/bar/bar. The usual result is "rm -rf foo/bar/bar" and starting over. It'd save a lot of grief if one could just say something like: rename foo/bar/bar foo/temp rename foo/temp foo/bar and be done with it. Of course, it'd be better if I could just type: rename foo/bar/bar foo/bar and get the desired result, but that's probably too much to hope for. ;-) Given the history of Unix releases, I wouldn't expect this to work when foo/bar/bar is a directory, unless there is some argument stronger than users' needs to convince the implementors. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) Volume-Number: Volume 13, Number 16
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (02/18/88)
From: uunet!harvard.harvard.edu!haddock!karl (Karl Heuer) In article <130@longway.TIC.COM> the moderator writes: >I don't really understand the question, but if it's whether the rename >function can be used to move directories, the answer is yes (although the >user command is mv). On at least one SysV-based system with a rename() system call and with unprivileged mv command, the following can occur. $ cat <<\! >rename.c > main(c,v) char **v; { if (rename(v[1], v[2]) == -1) perror("rename"); } > ! $ cc rename.c -o rename $ ls rename rename.c $ mkdir foo $ mkdir foo/bar $ mv foo/bar bar mv: directory rename only $ ./rename foo/bar bar $ ls bar foo rename rename.c $ ls foo $ exit As you can see, even though the system call works properly, `mv' on this system attempts to enforce a restriction that the only thing you can do with a directory is a `simple' rename (one where the `..' entry does not change). My reinterpretation of John Chamber's question has two parts: (a) Does the standard require that the rename() function allow non-simple renames of directories? (b) Does the standard require that the mv command allow this? [1003.1 doesn't say anything about mv, because that's in 1003.2. I don't know offhand what 1003.2 says. 1003.2 people? -mod] Volume-Number: Volume 13, Number 18
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/18/88)
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 5std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/18/88)
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 6std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/18/88)
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