pc@hillside.co.uk (Peter Collinson) (06/06/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) An Update on UNIX-Related Standards Activities USENIX Standards Watchdog Committee Stephen R. Walli <stephe@usenix.org>, Report Editor April in Chicago The April IEEE POSIX working groups was significant. The newly formed Project Management Committee enjoyed its first full working meeting. A new steering committee was formed to manage the thornier issues surrounding POSIX profiles. The long awaited first draft of a language independent specification of IEEE 1003.1-1990 was delivered for review and comment by interested working group members. And of course the week was dominated with Sun MicroSystems's and UNIX Systems Labs's (USL) Open Look project request being put up against the Open Software Foundation OSF/Motif project request. Project Management Committee Chicago was the first working meeting of the newly formed Project Management Committee (PMC). The PMC monitors existing TCOS-SS projects and reviews new PARs (Project Authorization Requests). They use a mentoring process, whereby a member of the committee is assigned to each new PAR and each current working group. Each PMC member has several to track, because of the current number of projects. Once a mentor is assigned a new PAR, they aid the PAR presenter in making sure it is properly formatted, and that all supporting documentation is present and complete. The point is to ensure that no PAR fails to be accepted by the TCOS-SS Sponsor Executive Committee (SEC) for documentation problems. If the PAR is accepted, the mentor continues to monitor the project to ensure that it is on track. A project that loses focus on the current scope would receive help to bring it back in line with its stated purpose. The PMC has no direct authority to mandate anything, however they can recommend that the SEC take certain actions. Members of the PMC include: Jason Zions, Shane McCarron, Lorraine Kevra, Roger Martin, Derek Kaufman, Robert Bismuth, Don Cragun and Tim Baker. The PMC covered a lot of ground in its first week, starting on Sunday afternoon. The competing project authorization requests (PARs) to create standards for the two major X interfaces were discussed. (Discussion of the competing PARs follows.) The POSIX.2 (Shell and Utilities) working group had a new PAR proposed, POSIX.2b, which covered the reformatting of the POSIX.2 and POSIX.2a (User Portability Extension) documents, and the incorporation of new utilities. The new POSIX.2b PAR was changed so that only new extensions would be part of the PAR, and the document reformatting was left out. This means we won't have a two thousand page document arriving for ballot as POSIX.2b! POSIX.7 (System Administration) was reviewed and recommendations made to separate it into several PARs under the same working group. An additional PAR for 1224 to cover the Object Management API for X.400 and X.500 was recommended. The POSIX.4, POSIX.6 and POSIX.11 projects were also reviewed during the first week. This committee will likely begin to have more and more effect on the building of POSIX as it becomes comfortable with its role. Its members are long-time POSIX people with considerable experience and I look forward to what they bring to the overall process with all of its current problems of co-ordination and synchronization. Par Wars Competing X Window PARs dominated the Chicago meeting. A month before the Chicago meeting, the Open Software Foundation (OSF) submitted a PAR to the TCOS-SS SEC proposing a direct ballot of the OSF/Motif API Document and Style Guide. These documents would be reformatted according to TCOS style guides if the PAR was accepted. Test assertions and Language Independent Specifications would be written at the OSF's expense if required. The legal copyright issues were arranged with the IEEE Standards Office. Sufficient industry acceptance and experience to make Motif a standard was claimed. This forced the backers of Open Look to rush forward with a similar PAR, championed by Sun Microsystems and UNIX Systems Labs. Similar claims of industry acceptance and experience were made, and similar reformatting, test assertions and LIS were promised. So the battle was joined once again. There is significance to a direct ballot. POSIX standards are usually drafted by a working group who take base documents and create a new revised document. This revised document is balloted, reviewed and made into a standard. With a direct ballot, there is no working group formed to build a document through a consensus process, but a balloting group is formed directly. In theory the document is ready to be shipped to balloters, which was not the case for either of these PARs. TCOS-SS has rules for creating standards this way, but no one has ever done it before. The stage was set for a week of theatrics. The first people to have to deal with the duel was the PMC. They stuck to the letter of their mandate, and reviewed these PARs to ensure they were correctly formatted. They also recommended that certain steering committees review them. The Steering Committee on Windowing User Interfaces (SCWUI) was an obvious reviewer. (Yes, it's pronounced ``scwewy'', you wascally wabbit.) SCWUI stated that it did not want these PARs accepted because of the overlap with the current P1201.1 (Windowing Toolkit API) work. The Steering Committee on Conformance testing (SCCT) was also asked for comment, and reported they had no concerns with either of them as stated. One SC that was missed was the Distributed Services Steering Committee (DSSC) which came to light in the SEC discussions of the PARs. The Sun/USL PAR characterizes Open Look as a distributed desktop paradigm, so DSSC should have an opportunity to comment on it. The P1201.2 working group is building a Recommended Practice document for driving window based applications. The chair of this working group raised concerns that if either of these documents became standards before P1201.2 completes its work, it may conflict with it. People discussed and debated all week in the hallways as to what would and should happen. Many felt that both PARs should be accepted, pointing to the IEEE 802 LAN standards as an example. Fortunately, many of the Europeans present were able to point out the problems with this, since they are currently living in a situation where many conforming implementations of OSI protocols cannot talk to one another because of such differences. This destroys any hope of building very portable applications which have windowed interfaces, unless one is willing to only be portable within windowing environment ``A''. Others felt that neither PAR should be accepted, pointing out that if P1201.1 (Windowing Toolkit API) has been deadlocked over this type of API for so long, perhaps there isn't sufficient industry consensus to create a standard. This is extremely important. On a few occasions during the week I heard different people refer to the original POSIX work to build POSIX.1. These references came about during completely seperate discussions on conformance for language independent specifications and profiles. People talked about the way that the working group members laid aside their preferences for their particular flavours of UNIX in favour of building the standard. This does not appear to be happening in this arena. Neither PAR could be accepted alone, since this would have disastrous commercial effects on the ``loser.'' This points out some of the problems of allowing vendors and vendor consortia to produce such documents for standardization. It has been successfully done in the past in other areas of technology, but it needs to be done with great care, and not in an environment of direct and blatant commercial competition. The membership of the balloting groups for these PARs would be interesting to see. The IEEE has rules about the percentage of balloting group content that is vendor related, user related or ``general interest''. This has never been contested in the past. Likewise, ballot resolution of comments and objections would also be interesting, as the PAR presenters would be responsible for administering their own ballot resolution according to the PAR's scope. Somewhat like handing a pit bull terrier its own leash and telling it to walk itself without getting into a fight. The SEC was forced into a painful discussion for a few hours on these PARs. During part of the discussion, PAR presenters pointed out that if the TCOS-SS SEC refused the issue, there was still a court of final appeal, being the IEEE Standards Board itself. Fortunately, Paul Borrill was present. Paul is the vice-president for standards in the IEEE Computer Society, and a member of the IEEE Standards Board. Paul didn't have a lot to say, but his points were clearly made. First, he encouraged the groups to fix their own problems. Second, he reminded them who sets the rules, if people chose to bend or abuse them. (The IEEE Standards Board!) Points taken. In the end, the discussion was halted with a flurry of Robert's Rules procedural magic. The Rules are used as a way to ensure that work is accomplished in a committee forum and that all participants have fair opportunity to be heard. The SEC resolved that it ``does not feel at this time that it should sponsor either the Modular Toolkit Environment PAR (Motif) or the Open Toolkit Environment PAR. (Open Look)'' The PARs are in procedural limbo, By that hour, the SEC was only too happy to kill discussion of the PARs. The PARs have not been ``tabled'', ``withdrawn'', or ``postponed''. They are still very real and I fear that the Santa Clara meeting will have these PAR presenters haunting the hallways, singing ``weee're baaaack....'' Profiles! Get your Profiles! For quite some time now, profiles have been a great source of confusion in the POSIX world. Ask ten different people from ten different areas what a POSIX profile is, and you will indeed receive ten different answers. There is a list of serious outstanding issues on defining, co-ordinating and standardizing POSIX profiles, which has been built up by the working group on the POSIX Guide (P1003.0) and current profile writing groups. They have long felt that some form of managing group needed to take charge of these issues. After much (circular) discussion as to the nature of this committee (is it a rapporteur group, an ad hoc group or a steering committee) it was finally decided that a steering committee was required to deal with the management issues of profiles. The SEC ratified this decision and the Profiles Steering Committee was born. Bob Gambrel is the chair of the Profiles Steering Committee, and each working group with a profile project also has representation. The group held its first organizational meeting the next day and by the time Santa Clara rolls around, the committee's work will be well underway. LIS POSIX.1 A first draft language independent specification of POSIX.1 (System Application Program Interface) was delivered this week. Language Independence is an issue raised by ISO who wish standards to be unrelated to a particular programming language. In January, the SEC formed a subcommittee to solicit and evaluate submissions to produce a complete POSIX.1 language independent specification (LIS). Monies were put forward by the IEEE Computer Society, the contract was awarded and the work was done. The completed first draft language independent specification of POSIX.1 (to IEEE 1003.1-1990) and a near complete draft C language binding (POSIX.16) were presented at the LIS BOF on Monday afternoon. BOF attendees raised concerns that input on certain language indendence issues raised over the last few working group meetings may not be completely reflected in the drafts, but the drafts were generally well received. Copies were in such high demand that the rules for making document copies at meetings had to be changed to prevent further drafts from being produced. This work is significant. A concrete example of a near complete LIS of POSIX.1 now exists. Other working groups can use it as an example in much the same way that POSIX.3.1 (Test Methods for POSIX.1) is an example of how to construct and structure test assertions. Many working groups point to the functionality described in POSIX.1, and it was unclear how their LIS would need to be structured to point to an LIS version of POSIX.1. These issues can now be addressed and the language indendence requirements on the POSIX standards process can move forward with more confidence. ISO's working group 15 (WG15) on POSIX requested that language bindings to the POSIX standards come forward as ``thin'' bindings to the LIS documents. Thin bindings indicate that there is no significant duplication of semantic content between the LIS and the language binding. Because of this request, the POSIX.5 (Ada Binding) and POSIX.9 (FORTRAN-77 Binding) working groups are not proceeding at the international level at this time. Both of these groups are balloting their documents at the IEEE level and are busy resolving ballot objections. Both of these groups have language standards groups reviewing their respective programming languages, with a view to significantly changing them. The groups feel they can better serve the industry by waiting until the POSIX.1 LIS and the changing language standards stabilize, and then produce the documents which will be forwarded to the international level for standardization. In the meantime, IEEE standard bindings will exist for Ada and FORTRAN-77 to the C based POSIX.1 standard. Volume-Number: Volume 23, Number 94