std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (09/03/88)
From: Shane P. McCarron <ahby@bungia.mn.org>
[ This report was commissioned by the USENIX Association. -mod ]
An update on UNIX Standards Activities
August 1, 1988
Shane P. McCarron, NAPS International
This is the third in a series of reports on standards bodies
relating to the Unix community. Before I start, I would
like to take a couple lines to thank all of those readers
who were kind enough to drop me a line of either criticism
or encouragement; both are greatly appreciated. In the
future please feel free not only to comment on the articles
here, but also on standards issues. I am more than happy to
try and answer any of your questions either individually or
through this column.
To business: the most important item to report (from my
perspective) is that the Usenix Association has formed a
Standards Watchdog Committee. The charter of this group is
to keep an eye on as many of the standards efforts as
possible, and report the progress of those efforts back to
the membership. In addition, the group will be looking for
important or contentious decisions, and trying to determine
a Usenix position where it seems appropriate. The group
will also be looking to you, the members, for input.
Everyone has opinions, and the Watchdog Committee, through
its standards committee representatives, can serve as a
channel to get your ideas to the appropriate groups or can
put you in contact with the appropriate people. For more
information, please contact:
John S. Quarterman
Texas Internet Consulting
701 Brazos, Suite 500
Austin, TX 78701
(512) 320-9031
jsq@usenix.org, uunet!usenix!jsq
As always, the standards bodies have been pretty busy during
the past quarter. Busy, that is, in standards body terms.
There is often a great deal of heat, but very little light.
I have remarked in the past that these committees can take a
long time to complete things. In some future issue, maybe I
will take a few inches and sketch out how a full standards
working group meeting really goes :-). Not this time though
- there is too much real news to get to:
P1003.0 - The POSIX Open Systems Environment Guide
The IEEE 1003.0 working group met on July 12 & 13, 1988 in
Denver, Colorado. The purpose of this meeting was to have
- 2 -
the group members, who had volunteered during the March
meeting to work on certain portions (sub-groups) of the
POSIX Open Systems Environment guide document, present their
material for review and critique by the group. This was
accomplished on day 1 and the morning of day 2. The sub-
groups that were discussed included:
1. Operating System
2. Database Management
3. Data Interchange
4. Network Services
5. User Interface
6. Languages
7. Graphics
The remainder of the meeting focused on goals and objectives
for the next meeting in October. There was strong consensus
within the group that the next goal should be a very rough
draft document. Volunteers were assigned to each sub-group
above with the purpose of putting into narrative form the
material that had been presented. It was also agreed that
distribution of this draft prior to the October meeting
would be essential in order to allow for good, well
thought-out discussion during the meeting.
The group has targeted October, 1989 as a goal for beginning
the balloting process. This is aggressive, but possible,
assuming that the effort between meetings can be maintained
at its present level.
Overall, the meeting was very productive and is drawing more
participation from a good cross-section of vendors and
users.
P1003.1
The big news this month is, of course, that as of August
22nd the POSIX System Services Interface standard is finally
complete. By the time you read this final drafts should
have been circulated to all of the POSIX working group
members, and copies of that draft should be available from
the IEEE office in New York. While you can obtain a copy of
the final draft now, you would do well to wait for a couple
of months and pick up a real, hard-bound version of the
standard from the IEEE. To order a copy of the final draft,
- 3 -
contact:
IEEE Standards Office
345 E. 47th St.
New York, NY 10017
(212) 705-7091
Since the last installment in this series, the 1003.1
standard has gone through not one, and not two, but three
more recirculations. As you may remember, the second
recirculation was scheduled to take place in May, and it
did. This one went as well as expected, and generated some
excellent feedback. The changes from that recirculation
were assembled and sent back to the balloting group for
review at the end of June. As a result of that
recirculation, there were yet more changes to the standard,
and those changes had to be recirculated as well. The final
recirculation took place at the end of July, and generated
no substantial changes. At that point the standard was
released to the Technical Editor for final copy editing, and
has now been balloted on and approved by the IEEE Standards
Board!
This is actually good and bad. It is good for all the
reasons you would suppose. It is bad because the standard
is not perfect; there are things that shouldn't be in it
that are (e.g. some weird timezone stuff and read() and
write() functions that allow broken behavior), and things
which should be in it but are not (like seekdir() and
telldir()). Even though the standard is not perfect, at
least we now have a foundation upon which additional
documents can be based. In the future this standard will be
extended and revised, but for now (in combination with
Standard C), it's the best thing we have for application
portability.
In the mean time, the .1 working group has not been idle.
Although the initial work on the Services Interace standard
was completed some months ago, there are always new areas to
work in. I gave a detailed description of these new areas in
the April update; the following is only information on
developments where they occured:
Clean Up
There are some issues that were not handled to the
satisfaction of the working group in the first cut of the
standard. A small group is working on sifting through the
unresolved balloting objections (there were several) and
identifying those items that can be rectified through
modification to the standard. It turns out that many of the
- 4 -
unresolved objections were very reasonable items, but were
introduced too late in the process to be placed in the
standard. Those items will be looked at and possibly added
to the standard in a supplement.
Language Independent Description
While little progress has been made in this area by the .1
working group, it turns out that there has been quite a bit
of work done by other working groups and technical
committees. The /usr/group technical committee on
Supercomputing, in particular, has produced a Fortran
language description of the .1 interface. In the process
they have come up with a number of items that can be used by
the .1 people to develop their language independent
description.
Terminal Interface Extensions
The Working Group looked at the various requirements
necessary for a terminal interface standard (a terminal
interface standard is something like the Terminal Interface
Extensions in the SVID, better know as curses/terminfo).
The group determined that there is little or no way to get a
single interface standard that will satisfy the needs of the
entire community. Those people with bit mapped displays can
do things better, and we should let them. Those people with
block mode terminals have special needs that should not have
to be addressed by Joe Portable Application. The majority
of users that we are trying to satisfy, those with character
based terminals, have well defined needs that are already
being addressed by existing practice.
What's the solution? Well, none was really proposed, but I
would guess that the people in the bit mapped world are
going to care a lot more about Open Look and Presentation
Manager (bite my tongue) than they are about something based
on terminfo or termcap. For the other 90 percent of the
Unix using community, while terminfo/termcap may be what
they are used to seeing, it is hardly attractive enough to
make them sit up and take notice. They are looking for
flashier, better, faster applications, and the traditional
interface is not going to be enough. For application
developers, the functionality which can be achieved via
terminfo is fine but hardly adequate for building the
products that the user community is coming to expect.
I would guess that the POSIX committees will settle on some
subset of the terminfo interface as the standard, and that
no one will use it. Sure, it will be on every POSIX
conformant system, but who cares? It is a lame interface,
- 5 -
and someone will come up with a better one soon enough.
New Archive Format
As I mentioned previously, the ISO has asked P1003.1 to come
up with a new archive format that will not have the
deficiencies of tar or cpio and will be able to take the
security concerns of the P1003.6 group into consideration (I
assume that by this they mean access control lists,
mandatory access controls, and the like). Little was done
on this topic between meetings, but at the July meeting the
committee discussed ways to extend the cpio archive format
to take these things into consideration. While the
technical details of this extension are clear, they are also
boring. Suffice it to say that the filename field in the
archive can be extended through a kludge and that it would
be backward compatible.
This met with mixed reactions, and I believe that in the end
it will not be used. This discussion (popularly known as
Tar Wars) has been very religious and contentious, and I
don't think that a format based on either will be able to
get popular support from the working group. There is now a
small group of people (from both camps) working on another
new format, and I am certain that they will come up with
something for the October meeting.
P1003.2 - Shell and Tools Interface
This group is actually a little bit ahead of schedule.
Forget all the nasty things I have said about their schedule
being too tight and optimistic - they are actually going to
do it! You're not as impressed as I am, I can tell. Some
people are just never satisfied. Okay, here's some evidence
for you:
Functionality was frozen at the March meeting. This means
that no additional commands or concepts could be added to
the standard. It also means that the working group members
were free to concentrate on the content of the draft,
instead of looking at new proposals for additional commands
all of the time. This has turned out to be very profitable;
the draft has been cleaned up to the point where it can be
submitted (to the working and corresponding groups) for a
mock ballot in September. A mock ballot is just that - a
process during which the draft is picked apart as it would
be in the balloting process, with changes submitted through
formal balloting objections. This may seem a little
excessive, but it has proven effective in the past.
- 6 -
Assuming that all goes well, and the objections from the
mock ballot are resolved at the October meeting, the group
could go to a full ballot as early as January. A less
optimistic scenario shows the group working on resolution of
the mock ballot for two full meetings, with the real ballot
occuring in February or March. Either way, the group is on
schedule for a full use standard before the end of 1989.
In addition to this good news, there were a few key
decisions made at the July meeting:
This side of the Tar Wars is apparently at an end. There
were two aspects to the war - user/program interface and
actual archive format.
The interface side of it seems to have been settled by the
introduction of a command called pax (latin for peace :-).
This command will be able to read and write both types of
archives and has an interface that is acceptable to both
camps. While this has not been agreed upon by the balloting
group, or even by the full working group, the interface is
pretty familiar, and I believe it will be approved with
little change.
The group also concentrated on trying to remove anything
that might be considered implementation dependent from the
draft. This included removing the octal modes from chmod,
and the signal numbers from trap and kill. In their place
go all of the mnemonic command line arguments that have been
in those commands all along, but aren't used by anyone. As
a committee member I can see what they are trying to do, and
even agree with it. As a user, however, I wish they would
have placed requirements that, say, kill -9 would always map
to SIGKILL. At least that way I wouldn't have to fix every
shell script I have ever written.
P1003.3 - Testing and Verification
This working group is progressing well on their verification
standard for 1003.1. They are planning to have a version to
ballot in January or February of 1989. That would make the
standard available just about the time that the major
vendors are finishing their .1 conformant implementations.
The group has also started supplying liason people to each
of the other working groups. These people, with their
experience writing a testing standard for .1, are proving
very valuable in designing testable standards.
New POSIX Work Items
- 7 -
In addition to all of the committees you have heard about in
past articles, there were several new working groups
proposed to the P1003 steering committee:
System Administration
The committee recognizes the need for a standard interface
to many of the system administration utilities that we are
plagued with. While there was a considerable amount of
skepticism exhibited from the members, the steering
committee has agreed to let work progress on this topic.
Consequently, a PAR was filed by Steve Carter of Bellcore,
and the new working group will start meeting in October.
This group has a lot of work ahead of them; The
difficulties of designing standard interfaces to things like
fsck and fsdb may prove impossible. Also, from an system
implementor standpoint, I would hate to have the
administrative functions I can provide limited by something
that a standards committee is going to generate based on
existing practice. This is not an area in which there is a
huge body of existing applications, so implementors should
be allowed to innovate and improve if they like.
On the other hand, the computer users of the world are
probably pretty sick of having to learn a new way to enable
printers on every system they purchase. For those people,
having a standard is going to be a big win. This is one of
those times when the saying "be careful what you wish
for..." comes into play. The ultimate, generic system admin
interface may prove to be so restricted or brain-dead that
it is of no use to anyone. The .1 standard was nearly that
way.
Networking
Another new working group will be focusing on the services
and service interfaces for a networked POSIX conformant
system. While the exact charter and goals of this group are
not fully established, what they are not trying to do is.
They are not trying to overlap the work of the ISO-OSI
committees, nor are they trying to supplant the work being
done by IEEE 802. Their plan is to spend two years defining
the services and service protocols, and maybe an additional
year defining interfaces to those protocols.
User Interface Commands
If you have looked closely at the 1003.1 and .2 standards,
you will notice that there is nothing in either of them
about User Interface. Well, you're not alone, and someone
- 8 -
is finally going to do something about it. A sub-group of
the Shell and Tools committee has beenformed to codify the
interface of many of the classic Unix commands (vi, ed,
etc...). In addition, the group will be defining the user
interface aspects of those commands already in the .2
standard which have traditionally had user interfaces as
well as their programmatic ones.
This group is going to work somewhat in a vacuum - since
there is no standard for terminal interface, the user
interfaces defined are not going to have a way,
programmatically, of being put on the screen. Terminfo will
of course work for this, but it is not a standard.
Hopefully the .1 committee can get a supplement out
regarding this before the .2 sub-group finishes its work
describing the utilities.
X/Open
The X/Open group is just about to release version 3 of the
X/Open Portability Guide. This set of manuals is a must for
any application developer or system implementor planning on
marketing products in Europe. Version 3 will encompass all
of the .1 standard, but will not contain any of the items
proposed in the latest drafts of .2 - that document is too
immature. The XPG also has language definitions, database
interface specifications, and many other things that a
growing programmer needs in the Unix world.
NBS - Federal Information Processing Standard
I have written about this in each issue of this report, and
each time I say that it is almost here. Well, I am done
making predictions. The federal government has a shield
that my crystal ball just refuses to penetrate. I have
heard recently that the FIPS for the .1 standard is within
the Commerce department somewhere, but I have no proof.
When it does finally come out, it will be based on a version
of the standard that is almost a year out of date. Draft 12
of the .1 standard resembles the final standard about like a
caterpillar resembles a butterfly. This is very
unfortunate, as the vendors that are serious about selling
computers to the feds are going to have to conform to that
standard, and not the real one. Note that while the NBS did
try to jump the gun a little bit, they forced the .1
committee to work harder and faster. Without their
encouragement the standard may well never have been
finished.
Of course, the NBS has indicated that they will start making
the FIPS conform to the final standard just as soon as it is
- 9 -
out (now, that means). But, given the amount of time it
took them to get the first standard out the door, I'm not
holding my breath. It could be deep into 1989 before we see
a revised FIPS hit the Federal Register's list of
announcements.
In the mean time, the NBS is proceeding in its specification
of other interim FIPS. Just until there are real standards
in these areas, of course, we are going to see FIPS on Shell
and Tools, User Interface, System Administration, Terminal
Interface Extensions, and probably shoe lacing. The NBS
people are very busy cranking out standards that federal
government departments can cite when generating bid
requests. Unfortunately, in those cases where the
committees aren't far enough along yet, these standards are
going to be based on the SVID. And if the SVID is used as a
base document by the Feds, you can be sure that it will also
be used by any standards committees that come along later
and want to "codify existing practice". Just another
example of the Federal Government guiding the standards
community.
The NBS is putting on a series of workshops this fall to
address some of these issues, and get input from the
community. The first of these workshops, a seminar on
"POSIX and other Application Portability Profile Standards"
will be September 22nd and 23rd. For more information, you
should contact Debbie Jackson at (301) 975-3295. She will
be happy to send you registration materials, as well as give
you information about future workshops being put on by the
National Bureau of Standards.
X3J11 - ANSI C Language Standard
This standard is pretty important to everyone in the Unix
community. Unfortunately, that means that everyone has to
get involved in the development of it, and that takes time.
The document has now entered its third public comment period
(July 1st -> August 31st). From what I gather, the
committee will be very reluctant (read "it will never
happen") to make any substantive changes to the standard as
a result of this period. What they are looking for is
affirmation from the public that the changes made in round
two were adequate to remove most of the outstanding
objections.
The good news here is that the "noalias" keyword has been
removed from the draft. This was a very contentious issue,
and was introduced very late in the process. In simplest
terms, noalias would allow the programmer to specify that
the program, for that statement, would do exactly what it
- 10 -
was supposed to do. Pretty silly, when you get right down
to it. Anyway, its gone now - like a bad dream.
In addition, a number of simple editorial changes were made.
Most of these are transparent, and just made the standard a
little more readable. Unfortunately, it is still a standard
written by programmers, for programmers, and is a little
hard to read. There is even rumor of a x3speak program,
like the valspeak of a few years ago, about to come out in
comp.sources.misc. This would take any prose and render it
senseless through the addition of legalese. My advice to
future readers of the standard is this: Don't go into the
water alone. Use the buddy system, and take a readers'
guide with you.
Assuming all goes well at the September meeting, the ANSI C
Language Standard should be published later this year.
Well, that's about it for this month. Remember, keep those
cards and letters coming to:
Shane P. McCarron
NAPS International
117 Mackubin St.
Suite 6
St. Paul, MN 55102
(612) 224-9239
ahby@bungia.mn.org
Volume-Number: Volume 15, Number 4std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (09/05/88)
From: uunet!sysadm!bjorn >> New POSIX Work Items >> >> System Administration >... >> Consequently, a PAR was filed by Steve Carter of Bellcore, >> and the new working group will start meeting in October. > >Is there any way to get further information about this group, and >its work? [ Steve Carter can apparently be reached as uunet!usenix!bellcore!pyuxv!ctsd!slc2 and it is possible that slc2@bellcore.bellcore.com may also work. I have sent him a request for details to post to comp.std.unix. My understanding is that there will be a brief meeting of the new subcommittee at the Hawaii 1003 meeting (end of October), but that real work probably won't commence until next year. See also the announcement of the USENIX Large System Installation Administration Workshop in November. -mod ] Volume-Number: Volume 15, Number 6