Standards Update, Editorial

[Peter Collinson]

Submitted-by: pc at hillside.co.uk (Peter Collinson)

An Update on UNIX-Related Standards Activities
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe at 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