Standards Update, Recent Standards Activities
Jeffrey S. Haemer,
jsh at usenix.org
Fri Oct 12 07:26:10 AEST 1990
Submitted-by: jsh at usenix.org (Jeffrey S. Haemer,)
An Update on UNIX1-Related Standards Activities
October 11, 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, jsh at ico.isc.com, Report Editor
Summer-Quarter Standards Activities
This editorial addresses some of the summer-quarter standards activi-
ties covered by the USENIX Standards Watchdog Committee.2 In it, I've
emphasized non-technical issues, which are unlikely to appear in offi-
cial minutes and mailings of the standards committees. Previously
published watchdog reports give more detailed, more technical sum-
maries of these and other standards activities. If my comments move
you to read one of those earlier reports that you wouldn't have read
otherwise, I've done what I set out to do. Of course, on reading that
report you may discover the watchdog's opinions differ completely from
the ones you see here. As watchdog editor I edit the reports, I don't
determine their contents. The opinions that follow, in contrast, are
mine.
Profiles
There's an explosion of activity in the profiles world, bringing with
it an explosion of problems, and dot zero, the POSIX guide group, is
at ground zero.3 The first problem is, ``What's a profile?'' Everyone
has a rough idea: it's a document that specifies an application-
specific set of standards (or pieces of standards). The best informal
illustration I've heard is from Michele Aden, of Sun Microsystems.
Imagine, she says, you have to write a guideline for buying lamps for
Acme Motors. You might require that the lamps have ANSI-standard,
three-prong plugs, accept standard one-way, hundred-watt bulbs, have
cords no shorter than five feet, and stand either two- to three-feet
tall (desk models) or five- to seven-feet tall (floor-standing
models). This combination of pointers to standards, additional
specifications, and detailed options, which gives purchasing agents
__________
1. UNIXTM is a Registered Trademark of UNIX System Laboratories in
the United States and other countries.
2. A companion article provides a general overview of the committee
itself.
3. I use ``dot zero'' to refer both to the P1003.0 working group and
to the document it's producing. These are common conversational
conventions among standards goers, and which of the two I mean is
usually obvious from context.
October 11, 1990 Standards Update Recent Standards Activities
- 2 -
guidelines to help them make choices without tying their hands to a
specific vendor, is a profile - in this case, an Acme Motors lamp pro-
file. Dot zero now sees itself as a group writing a guide to help
profile writers pick their way through the Open-Systems'-standards
maze.
But that rough agreement is as far as things go. And the standards
world is never informal. For ``profile'' to graduate from a hallway-
conversation buzzword to an important organizing principle, it needs a
precise definition. And since there are already four groups writing
profiles - real-time, transaction processing, multiprocessing, and
supercomputing - TCOS needs to figure out what a profile is pretty
quickly. ISO already has IAPs, International Applications Profiles.
The ISO document TR 10K describes these in detail. Unfortunately, TR
10K was developed for OSI-related profiles and shows it. Cut-down
extracts of the standard appear in the document. Someone needs to
define a PAP, a POSIX Application Profile.
But that's just the first problem. Even thornier is the question
``What does it mean to say that something conforms to the POSIX
transaction-processing profile?'' If I want to write assertions for a
profile or tests to verify those assertions, how do I do it? Does it
suffice to conform to the individual components? What about their
interactions? The first principle of management is ``If it ain't
somebody's job, it won't get done.'' Dot zero has done such a good
job of promoting The Profile as an organizing principle for addressing
standards issues that people are beginning to press dot zero for
answers to questions like these. Unfortunately, that's a little like
killing the messenger. It's just not dot zero's job. So the funda-
mental profile question is ``Who's in charge?'' Right now, I think
the question sits squarely, if uncomfortably, in the lap of the SEC -
the Sponsors Executive Committee, which oversees the IEEE's
operating-systems activities.
In the meantime, the various working groups writing profiles are mak-
ing headway by just trying to define profiles and seeing where they
get stuck. Dot twelve, the real-time profile group, is busily making
various sorts of tables, to try to find a reasonable way to specify
the pieces that make up a profile, their options, and their interac-
tions. Dot ten, the supercomputing profile group, is seeking an
overall structure for a profile document that makes sense. Dot
eleven, the transaction-processing profile group, is trying to steal
from dots twelve and ten, an important test of the generality of the
other two groups' solutions. Dot fourteen, the multiprocessing pro-
file group, isn't far enough along to make theft worth their while,
but will eventually provide a second generality test. Think of it as
a problem in portable ideas.
October 11, 1990 Standards Update Recent Standards Activities
- 3 -
Will_I_Win_My_Beer?
In my last editorial, I announced a beer bet with John Gertwagen over
whether threads will ballot and pass before the base dot-four (real-
time) ballot objections are resolved. I'm still betting on threads,
but it looks like the bet is still anyone's to win. Some folks assure
me that I'll win my beer handily, others say I don't have a chance.
At the summer POSIX meetings, in Danvers, Massachusetts, the dot-four
chair, Bill Corwin, challenged the threads folks to come up with a
ballotable draft by the end of the week, and they very nearly did. (I
hear complaints from some quarters that the the vote to go to ballot
was 31 to 7 in favor, and that attempts to move to balloting were only
blocked because of filibusters from those opposed.) On the other
hand, technical reviewers are now resolving ballot objections to the
base with machetes. They've thrown away asynchronous events alto-
gether and have discarded real-time files and adopted the mmap model
that the balloting group suggested.4 Dot four has moved from ``design
by working committee'' to ``design by balloting committee.''
Innovation
C.A.R. Hoare once said, ``One thing [the language designer]
should not do is to include untried ideas of his own.'' We have
followed that precept closely. The control flow statements of
Ratfor are shamelessly stolen from the language C, developed for
the UNIX operating system by D. M. Ritchie.
- Kernighan and Plauger5
Should standards groups just standardize existing practice, or should
they be solving known problems? And if they solve known problems, how
much innovation is allowed? Shane McCarron's September UNIX/Review
article6 uses the real-time group, dot four, as a focus for an essay
on this subject. His thesis is that standards bodies should only be
allowed to standardize what's boring. I've already seen John
Gertwagen's reply, which I assume will be printed in the next issue.
__________
4. Dot four's real-time files are currently a part of the
supercomputing profile. If they disappear from dot four, they may
reappear elsewhere.
5. Kernighan, Brian and Peter Plauger, Software Tools, Addison-
Wesley, 1979, p. 318.
6. McCarron, Shane, ``Commodities, Standards, and Real-Time
Extensions,'' UNIX Review, 8(9):16-19 (1990).
October 11, 1990 Standards Update Recent Standards Activities
- 4 -
I find myself agreeing (and disagreeing) with both and recommend you
read them.
This battle will rage brighter in some of the groups less far along,
but sporadic fighting still breaks out in the shell and tools group,
dot two. Right now, collation and character classification are seeing
a lot of skirmishing. Some want to stay relatively close to the
existing practice, while others want to grow a mechanism to deal with
the Pandora's box of internationalization. My favorite current exam-
ple, though, is make. Bradford's augmented make is almost a decade
old. Stu Feldman's original is a couple of years older than that.
That decade has seen a number of good make replacements, some of them
wildly successful: Glenn Fowler's nmake has virtually replaced make
for large projects in parts of AT&T. Still, many of these upgrades
maintain the original make model,7 just patching up some of make's
more annoying craters and painting over its blemishes. At this point,
there is real consensus among make augmentors about some patches.
Most upgrades expand make's metarules. For example,
.c.o:
$(CC) $(CFLAGS) $<
might become
%.c : %.o
$(CC) $(CFLAGS) $<
Not much of a change, but it also gives us
s.% : %
$(GET) $(GFLAGS) -p $< > $>
...
in place of the current, baroque
__________
7. Fowler, Glenn, ``A Case for make,'' Software-Practice and
Experience, 20: S1/35-S1/46 (1990).
October 11, 1990 Standards Update Recent Standards Activities
- 5 -
.c~.o:
$(GET) $GFLAGS) -p $< > $>
...
Make's successors don't agree on syntax, but they all agree agree that
``~'' rules are the wrong solution to a real problem. Should dot two
standardize a newer solution? Existing-practice dogmatists would say,
``No. It's not make.'' Here's a place I say, ``Yes - if we can do it
in a way that doesn't break too many makefiles.'' The prohibition
should be against untried ideas, and I don't see those here. A year
or so ago, Stu Feldman (make), Glenn Fowler (nmake), Andrew Hume (mk),
and a handful of other make luminaries presented a proposal to add
four extensions to dot two's make. Not one is yet in the draft. I
hope that changes.
SCCT_Faces_Serious_Problem
At Danvers, the testing group, dot three, worked with dot two on test
assertions to try to avoid the kinds of problems created by the
P1003.1 test assertions, which dot one had no input into until the
assertions were in ballot.
A side effect of the collaboration, which is taking place before dot
two is finished, is that it may reveal that parts of dot two are
imprecise enough to require a rewrite. Dot two, draft eight had
around four-hundred ballot objections, draft nine saw fewer than half
that number. There was hope that draft ten would halve that again,
bringing it within striking distance of being a standard8 The asser-
tion work may point out and clear up rough spots that might otherwise
have escaped the notice of battle-fatigued balloters. (Paradoxically,
NIST, which is heavily represented in dot three and painfully familiar
with dot two's status and problems, is currently pushing for a shell-
and-tools FIPS based on the now-out-of-date draft nine.)
The exercise of trying to construct assertions for dot two before it
goes to ballot may bring some new testing problems into focus, too.
Before I explain what I mean, I'll give you a little background.
The POSIX effort has outgrown dot three, which did test assertions for
dot one and is in the process of constructing test assertions for dot
two. Dot three has, at most, a couple of dozen members, and the docu-
ment for dot two alone may swell to one- or two-thousand pages.9 If
__________
8. It didn't reach that goal. Keith Bostic tells me he submitted 132
objections himself.
October 11, 1990 Standards Update Recent Standards Activities
- 6 -
dot three were to continue to do all test assertion work, it would
have to produce a similar document for at least a dozen other stan-
dards.
Reacting to this problem, the SEC created a steering committee, the
SCCT, to oversee conformance testing. The committee's current plan is
to help guide standards committees to write their own assertions,
which will be part of the base document. Test assertions, like
language independence, are about to become a standards requirement (a
standards standard).
With this change, the current process - write a base document, evolve
the base document until it's done, write test assertions for the
result, evolve the test assertions until they're done - would become:
write a base document with test assertions, then evolve the base docu-
ment modifying the test assertions as you go. A sensible-enough idea
on the surface, but after the joint dot-two, dot-three meeting I have
questions about how deep that sense runs.
First, does it really make sense to write assertions early? Working-
group members should be exposed to assertion writing early; when
working-group members understand what a testable assertion is, it's
easier to produce a testable document. Still, substantive, major
draft revisions are normal, (see the real-time group's recent ballot,
for example) and keeping test assertions up-to-date can be as much
work as writing them from scratch. This meeting saw a lot of review
of draft-nine-based assertions to see which ones had to change for
draft ten.
Second, if you make the assertions part of the standard, they're voted
on in the same ballot. Are the same people who are qualified to vote
on the technical contents qualified to vote on the test assertions?
Third, writing good assertions is hard, and learning to write them
takes time. How eager will people in working groups be to give up
time they now spend writing and revising document content in order to
do assertions?
Fourth, is the time well-spent? Not everything merits the time and
expense of a standard. If only a small number of organizations will
ever develop test suites for a particular standard (with none being a
______________________________________________________________________
9. Any imagined glamour of POSIX meetings fades rapidly when one is
picking nits in a several-hundred-page standards document. When
asked where the next meeting was, one attendee replied, ``some
hotel with a bunch of meeting rooms with oversized chandeliers and
little glasses full of hard candies on the tables.''
October 11, 1990 Standards Update Recent Standards Activities
- 7 -
special, but important case) does it make sense for folks to spend
time developing standards for those test suites? Wouldn't it make
more sense to develop it after there is a clear need? (This is a per-
verse variant of the ``existing practice'' doctrine. Even if you
don't think standards should confine themselves to existing practice,
does it make sense to innovate if there's never going to be an exist-
ing practice?)
Stay_Tuned_for_This_Important_Message
If you haven't yet had the pleasure of internationalizing applica-
tions, chances are you will soon. When you do, you'll face messaging:
modifying the application to extract all text strings from external
data files. The sun is setting on
main()
{
printf("hello, world\n");
}
and we're entering a long night of debugging programs like this:
#include <stdio.h>
#include <nl_types.h>
#include "msg.h" /* decls of catname(), etc. */
#define GRTNG "hello, world\n"
nl_catd catd;
main()
{
setlocale(LC_ALL, "");
catd = catopen(catname(argv[0]), 0);
printf(catgets(catd, SETID, MSGID, GRTNG));
catclose(catd);
exit(0);
}
This, um, advance stems from a desire to let the program print
ch`o c'c ^ng
instead of
hello, world
when LANG is set to ``Vietnamese.''
October 11, 1990 Standards Update Recent Standards Activities
- 8 -
Most programs use text strings, so the system services interface
group, dot one, has been thinking about portable library calls to sup-
ply such strings and portable formats for the files that contain them.
Actually, ``re-thinking'' is probably more accurate than ``thinking
about.'' 1003.1a Draft 9, specified a design by the UniForum Techni-
cal Committee on Internationalization. At Danvers, X/Open counter-
proposed a variant of its existing XPG3 specification, arguing that
the X/Open scheme may have problems but it also has users, while the
UniForum proposal is still in the laboratory. (It brings to mind the
apocryphal story of Stu Feldman's wanting to improve the design of
make, but feeling he couldn't because he already had seven users.)
Someone from Unisys also brought a proposal, different from both
UniForum's and X/Open's.
That no one even showed up to defend the UniForum proposal shows that
there is something wrong with standardizing messaging. One minute,
there is enough support for a messaging scheme to get it into the
draft standard; the next, there's none at all. In the end, the work-
ing group agreed that a messaging standard was premature and that the
free market should continue to operate in the area for a while.
Given the relative sizes of the organizations concerned, this outcome
probably sticks us with the X/Open scheme for a while, which I find
the ugliest of the lot. Still, it's not a standard, and there's room
for innovation and creativity if we're quick about it. The ``existing
practice'' criterion is supposed to help avoid a requirement for mas-
sive, murderous source code changes. We should be looking for the
messaging scheme that doesn't require changes in the first place, not
the one with the most existing victims.
Language_Independence_Stalls_ISO_Progress
Internationally, 1003.4 (real-time), 1003.5 (Ada bindings), and 1003.9
(FORTRAN bindings) are being held hostage by ISO, which refuses to
loose them on the world until we come up with a language-independent
binding for 1003.1. The question is, who will do the work? ``Not
I,'' says dot four, whose travel vouchers are signed by companies
caught up in the glamour of real-time and threads; ``Not I,'' say dot
five and dot nine, who seldom have even ten working-group members
apiece; ``Not I,'' say the tattered remnants of dot one, exhausted
from struggling with 1003.1-1988, FIPS-151 and 151-1, and (almost)
1003.1-1990, before any other groups have even a first standard
passed. Where is the Little Red Hen when we need her?
Should_We_Ballot_POSIX_the_Way_We_Ballot_Three-Phase_Power?
In the meantime, we progress inexorably toward balloting on several
IEEE/ANSI standards. The sizes of the drafts (and several contribu-
tors to comp.std.unix) raise real questions about whether the IEEE's
balloting process make sense for the sort of standards work POSIX is
October 11, 1990 Standards Update Recent Standards Activities
- 9 -
performing. A month or so might be enough to review a few-page
hardware standard. But is it enough for the nearly 800 pages in the
latest recirculation of dot two? Does it really make sense to review
the standard for grep in hard copy? Many would like to see longer
balloting times and on-line access to drafts. Some argue that the
final standard should be available only from the IEEE, both to insure
authenticity and to provide the IEEE with income from its standards
efforts; even that argument seems weak. Checksums can guarantee
authenticity, and AT&T's Toolchest proves that electronic distribution
works: I'll bet ksh has paid for itself several times over.
``We_handed_1201.1_its_head_and_asked_it_to_comb_its_hair.''
Moving away from POSIX, we come upon 1201.1, still in search of an
officially sanctioned mission that the group wants to take on. The
group currently has a PAR (charter) to standardize various aspects of
X-based windowing - principally the toolkit-level API - but any hope
of compromise between the OPEN LOOK and OSF/Motif factions died at the
winter-quarter Utah meetings. In a moment of responsible, adult
behavior, the group recovered by switching to a dark horse: a
window-system-independent API that could be implemented on top of
either product. Marc Rochkind's XVT, which already allows users to
write programs that are portable across several, unrelated window sys-
tems including X, the Mac, and MS-Windows, was offered as a proof-of-
concept.
While the original charter could probably encompass the new XVT work,
the group seemed to feel that this direction change, together with the
fragmenting of the original group into separate toolkit, drivability,
UIMS, and X intrinsics efforts, required that they ask the SEC for a
new charter. (The drivability group has already had a separate PAR
approved and is now 1201.2.) The group convened a pair of interim
meetings in Milpitas, California, and Boulder, Colorado, to forge a
PAR that would meet the SEC's new, stricter standards for PAR approval
by the summer Danvers meeting. They didn't succeed.
Most of the problems seem to have been administrative missteps. Some
examples:
- Working-group members complained that the Milpitas meeting took
place without enough notice for everyone to attend, and issues
that had been resolved at the interim meetings were re-opened in
Danvers.
- The PAR was so broadly written that at least one technology (Ser-
pent) was advanced as a candidate that almost no one thought
should even be considered.
- Some working-group members hadn't even received copies of the XVT
reference manual before they reached Danvers.
October 11, 1990 Standards Update Recent Standards Activities
- 10 -
- Many SEC members appeared not to have seen a copy of the PAR
until the afternoon before the SEC meeting, and some saw the
final PAR for the first time at the SEC meeting itself.
Many people who weren't familiar with the proposal ended up uneasy
about it, not because they'd read it and didn't like it - they'd not
been given much chance to read it - but because a lack of attention to
administrative details in the proposal's presentation sapped their
confidence in the group's ability to produce a sound standard. After
all, standards work is detail work. In the end, the SEC tactfully
thanked the group and asked them to try again. One SEC member said,
``We handed 1201.1 its head and asked it to comb its hair.''
I believe all of this is just inexperience, not a symptom of fundamen-
tal flaws in the group or its approach. If 1201.1 can enlist a few
standards lawyers - POSIX has no shortage of people who know how to
dot all the i's and cross all the t's - and can muster the patience to
try to move its PAR through methodically and carefully, I think the
group will give us a standard that will advance our industry. If it
doesn't do so soon, though, the SEC will stop giving it its head back.
POSIX_Takes_to_the_Slopes
Finally, I want to plug the Weirdnix contest. We currently have a
great prize- including a ski trip to Utah - and only a few entries.10
The contest closes November 21, 1990. Send your entries to me,
jsh at ico.isc.com.
__________
10. The occasionally heard suggestion that Brian Watkins was found
clutching Mitch Wagner's entry is tasteless; it is almost - but,
luckily, not quite - beneath me to repeat it.
October 11, 1990 Standards Update Recent Standards Activities
Volume-Number: Volume 21, Number 198
More information about the Comp.std.unix
mailing list