To Amend or to Revise?

Formal standards, or at least those of the IEEE and ISO, have two distinct ways of being modified once published. The first is to amend that standard; strictly, this is intended for adding new material, though an amendment can also fix some problems with the original. The second method is a full-scale revision of the entire standard. In the world of POSIX, until now, we have been publishing amendments to the original POSIX.1 and POSIX.2 core standards.

These have added such facilities as support for realtime systems, threads, and sockets. There are several more amendments in progress, such as POSIX.1a (symbolic links and other extensions), POSIX.1h (services for reliable and available systems), POSIX.1j (more realtime), etc.

An amendment changes the base standard; if you ask for POSIX.1 today, you get all the approved amendments as part of that deal. This means that vendors have a real problem keeping up, even if it does take years to approve a standard. As soon as an amendment is published, their systems stop conforming to the standard because the standard changed under their feet.

A revision allows a whole new document to be issued, looking at the entire scope of the document again. A vendor can claim conformance to an old revision.

One of the results of the big "Future of POSIX" debate in Fort Lauderdale this January was a resolution that effectively prevents PASC, the Portable Applications Standards Committee of the IEEE Computer Society, from ever sponsoring another amendment project. Those that are in progress have two years to complete or to change course and publish their standard as a standalone document.

At the same time, we have been debating the commencement of the first revision of POSIX.1 since 1990. Such a revision would be allowed to include any new functionality already published in other standards (withdrawing that separate standard as a result), and would allow us to make all the amendments that have been published truly fit together seamlessly ­ or at least that's the theory.

All these standards are produced essentially by volunteer effort. Various companies and organizations (such as USENIX) pay individuals for time and expenses, but entirely on a voluntary basis. If nobody volunteers to work on a revision to POSIX.1, then that project will fail.

Organizations other than PASC are working in a scope that overlaps that of PASC, most notably, The Open Group (TOG) and ISO SC22/WG15. One proposal from TOG (reported on in the February 1998 ;login:) was for TOG to take over much of the development and support of the POSIX standards. This proposal failed during the debate, but it has been agreed that the three groups do need to work more closely. An ad hoc committee has been formed to try and work out how such co­operation might work. Your views are actively encouraged on this. Personally, I should like to see a coordinated single working group of the technical experts from all three sources and a synchronized ballot process involving all three procedures. Please send comments to me or to Roger Martin, chair of the ad hoc committee <rjmartin@eng.sun.com>.