mod.std.unix and P1003

Moderator, John Quarterman std-unix at ut-sally.UUCP
Wed Oct 29 04:19:24 AEST 1986


This article is a slightly adapted copy of an earlier one.

There seems to be widespread confusion as to the relation of the
newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the
IEEE P1003 standards committee and its subcommittees.  Allow me
to try to clear some of it up.


Because something is discussed in mod.std.unix does not mean that
it is automatically proposed to P1003 for inclusion in the standard.
Proposals to the committee have to be more formal.  Especially they
have to include specific proposed wording.

As it happens, the moderator of the newsgroup is also the USENIX
representative to the committee.  As such, I am willing to present
proposals to the committee if someone actually has some to present.
However, the proposer has to specifically request that for a specific
proposal and I have to agree to it before it will happen.

It is true that several committee members follow the newsgroup and
that I make sure that copies of articles from the newsgroup go to
appropriate technical reviewers or are mentioned to the committee
as a whole.  However, they are not presented as proposals:  they
are presented as comments.  They may help committee members understand
the context of a topic which is treated in the standards document,
but they are unlikely to cause new topics to be added to the document.

This is not to say that input from the newsgroup is not useful
to the committee.  A number of problems with the latest drafts
were pointed out in the newsgroup and fixed because of that.
The time zone discussion has led to an actual proposal (P.055)
which may be adopted by the committee.


Because something is discussed in mod.std.unix does not even
necessarily mean that it has anything to do with the P1003 committee.


The committee is very aware that they should not be introducing
new facilities.  It has happened a few times.  The only one
I can think of at the moment is file locking, specifically the
mandatory locking feature of flock (which was actually introduced
by the /usr/group committee).  This is also, not coincidentally,
one of the most controversial things in the current document,
even though its proponents only back it because they are convinced
it is necessary.

You will find things in the draft standard document which do not
correspond to your local system, regardless of what your local system
is.  This is because in the real world there are at least two major
variants of UNIX and many minor ones.  To pick one and standardize on
it alone would be to try to outlaw all the others.  This is probably
not even possible, even if it were desirable.  The committee has chosen
instead to try to produce something which is not exactly like anything
out there but which can be implemented with relatively minor changes on
most existing systems.

Ritual disclaimer:  this article is constructed of my personal opinions
and does not necessarily represent any official position of IEEE, P1003,
USENIX, /usr/group, or any other organization.

Volume-Number: Volume 8, Number 2



More information about the Mod.std.unix mailing list