Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1989.12

Text File | 1990-05-09 | 108.4 KB | 2,524 lines

echo intro
cat >intro <<'shar.intro.29352'
From [e-mail]  Sat Dec  2 14:28:34 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06538; Sat, 2 Dec 89 14:28:34 -0500
Posted-Date: 1 Dec 89 00:36:02 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA03275; Sat, 2 Dec 89 13:28:29 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00188; Sat, 2 Dec 89 11:49:28 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: October reports from USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Dec 89 00:36:02 GMT
Apparently-To: [e-mail]

From: [e-mail] (John S. Quarterman)

Some USENIX Standards Watchdog Committee reports have come in
and have been edited by Jeffrey Haemer, the report editor.
There are several for the October IEEE 1003 meeting in Brussels.
The rest will presumably follow shortly (calling all snitches!).

We'll go ahead and publish the ones that are here now.

To start with, there is one report just received about the July 1989
meeting in San Jose, specifically about 1003.8/1.  It arrived long
after all the others, but it's quite good, and may stir up some
discussion....

John S. Quarterman <[e-mail]>
Chair, USENIX Standards Watchdog Committee

Volume-Number: Volume 17, Number 79

shar.intro.29352
echo overview
cat >overview <<'shar.overview.29352'
From [e-mail]  Sun Jan  7 23:43:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25804; Sun, 7 Jan 90 23:43:33 -0500
Posted-Date: 8 Jan 90 02:57:08 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17629; Sun, 7 Jan 90 22:43:15 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05986; Sun, 7 Jan 90 20:59:41 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 8 Jan 90 02:57:08 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

USENIX Standards Watchdog Committee Update

The reports that accompany this summary are for the Fall meeting of
IEEE 1003 and IEEE 1201, conducted the week of October 16-20, 1989, in
Brussels, Belgium.  (This isn't really true of the 1003.4 and 1003.8/1
reports, but let's overlook that.)

The reports are done quarterly, for the USENIX Association, by
volunteers from the individual standards committees.  The volunteers
are familiarly known as ``snitches'' and the reports as ``snitch
reports.'' The band of snitches and I make up the working committee of
the USENIX Standards Watchdog Committee.  The group also has a policy
committee: John S. Quarterman (chair), Alan G. Nemeth, and Shane P.
McCarron.  Our job is to let you know about things going on in the
standards arena that might affect your professional life - either now
or down the road a ways.

More formally:

     The basic USENIX policy regarding standards is:

          to attempt to prevent standards from prohibiting innovation.

     To do that, we

        o+ Collect and publish contextual and technical information
          such as the snitch reports that otherwise would be lost in
          committee minutes or rationale appendices or would not be
          written down at all.

        o+ Encourage appropriate people to get involved in the
          standards process.

        o+ Hold forums such as Birds of a Feather (BOF) meetings at
          conferences.  We sponsored one workshop on standards.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 2 -

        o+ Write and present proposals to standards bodies in specific
          areas.

        o+ Occasionally sponsor White Papers in particularly
          problematical areas, such as IEEE 1003.7 (in 1989) and
          possibly IEEE 1201 (in 1990).

        o+ Very occasionally lobby organizations that oversee standards
          bodies regarding new committees, documents, or balloting
          procedures.

        o+ Starting in mid-1989, USENIX and EUUG (the European UNIX
          Users Group) began sponsoring a joint representative to the
          ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards committee.

     There are some things we do _n_o_t do:

        o+ We do not form standards committees.  It's the USENIX
          Standards Watchdog Committee, not the POSIX Watchdog
          Committee, not part of POSIX, and not limited to POSIX.

        o+ We do not promote standards.

        o+ We do not endorse standards.

     Occasionally we may ask snitches to present proposals or argue
     positions on behalf of USENIX.  They are not required to do so
     and cannot do so unless asked by the USENIX Standards Watchdog
     Policy Committee.  Snitches mostly report.  We also encourage
     them to recommend actions for USENIX to take.

          John S. Quarterman, Chair, USENIX Standards Watchdog Committee

We don't yet have active snitches for all the committees and sometimes
have to beat the bushes for new snitches when old ones retire or can't
make a meeting, but the number of groups with active snitches is
growing steadily.  This quarter, you've seen reports from .1, .4, .5,
.6, .8/2, and a belated report of last quarter's .8/1 meeting, as well
as a report from 1201.  Reports from .2 and .7 are in the pipeline,
and may get posted before this summary does.  We have no reports from
.3, .8/[3-6], .9, .10, or .11, even though we asked Santa for these
reports for Christmas.

If you have comments or suggestions, or are interested in snitching
for any group, please contact me ([e-mail]) or John
([e-mail]).  If you want to make suggestions in person, both of
us go to the POSIX meetings.  The next set will be January 8-12, at
the Hotel Intercontinental in New Orleans, Louisiana.  Meetings after
that will be April 23-27, 1990 in Salt Lake City, Utah, and July 16-
20, 1990 in Danvers (Boston), Massachusetts.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 3 -

I've appended some editorial commentary on problems I see facing each
group.  I've emphasized non-technical problems, which are unlikely to
appear in the official minutes and mailings of the committees.  If the
comments for a particular group move you to read a snitch report that
you wouldn't have read otherwise, they've served their purpose.  Be
warned, however, that when you read the snitch report, you may
discover that the snitch's opinion differs completely from mine.

1003.0

Outside of dot zero, this group is referred to as ``the group that
lets marketing participate in POSIX.'' Meetings seem to be dominated
by representatives from upper management of large and influential
organizations; there are plenty of tailor-made suits, and few of the
jeans and T-shirts that abound in a dot one or dot two meeting.
There's a good chance that reading this is making you nervous; that
you're thinking, ``Uh, oh.  I'll bet the meetings have a lot of
politics, positioning, and discussion about `potential direction.'''
Correct.  This group carries all the baggage, good and bad, that you'd
expect by looking at it.

For example, their official job is to produce the ``POSIX Guide:'' a
document to help those seeking a path through the open-systems
standards maze.  Realistically, if the IEEE had just hired a standards
expert who wrote well to produce the guide, it would be done, and both
cleaner and shorter than the current draft.

Moreover, because dot zero can see the entire open systems standards
activities as a whole, they have a lot of influence in what new areas
POSIX addresses.  Unfortunately, politics sometimes has a heavy hand.
The last two groups whose creation dot zero recommended were 1201 and
the internationalization study group.  There's widespread sentiment,
outside of each group (and, in the case of internationalization,
inside of the group) that these groups were created at the wrong time,
for the wrong reason, and should be dissolved, but won't be.  And
sometimes, you can find the group discussing areas about which they
appear to have little technical expertise.  Meeting before last, dot
zero spent an uncomfortable amount of time arguing about graphics
primitives.

That's the predictable bad side.  The good side?  Frankly, these folks
provide immense credibility and widespread support for POSIX.  If dot
zero didn't exist, the only way for some of the most important people
and organizations in the POSIX effort to participate would be in a
more technical group, where the narrow focus would block the broad
overview that these folks need, and which doing the guide provides.

In fact, from here it looks as though it would be beneficial to POSIX
to have dot zero actually do more, not less, than it's doing.  For
example, if dot five is ever going to have much impact in the Ada

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 4 -

community, someone's going to have to explain to that community why
POSIX is important, and why they should pay more attention to it.
That's not a job for the folks you find in dot five meetings (mostly
language experts); it's a job for people who wear tailor-made suits;
who understand the history, the direction, and the importance of the
open systems effort; and who know industry politics.  And there are
members of dot zero who fit that description to a tee.

1003.1

Is dot one still doing anything, now that the ugly green book is in
print?  Absolutely.

First, it's moved into maintenance and bug-fix mode.  It's working on
a pair of extensions to dot 1 (A and B), on re-formatting the ugly
green book to make the ISO happy, and on figuring out how to make the
existing standard language-independent.  (The developer, he works from
sun to sun, but the maintainer's work is never done.) Second, it's
advising other groups and helping arbitrate their disputes.  An
example is the recent flap over transparent file access, in which the
group defining the standard (1003.8/1) was told, in no uncertain
terms, that NFS wouldn't do, because it wasn't consistent with dot one
semantics.  One wonders if things like the dot six chmod dispute will
finally be resolved here as well.

A key to success will be keeping enough of the original dot one
participants available and active to insure consistency.

1003.2

Dot one standardized the UNIX section two and three commands.  (Okay,
okay.  All together now: ``It's not UNIX, it's POSIX.  All resemblance
to any real operating system, living or dead, explicit or implied, is
purely coincidental.'') Dot two is making a standard for UNIX section
one commands.  Sort of.

The dot two draft currently in ballot, ``dot-two classic,'' is
intended to standardize commands that you'd find in shell scripts.
Unfortunately, if you look at dot-two classic you'll see things
missing.  In fact, you could have a strictly conforming system that
would be awfully hard to to develop software on or port software to.
To solve this, NIST pressured dot two into drawing up a standard for a
user portability extension (UPE).  The distinction is supposed to be
that dot-two classic standardizes commands necessary for shell script
portability, while the UPE standardizes things that are primarily
interactive, but aid user portability.

The two documents have some strategic problems.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 5 -

   o+ Many folks who developed dot-two classic say the UPE is outside
     of dot two's charter, and won't participate in the effort.  This
     sort of behavior unquestionably harms the UPE.  Since I predict
     that the outside world will make no distinction between the UPE
     and the rest of the standard, it will actually harm the entire
     dot-two effort.

   o+ The classification criteria are unconvincing.  Nm(1) is in the
     UPE.  Is it really primarily used interactively?

   o+ Cc has been renamed c89, and lint may become lint89.  This is
     silly and annoying, but look on the bright side: at least we can
     see why c89 wasn't put in the UPE.  Had it been, it would have
     had to have a name users expected.

   o+ Who died and left NIST in charge?  POSIX seems constantly to be
     doing things that it didn't really want to do because it was
     afraid that if it didn't, NIST would strike out on its own.
     Others instances are the accelerated timetables of .1 and .2, and
     the creation of 1003.7 and 1201.)

   o+ Crucial pieces of software are missing from dot two.  The largest
     crevasse is the lack of any form of source-code control.  People
     on the committee don't want to suffer through an SCCS-RCS debate.
     POSIX dealt with the cpio-tar debate.  (It decided not to
     decide.) POSIX dealt with the vi-emacs debate.  (The UPE provides
     a standard for ex/vi.) POSIX is working on the NFS-RFS debate,
     and a host of others.  Such resolutions are a part of its
     responsibility and authority.  POSIX is even working on the
     Motif-Open/Look debate (whether it should or not).

     At the very least, the standard could require some sort of source
     code control, with an option specifying which flavor is
     available.  Perhaps we could ask NIST to threaten to provide a
     specification.

As a final note, because dot two (collective) standardizes user-level
commands, it really can provide practical portability across operating
systems.  Shell scripts written on a dot-two-conforming UNIX system
should run just fine on an MS-DOS system under the MKS toolkit.

1003.3

Dot three is writing test assertions for standards.  This means dot
three is doing the most boring work in the POSIX arena.  Oh, shoot,
that just slipped out.  But what's amazing is that the committee
members don't see it as boring.  In fact, Roger Martin, who, as senior
representative of the NIST, is surely one of the single most
influential people in the POSIX effort, actually chairs this
committee.  Maybe they know something I don't.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 6 -

Dot three is balloting dot one assertions and working on dot two.  The
process is moving at standards-committee speed, but has the advantage
of having prior testing art as a touchstone (existing MindCraft, IBM,
and NIST test work).  The dilemma confronting the group is what to do
about test work for other committees, which are proliferating like
lagomorphs.  Dot three is clearly outnumbered, and needs some
administrative cavalry to come to its rescue.  Unless it expands
drastically (probably in the form of little subcommittees and a
steering committee) or is allowed to delegate some of the
responsibility of generating test assertions to the committees
generating the standards, it will never finish.  (``Whew, okay, dot
five's done.  Does anyone want to volunteer to be a liaison with dot
thirty-seven?'')

1003.4

Dot four is caught in a trap fashioned by evolution.  It began as a
real-time committee.  Somehow, it's metamorphosed into a catch-all,
``operating-system extensions'' committee.  Several problems have
sprung from this.

   o+ Some of the early proposed extensions were probably right for
     real-time, but aren't general enough to be the right approach at
     the OS level.

   o+ Pieces of the dot-four document probably belong in the the dot
     one document instead of a separate document.  Presumeably, ISO
     will perform this merge down the road.  Should the IEEE follow
     suit?

   o+ Because the dot-four extensions aren't as firmly based in
     established UNIX practice as the functionality specified in dot
     one and two, debate over how to do things is more heated, and the
     likelihood that the eventual, official, standard solution will be
     an overly complex and messy compromise is far higher.  For
     example, there is a currently active dispute about something as
     fundamental as how threads and signals should interact.

Unfortunately, all this change has diverted attention from a problem
that has to be dealt with soon - how to guarantee consistency between
dot four and dot five, the Ada-language-binding group.  Tasks
semantics are specified by the Ada language definition.  In order to
get an Ada binding to dot four's standard (which someone will have to
do), dot four's threads will have to be consistent with the way dot
five uses tasks in their current working document.  With dot five's
low numbers, the only practical way to insure this seems to be to have
dot four aggressively track the work of dot five.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 7 -

1003.5

Dot five is creating an Ada-language binding for POSIX.  What's
``Ada-language binding'' mean?  Just that an Ada programmer should be
able to get any functionality provided by 1003.1 from within an Ada
program.  (Right now, they're working on an Ada-language binding for
the dot one standard, but eventually, they'll also address other
interfaces, including those from dot four, dot six, and dot eight.)
They face at least two kinds of technical problems and one social one.

The first technical problems is finding some way to express everything
in 1003.1 in Ada.  That's not always easy, since the section two and
three commands standardized by dot one evolved in a C universe, and
the semantics of C are sometimes hard to express in Ada, and vice-
versa.  Examples are Ada's insistence on strong typing, which makes
things like ioctl() look pretty odd, and Ada's tasking semantics,
which require careful thinking about fork(), exec(), and kill().
Luckily, dot five is populated by people who are Ada-language wizards,
and seem to be able to solve these problems.  One interesting
difference between dot five and dot nine is that the FORTRAN group has
chosen to retain the organization of the original dot one document so
that their document can simply point into the ugly green book in many
cases, whereas dot five chose to re-organize wherever it seemed to
help the flow of their document.  It will be interesting to see which
decision ends up producing the most useful document.

The second technical problem is making the solutions look like Ada.
For more discussion of this, see the dot-nine (FORTRAN bindings)
summary.  Again, this is a problem for Ada wizards, and dot five can
handle it.

The social problem?  Interest in dot five's work, outside of their
committee, is low.  Ada is out-of-favor with most UNIX programmers.
(``Geez, 1201 is a mess.  Their stuff's gonna look as ugly as Ada.'')
Conversely, most of the Ada community's not interested in UNIX.
(``Huh?  Another `standard' operating environment?  How's it compare
to, say, PCTE?  No, never mind.  Just let me know every few years how
it's coming along.'') The group that has the hardest problem - welding
together two, well-developed, standardized, disparate universes - has
the least help.

Despite all of this, the standard looks like it's coming close to
ballot, which means people ought to start paying attention to it
before they have no choice.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 8 -

1003.6

Most of the UNIX community would still feel more at home at a Rainbow
gathering than reading the DOD rainbow books.  The unfamiliar-buzzword
frequency at dot six (security) meetings is quite high.  If you can
get someone patient to explain some of the issues, though, they're
pretty interesting.  The technical problems they're solving each boil
down to thinking through how to graft very foreign ideas onto UNIX
without damaging it beyond recognition.  (The recent posting about
chmod and access control lists, in comp.std.unix by Ana Maria de
Alvare and Mike Ressler, is a wonderful, detailed example.)

Dot six's prominent, non-technical problem is just as interesting.
The government has made it clear that vendors who can supply a
``secure UNIX'' will make a lot of money.  No fools, major vendors
have begun been furiously working on implementations.  The push to
provide a POSIX security standard comes at a time when these vendors
are already quite far along in their efforts, but still some way from
releasing the products.  Dot six attendees from such corporations
can't say too much, because it will give away what they're doing
(remember, too, that this is security), but must, somehow insure that
the standard that emerges is compatible with their company's existing,
secret implementation.

1003.7

There is no single, standard body of practice for UNIX system
administration, the area dot seven is standardizing.  Rather than seek
a compromise, dot seven has decided to re-invent system administration
from scratch.  This was probably necessary simply because there isn't
enough existing practice to compromise on.  Currently, their intent is
to provide an object-oriented standard, with objects specified in
ASN.1 and administration of a multi-machine, networked system as a
target.  (This, incidentally, was the recommendation of a USENIX White
Paper on system administration by Susanne Smith and John Quarterman.)
The committee doesn't have a high proportion of full-time system
administrators, or a large body of experience in object-oriented
programming.  It's essentially doing research by committee.  Despite
this, general sentiment outside the committee seems to be that it has
chosen a reasonable approach, but that progress may be slow.

A big danger is that they'll end up with a fatally flawed solution:
lacking good, available implementations; distinct enough from existing
practices, where they exist, to hamper adoption; and with no clear-cut
advantage to be gained by replacing any ad-hoc, existing, solutions
except for standard adherence.  The standard could be widely ignored.

What might prevent that from happening?  Lots of implementations.
Object-oriented programming and C++ are fashionable (at the 1988,

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 9 -

Winter Usenix C++ conference, Andrew Koenig referred to C++ as a
``strongly hyped language''); networked, UNIX systems are ubiquitous
in the research community; and system administration has the feeling
of a user-level, solvable problem.  If dot seven (perhaps with the
help of dot zero) can publicize their work in the object-oriented
programming community, we can expect OOPSLA conferences and
comp.sources.unix to overflow with high-quality, practical, field-
tested, object-oriented, system administration packages that conform
to dot seven.

1003.8

There are two administrative problems facing dot eight, the network
services group.  Both stem directly from the nature of the subject.
There is not yet agreement on how to solve either one.

The first is its continued growth.  There is now serious talk of
making each subgroup a full-fledged POSIX committee.  Since there are
currently six groups (transparent file access, network IPC, remote
procedure call, OSI/MAP services, X.400 mail gateway, and directory
services), this would increase the number of POSIX committees by
nearly 50%, and make networking the single largest aspect of the
standards work.  This, of course, is because standards are beneficial
in operating systems, and single-machine applications, but
indispensible in networking.

The second is intergroup coordination.  Each of the subgroups is
specialized enough that most dot eight members only know what's going
on in their own subgroup.  But because the issues are networking
issues, it's important that someone knows enough about what each group
is doing to prevent duplication of effort or glaring omissions.  And
that's only a piece of the problem.  Topics like system administration
and security are hard enough on a single, stand-alone machine.  In a
networked world, they're even harder.  Someone needs to be doing the
system engineering required to insure that all these areas of overlap
are addressed, addressed exactly once, and completed in time frames
that don't leave any group hanging, awaiting another group's work.

The SEC will have to sort out how to solve these problems.  In the
meantime, it would certainly help if we had snitches for each subgroup
in dot eight.  Any volunteers for .8/[3-6]?

1003.9

Dot nine, which is providing FORTRAN bindings, is really fun to watch.
They're fairly un-structured, and consequently get things done at an
incredible clip.  They're also friendly; when someone new arrives,
they actually stop, smile, and provide introductions all around.  It
helps that there are only half-a-dozen attendees or so, as opposed to

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 10 -

the half-a-hundred you might see in some of the other groups.
Meetings have sort of a ``we're all in this together/defenders of the
Alamo'' atmosphere.

The group was formed after two separate companies independently
implemented FORTRAN bindings for dot one and presented them to the
UniForum technical committee on supercomputing.  None of this, ``Let's
consider forming a study group to generate a PAR to form a committee
to think about how we might do it,'' stuff.  This was rapid
prototyping at the standards level.

Except for the advantage of being able to build on prior art (the two
implementations), dot nine has the same basic problems that dot five
has.  What did the prior art get them?  The most interesting thing is
that a correct FORTRAN binding isn't the same as a good FORTRAN
binding.  Both groups began by creating a binding that paralleled the
original dot one standard fairly closely.  Complaints about the
occasional non-FORTRANness of the result have motivated the group to
try to re-design the bindings to seem ``normal'' to typical FORTRAN
programmers.  As a simple example, FORTRAN-77 would certainly allow
the declaration of a variable in common called ERRNO, to hold the
error return code.  Users, however, would find such name misleading;
integer variables, by default and by convention, begin with ``I''
through ``N.''

It is worth noting that dot nine is actually providing FORTRAN-77
bindings, and simply ignoring FORTRAN-8x.  (Who was it that said of
8x, ``Looks like a nice language.  Too bad it's not FORTRAN''?)
Currently, 1003 intends to move to a language-independent
specification by the time 8x is done, which, it is claimed, will ease
the task of creating 8x bindings.

On the surface, it seems logical and appealing that documents like
1003.1 be re-written as a language-independent standard, with a
separate C-language binding, analogous to those of dot five and dot
nine.  But is it really?

First, it fosters the illusion that POSIX is divorced from, and
unconstrained by its primary implementation language.  Should the
prohibition against nul characters in filenames be a base-standard
restriction or a C-binding restriction?

I've seen a dot five committee member argue that it's the former.
Looked at in isolation, this is almost sensible.  If Ada becomes the
only language anyone wants to run, yet the government still mandates
POSIX compliance, why should a POSIX implementation prohibit its
filenames from containing characters that aren't special to Ada?  At
the same time, every POSIX attendee outside of dot five seems repelled
by the idea of filenames that contain nuls.  (Quiz: Can you specify a
C-language program or shell script that will create a filename
containing a nul?)

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 11 -

Second, C provides an existing, precise, widely-known language in
which POSIX can be specified.  If peculiarities of C make implementing
some portions of a standard, specified in C, difficult in another
language, then there are four, clear solutions:

  1.  change the specification so that it's equally easy in C and in
      other languages,

  2.  change the specification so that it's difficult in every
      language,

  3.  change the specification so that it's easy in some other
      language but difficult in C

  4.  make the specification vague enough so that it can be done in
      incompatible (though equally easy) ways in each language.

Only the first option makes sense.  Making the specification
language-independent means either using an imprecise language, which
risks four, or picking some little-known specification language (like
VDL), which risks two and three.  Declaring C the specification
language does limit the useful lifetime of POSIX to the useful
lifetime of C, but if we don't think we'll come up with good
replacements for both in a few decades, we're facing worse problems
than language-dependent specifications.

Last, if you think the standards process is slow now, wait until the
IEEE tries to find committee volunteers who are fluent in both UNIX
and some language-independent specification language.  Not only will
the useful lifetime of POSIX remain wedded to the useful lifetime of
C, but both will expire before the language-independent version of dot
one is complete.

It would be nice if this push for language-independent POSIX would go
away quietly, but it won't.

1003.10

In July, at the San Jose meeting, John Caywood of Unisys caught me in
the halls and said, accusingly, ``I understand you're think
supercomputers don't need a batch facility.'' I didn't have the
foggiest idea what he was talking about, but it seemed like as good a
chance as any to get a tutorial on dot ten, the supercomputing group,
so I grabbed it. (Pretty aggressively helpful folks in this
supercomputing group.  If only someone in it could be persuaded to
file a snitch report.)

Here's the story:

     Articles about software engineering like to point out that

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 12 -

     approaches and tools have changed from those used twenty years
     ago; computers and computing resources are now much cheaper than
     programmers and their time, while twenty years ago the reverse
     was true.  These articles are written by people who've never used
     a Cray.  A typical supercomputer application might run on a $25M,
     non-byte-addressable, non-virtual-memory machine, require 100 to
     1000 Mbytes of memory, and run for 10 Ksecs.  Expected running
     time for jobs can be greater than the machine's mean-time-to-
     failure.  The same techniques that were common twenty years ago
     are still important on these machines, for the same reasons -
     we're working close to the limits of hardware art.

The card punches are gone, but users often still can't login to the
machines directly, and must submit jobs through workstation or
mainframe front ends.  Resources are severely limited, and access to
those resources need to be carefully controlled.  The two needs that
surface most often are checkpointing, and a batch facility.

Checkpointing lets you re-start a job in the middle.  If you've used
five hours of Cray time, and need to continue your run for another
hour but have temporarily run out of grant money, you don't want to
start again from scratch when the money appears.  If you've used six
months of real time running a virus-cracking program and the machine
goes down, you might be willing to lose a few hours, even days, of
work, but can't afford to lose everything.  Checkpointing is a hard
problem, without a generally agreed-upon solution.

A batch facility is easier to provide.  Both Convex and Cray currently
support NQS, a public-domain, network queueing system.  The product
has enough known problems that the group is re-working the facility,
but the basic model is well-understood, and the committee members,
both users and vendors, seem to want to adopt it.  The goal is
command-level and library-level support for batch queues that will
provide effective resource management for really big jobs.  Users will
be able to do things like submit a job to a large machine through a
wide-area network, specify the resources - memory, disk space, time,
tape drives, etc. - that the job will need to run to completion, and
then check back a week or two later to find out how far their job's
progressed in the queue.

The group is determined to make rapid progress, and to that end is
holding 6-7 meetings a year.  One other thing: the group is actually
doing an application profile, not a standards document.  For an
clarification of the distinction, see the discussion of dot eleven.

1003.11

Dot eleven has begun work on an application profile (AP) on
transaction processing (TP).  An AP is a set of pointers into the
POSIX Open System Environment (OSE).  For example, the TP AP might

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 13 -

say, ``For dot eleven conformance, you need to conform to dot one, dot
four, sections 2.3.7 and 2.3.8 of dot 6, 1003.8 except for /2, and
provide a batch facility as specified in the dot 10 AP.'' A group
doing an AP will also look for holes or vague areas in the existing
standards, as they relate to the application area, go point them out
to the appropriate committee, and possibly chip in to help the
committee solve them.  If they find a gap that really doesn't fall
into anyone else's area, they can write a PAR, requesting that the SEC
(1003's oversight committee) charter them to write a standard to cover
it.

Dot eleven is still in the early, crucial stage of trying to figure
out what it wants to do.  Because of fundamental differences in
philosophy of the members, the group seems to be thrashing a lot.
There is a clear division between folks who want to pick a specific
model of TP and write an AP to cover it, and folks who think a model
is a far-too-detailed place to start.  The latter group is small, but
not easily dismissed.

It will be interesting to see how dot eleven breaks this log jam, and
what the resolution is.  As an aside, many of the modelers are from
the X/OPEN and ISO TP groups, which are already pushing specific
models of their own; this suggests what kinds of models we're likely
to get if the modeling majority wins.

X3J11

A single individual, Russell Hansberry, is blocking the official
approval of the ANSI standard for C on procedural grounds.  At some
point, someone failed to comply with the letter of IEEE rules for
ballot resolution.  and Hansberry is using the irregularity to delay
adoption of the standard.

This has had an odd effect in the 1003 committees.  No one wants to
see something like this inflicted on his or her group, so folks are
being particularly careful to dot all i's and cross all t's.  I say
odd because it doesn't look as though Hansberry's objections will have
any effect whatsoever on either the standard, or its effectiveness.
Whether ANSI puts its stamp on it or not, every C compiler vendor is
implementing the standard, and every book (even K&R) is writing to it.
X3J11 has replaced one de-facto standard with another, even stronger
one.

1201.1

What's that you say, bunky?  You say you're Jewish or Moslem, and you
can look at Xwindows as long as you don't eat it?  Well then, you
won't care much for 1201.1, which is supposed to be ``User Interface:
Application Programming Interface,'' but is really ``How much will the

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 14 -

Motif majority have to compromise with the Open/Look minority before
force-feeding us a thick standard full of `Xm[A-Z]...' functions with
long names and longer argument lists?''

Were this group to change its name to ``Xwindows application
programming interface,'' you might not hear nearly as much grousing
from folks outside the working group.  As it is, the most positive
comments you hear are, ``Well, X is pretty awful, but I guess we're
stuck with it,'' and ``What could they do?  If POSIX hadn't undertaken
it, NIST would have.''

If 1201 is to continue to be called ``User Interface,'' these aren't
valid arguments for standardizing on X or toolkits derived from it.
In what sense are we stuck with X?  The number of X applications is
still small, and if X and its toolkits aren't right for the job, it
will stay small.  Graphics hardware will continue to race ahead,
someone smart will show us a better way to do graphics, and X will
become a backwater.  If they are right, some toolkit will become a
de-facto standard, the toolkit will mature, and the IEEE can write a
realistic standard based on it.

Moreover, if NIST wants to write a standard based on X, what's wrong
with that?  If they come up with something that's important in the
POSIX world, good for them.  ANSI or the IEEE can adopt it, the way
ANSI's finally getting around to adopting C.  If NIST fails, it's not
the IEEE's problem.

If 1201.1 ignores X and NIST, can it do anything?  Certainly.  The
real problem with the occasionally asked question, ``are standards
bad?'' is that it omits the first word: ``When.'' Asked properly, the
answer is, ``When they're at the wrong level.'' API's XVT is example
of a toolkit that sits above libraries like Motif or the Mac toolbox,
and provides programmers with much of the standard functionality
necessary to write useful applications on a wide variety of window
systems.  Even if XVT isn't the answer, it provides proof by example
that we can have a window-system-independent, application programming
interface for windowing systems.  1201.1 could provide a useful
standard at that level.  Will it?  Watch and see.

December 1989 Standards Update     USENIX Standards Watchdog Committee


Volume-Number: Volume 18, Number 10

shar.overview.29352
echo 1003.0
cat >1003.0 <<'shar.1003.0.29352'
From [e-mail]  Sat Dec  2 15:57:16 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18688; Sat, 2 Dec 89 15:57:16 -0500
Posted-Date: 2 Dec 89 19:20:41 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06164; Sat, 2 Dec 89 14:57:11 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00494; Sat, 2 Dec 89 13:21:16 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:20:41 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>




            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide Update

Kevin Lewis <[e-mail]> reports on the October 16-20,
1989 meeting in Brussels, Belgium:

Dot Zero's mission in Brussels was to step back and review where the
group had been, where we were, and where we needed to go. When we did,
we saw that we hadn't gone quite where we had wanted.  This has
brought us to a place we don't necessarily want to be and will make
the remaining trip to where we plan to go longer than we'd like.  I'll
quickly add that we are now headed in the right basic direction but
still need to make some course corrections.

There are two major contributors to this state of affairs. First, an
honest review of the pre-Brussels document reveals that it still has
significant holes.  Also, its format makes what is there hard to
follow.  I must admit that it felt good to see unanimous (yes,
unanimous) consent on both the need to re-organize the document and on
a new format.  It does a co-chair's heart good to see two such rare
events occur concurrently. The reformatting of the draft guide will be
complete by the January meeting in New Orleans.  The group will then
review components of the document that are sufficiently complete
section-by-section and line-by-line.

Second, Dot Zero faces a problem that is becoming widespread in 1003
and TCOS-SS: a serious dilution of effort.  Little did Dot Zero
realize, when it recommended the formation of a group to address a
windows standard (now 1201), that we would lose people who had been
shepherding key components of the Dot Zero guide. With the voracious
growth of Dot Ate (oops), I see no end to this in sight.  The new
efforts have left us with no one to cover networking, graphics, or
windows, though it's possible that new folks in these areas will join
us in New Orleans.  [Editor's note: Listen to this man.  What are your
ideas about open systems in these areas?  If you have something useful
to contribute, please contact someone on dot zero -- Kevin, for
example.  Don't just wait until it's too late and then complain about
the result.]

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update                IEEE 1003.0: POSIX Guide


                                - 2 -

Regarding internationalization (for which the current buzzword is
"I18N", because there are eighteen letters between the 'I' and the
'N'):

Everyone who attended the I18N study group meeting sponsored by Dot
Zero found it most interesting in the end when the question regarding
the group's future was posed.  All those present tacitly agreed that
it would not be in the best interests of I18N efforts for this study
group to become a full-fledged working group.  This study group would
best serve the industry as a forum for issue flagellation, soap-
boxing, and formation of proposals to the appropriate accredited
bodies.  At the appropriate time, the I18N group will declare that its
time is up.  When that will be is yet to be determined.

When the question of identifying the major contributors to the I18N
efforts arose, I did notice an effort on the part of OSF to remain at
arm's distance from X/Open, in light of OSF's membership in X/Open,
signifying its desire to maintain its own identity.

That's enough negatives.  Is there an up-side to all this?. Yes,
absolutely.  We have a re-organized document that will ease and
streamline the review process.  We now have the eyes of the industry
and the press looking over our shoulders, eager to read our guide.
And we are reaching the point where fear of personal and professional
embarrassment is motivating those who have an interest in this
effort's succeeding (which is almost everyone, I think).  These will
combine to help us meet our goal of readying a draft for review and
comment by ISO by the fall of 1990.  (Why are you laughing...?  GEE!!
I get no respect!!!)

December 1989 Standards Update                IEEE 1003.0: POSIX Guide


Volume-Number: Volume 17, Number 81

shar.1003.0.29352
echo 1003.1
cat >1003.1 <<'shar.1003.1.29352'
From [e-mail]  Sat Dec  2 15:57:32 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18701; Sat, 2 Dec 89 15:57:32 -0500
Posted-Date: 2 Dec 89 19:24:11 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06174; Sat, 2 Dec 89 14:57:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00554; Sat, 2 Dec 89 13:24:52 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:24:11 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>



            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.1: System services interface Update

Mark Doran <[e-mail]> reports on the October 16-20, 1989 meeting
in Brussels, Belgium:

P1003.1 is now a full-use standard, so interest in attending the
working group has wained somewhat.  Attendance didn't get above
fifteen or so all week and was nearer half a dozen most of the time.
Even so, this was a bit low by comparison with recent meetings.  So
where was everyone?

[Editor's note -- Notice that this is larger than the attendance at
typical meetings of, for example, dot nine.  "Low attendance" is
relative.
Author's additional note -- And that's the frightening thing;
standards being established by as few as half a dozen _i_n_d_i_v_i_d_u_a_l_s.
This cannot be representative or balanced.  Scary stuff, "...as we
take you on a journey, into the Standards Zone..."]

We were all lead to believe that meeting in Brussels was going to
further the cause of international participation in the POSIX process.
Several people I would normally expect to see, didn't show; Europe
must be too far from home for a lot of the regulars.  Unfortunately,
neither did I see more than two or three European types (whom I would
not normally expect to see at POSIX) all week either.  Oh well, I'm
sure it was a good idea really...

So what did those that showed get up to?  Well, in chronological
order:

  1.  ISO 9945 Status and Document Format

  2.  P1003.1a Balloting

  3.  Transparent File Access

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 2 -

  4.  Language-Independent Specification

  5.  Messaging

  6.  P1003.1b

In detail:

  1.  ISO 9945

      [Editor's note -- ISO 9945 is, roughly, the ISO standard
      engendered by and corresponding to the POSIX work.]

      It looks like 9945 is going to be split up into three major
      pieces, the first of which is founded upon the IEEE P1003.1-1988
      standard.  This piece is likely to include all the other system
      interfaces as well (notably, the real time stuff from P1003.4).
      The other two pieces will be based around utilities and system
      administration.

      The basic IS9945-1:1989 will be just the same as the regular,
      ugly-green, dot-one book -- well almost.  ISO has yet another
      documentation format and the book will have to be squeezed to
      fit it.  And before you ask, this one doesn't allow line numbers
      either.  We are assured that making the changes is not a major
      problem, but the working group has still requested a new
      disclaimer telling readers that all mistakes are the fault of
      ISO!

  2.  P1003.1a

      [Editor's note -- This document (supplement A) is supposed to
      contain clarifications of and corrections to P1003.1-1988, but
      no substantive changes.]

      The meeting discussed resolution issues from the first ballot.

      Highlights included:

         - the decision to withdraw the cuserid() interface; its loss
           will not be sadly mourned since one can use other
           interfaces to do the same job better.

         - the addition of a new type name ssize_t (yes, two s's) to
           represent signed size_t values; this has all sorts of uses
           -- for example, in the prototype for read().  Currently,
           the parameter specifying the number of bytes to be read()
           is given as a size_t, but read() has been specified to

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 3 -

           return an int, which this may not be large enough to hold a
           size_t character count.  Moreover, read() may return -1 for
           failure, or the number of characters read if the call was
           successful.

      The recirculation ballot happened between November 10-20; if you
      care but didn't know that already, it doesn't matter because you
      (and many others, I suspect) have missed your chance.  This all
      seems a bit fast but it does mean that P1003.1a will hit an ISO,
      six-month, letter-ballot window; standards must progress you
      know...

  3.  Transparent File Access

      Isn't this a P1003.8 problem?  Yes, but the chair of the TFA
      committee came to talk about TFA semantics as they relate to
      P1003.1.

      The crux of the matter is that the TFA folks (all six of
      them...) seem to have decided that standardizing NFS will do
      nicely for TFA.  Their chair wonders whether the rest of the
      world (or, more accurately, the balloting group for a TFA
      standard) will agree.

      The answer from the dot one folks appears to be definitely not
      (thank goodness)!  There appear to be several arguments against
      NFS as the TFA standard from dot one.  These include:

         - It is impossible to maintain full dot one semantics over a
           network using NFS.  Consider the last-close semantics, for
           example, which can only be preserved over a network using a
           connection-oriented protocol, which NFS is not.

         - Transparent File Access should be _t_r_a_n_s_p_a_r_e_n_t; NFS isn't.
           It is possible for operations that are logically sound to
           fail because of network timeouts.

         - NFS is a _d_e _f_a_c_t_o standard; why should it get an official
           rubber stamp?

      This appears to be a hot topic that many groups may have an
      interest in, so there will be an "out-of-hours" meeting on TFA
      at the New Orleans POSIX -- If you care at all, I suggest you
      try to show up...  [Editor's note -- If you do care but can't go
      to New Orleans, we suggest either writing directly to the TFA
      chair, Jason Zions <[e-mail]>, or posting your
      opinions to comp.std.unix.]

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 4 -

  4.  Language-Independent Specification

      It seems to have been decided that POSIX API standards should be
      written in a language-independent form, i.e. not expressed in
      C-language constructs.

      My initial reaction was one of horror, but then someone quietly
      pointed out to me that C is not the only programming language in
      the known universe.  This I have to concede, along with the idea
      that bindings to POSIX APIs in other languages may not be such a
      bad idea after all.  Indeed work is well underway to produce
      FORTRAN and ADA bindings.

      But now it seems we have to express POSIX in a language-
      independent way.  "Why?" I ask...  Well, this means that when
      you come to write the next set of actual language bindings, the
      semantics you'll need to implement won't be clouded with
      language-dependent stuff; the idea is that you won't have to
      understand C in all its "glory" to write new language bindings.

      So what will the language-independent specifications look like?
      Will I be able to understand those?  The current proposal
      doesn't look like anything I recognize at all.  Yes, that's
      right, we have to learn a whole NEW language (sigh).  Why not
      use a more formal specification language that a few people know?
      (Like ASN.1 for example, which P1003.7 has decided to use.)
      Better yet, why not use constrained English -- lots of people
      can read that...

      Come to think of it, since the FORTRAN and ADA bindings folks
      have managed without the aid of language-independent
      specifications, why can't everyone else?  Is there more to this
      than a glorified job creation scheme?  ("Wanted: expert in POSIX
      'language-independent' language...") If there is, do we have to
      invent a new wheel to get the job done?

      As you can tell, my opinion of this effort is somewhat
      jaundiced.  Perhaps, you may say, I have missed the point.
      Maybe so; but if I have, I feel sure that some kind soul will be
      only too happy to correct me in "flaming" detail :-)

  5.  Messaging

      The UniForum internationalization (I18N) folks brought forward a
      proposal for a messaging facility to be included in P1003.1b.
      The working group decided that it needs some more work but will
      go into the next draft.

      [Editor's note -- The problem being solved here is that
      internationalized applications store all user-visible strings in
      external files, so that vendors and users can change the

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 5 -

      language of an application without recompiling it.  The UniForum
      I18N group is proposing a standard format for those files.]

  6.  P1003.1b

      Work on production of the second supplement is still at a
      formative stage.  Indeed, the group is still accepting formal
      proposals for functionality to add to the document.  Where
      P1003.1a has been drawn up as a purely corrective instrument,
      P1003.1b may add new functionality.  Among the interesting
      things currently included are these:

         - The messaging proposal described above.

         - A set of interfaces to provide symbolic links.  The basic
           idea is that lstat(), readlink() and symlink() operate on
           the link, and all other interfaces operate on the linked-to
           file.

           Rationale will be added to explain that '..' is a unique
           directory, which is the parent directory in the same
           physical file system.  This means that cd does not go back
           across symlinks to the directory you came from.

           This is the same as the semantics on my Sun.  For example:

           (sunset) 33 % pwd
           /usr/spare/ins.MC68020/md/train
           (sunset) 34 % ls -ld ./MR_C++
           lrwxrwxrwx  1 root  32 Sep 30  1988 MR_C++ -> /usr/sunset/md/c++/trainset/c++/
           (sunset) 35 % cd MR_C++
           (sunset) 36 % pwd
           /usr/sunset/md/c++/trainset/c++
           (sunset) 37 % cd ..
           (sunset) 38 % pwd
           /usr/sunset/md/c++/trainset

           The rationale is meant to help keep readers' eyes on what's
           really written in the standard and help them avoid
           misinterpreting it along lines of their own potential
           misconceptions.

         - P1003.1b used to have two descriptions of Data Interchange
           formats.  Now it has only one.  The working group picked
           the one that remains because it more closely existing

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 6 -

           standards in the area, in particular the surviving proposal
           refers to X3.27.

December 1989 Standards Update  IEEE 1003.1: System services interface


Volume-Number: Volume 17, Number 82

shar.1003.1.29352
echo 1003.2
cat >1003.2 <<'shar.1003.2.29352'
From [e-mail]  Sat Jan  6 14:06:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11102; Sat, 6 Jan 90 14:06:16 -0500
Posted-Date: 6 Jan 90 15:08:21 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA16930; Sat, 6 Jan 90 13:06:09 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00951; Sat, 6 Jan 90 09:09:07 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 6 Jan 90 15:08:21 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools Update

Randall Howard <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

Background on POSIX.2

The POSIX.2 standard deals with the shell programming language and
utilities.  Currently, it is divided into two pieces:

   + POSIX.2, the base standard, deals with the basic shell
     programming language and a set of utilities required for
     application portability.  Application portability essentially
     means portability of shell scripts and thus excludes most
     features that might be considered interactive.  In an analogy to
     the ANSI C standard, the POSIX.2 shell command language is the
     counterpart of the C programming language, while the utilities
     play, roughly, the role of the C library.  POSIX.2 also
     standardizes command-line and function interfaces related to
     certain POSIX.2 utilities (e.g., popen, regular expressions,
     etc.) [Editor's note - This document is also known as "Dot 2
     Classic".]

   + POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base POSIX.2 standard; it will eventually be an optional
     chapter of a future draft of the base document.  The UPE
     standardizes commands, such as screen editors, that might not
     appear in shell scripts but are important enough that users must
     learn them on any real system.  It is essentially an interactive
     standard that attempts to reduce retraining costs incurred by
     system-to-system variation.

     Some utilities, have interactive as well as non-interactive
     features In such cases, the UPE defines extensions from the base
     POSIX.2 command.  An example is the shell, for which the UPE
     defines job control, history, and aliases.  Features used both
     interactively and in scripts tend to be defined in the base

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update            IEEE 1003.2: Shell and tools


                                - 2 -

     standard.

In my opinion, the biggest current problem with the UPE is that it
lacks a coherent view: it's becoming a repository for features that
didn't make it into the base standard.  For example, compress is in
the current UPE draft.  It's hard to rationalize classifying file
formats as an "interactive" or "user portability" issue, yet the one
used by compress is specified in the UPE.  It certainly doesn't fit in
with a view of the UPE as a standard that merely adds utility syntax
information (e.g., information that would allow users to type the same
command line to compress a file on any system).  This highlights the
schizophrenic nature of the UPE: it addresses a range of different
needs that, taken together, do not appear to define a whole.  Dot 2
Classic, to my taste, appears to have far more unified scope and
execution.

A second, related, problem with the UPE is that there appears to be
less enthusiasm for it than for the base standard.  A number of
people, including me, understand the need for it, but it doesn't
appear to have the strategic importance of the base.  [Editor's note -
The UPE is, frankly, controversial.  Like 1201, the committee
undertook the UPE out of a fear that if they didn't, NIST would do the
job without them.  Supporters note that although its utilities are
probably not necessary for portability of most software, it would be
unpleasant for programmers to do the porting work without them.
Detractors counter that POSIX was never intended to cover software
development and that the group is exceeding not only its charter, but
that of the entire 1003 committee.]

Status of POSIX.2 Balloting

POSIX.2 is in its second round of balloting.  The first ballot, on
Draft 8, produced many objections that are only partially resolved by
Draft 9.  Although there were only fifty-four pages of unresolved
objections remaining after Draft 9 was produced, the current balloting
round is not restricted to existing objections, and there will almost
certainly be many new ones.  Remaining objections range from the
perennial war between David Korn and the UNIX Support Group over what
features should be required in the POSIX shell, through the resolution
of the incompatible versions (Berkeley and USG) of echo, to the
treatment of octal and symbolic modes in umask.

A digression to illustrate the kind of issues being addressed:

     In March of 1989, a study group from 1003.2 met at AT&T to
     resolve major objections to the shell specified in Draft 8 by the
     two warring parties.  This was a good place to hold the meeting,
     since both parties are from AT&T: one led by David Korn of Bell
     Labs, the author of the popular Korn Shell (KSH) the other, a
     group led by Rob Pike of Bell Labs Research and the UNIX Support
     Organization, advocating more traditional shells, like the System

December 1989 Standards Update            IEEE 1003.2: Shell and tools


                                - 3 -

     V Bourne Shell and the Version 9 Research shell.  Korn's group
     contends that the shell should be augmented to make it possible
     to efficiently implement large scripts totally within the shell
     language.  For example, while the more traditional camp views
     shell functions as little more than command-level macros and uses
     multiple scripts to modularize large shell applications, the Korn
     shell views functions as a tool for modularizing applications,
     and provides scoping rules to encourage this practice.

     The two philosophies engender different opinions on issues such
     as the scoping of traps within functions and the use of local
     variables.  Other contentious issues were the reservation of the
     brace ({ }) characters as operators (rather than as the more
     tricky "reserved words"), the promotion of tilde expansion to a
     runtime expansion (like parameter expansion), and the issue of
     escape sequences within echo/print/printf.

     The meeting produced a false truce.  I attended, and believe that
     both parties had different views of the agreement that came out
     of the meeting.  As a result, Draft 9 produced balloting
     objections from both parties and the dispute continues unabated.
     Shades of POSIX.1 Tar Wars...

I suspect the next draft (Draft 10) will fail to achieve the consensus
required for a full-use standard.

This is a good thing.  Useful features are still finding their way
into the document.  (Draft 9 introduces hexdump, locale, localedef,
and more.) Also, the sheer size (almost 800 pages) of Draft 9 has
prevented many balloters from thoroughly reviewing the entire
document, Still, there is a stable core of utilities that is unlikely
to change much more than editorially; I predict the standard will
become final around Draft 12.

A mock ballot on Draft 4 of the UPE will probably start after the New
Orleans meeting in January, and the resulting Draft 5 will probably go
to a real ballot somewhere in summer to early fall of 1990.  Although
many sections remain unwritten or unreviewed, the UPE is a much
smaller standard than POSIX.2 and should achieve consensus more
quickly.

Status of the Brussels Meeting

The Brussels meeting focused on the UPE, with only a summary report on
the status of balloting for the base standard.  For most of the
meeting, small groups reviewed and composed UPE utility descriptions.
The changes generated at the meeting will appear in Draft 3.

The groups reviewed many utilities.  The chapter on modifications to
the shell language (for interactive features) is now filled in, and
such utilities as lint89 (the recently renamed version of lint), more,

December 1989 Standards Update            IEEE 1003.2: Shell and tools


                                - 4 -

etc.  are approaching completion.  Still, much work remains.

[Editor's complaint - We think renaming common commands like lint
("lint89") and cc ("c89") is both cruel and unusual.  We are not eager
to re-write every makefile and shell script that refers to cc or lint,
nor to re-train our fingers to find new keys each time the C compiler
changes.  The name seems to have been coined by either a hunt-and-peck
typist, or someone who has longer and more accurate fingers than we
do.  (Was it, perhaps, the work of Stu Feldman, author of f77?)
Moreover, replacing commands with newer versions is commonplace and
traditional in UNIX.  Examples like "make", "troff", and "awk" spring
to mind.  If an older version is kept on for die-hards, it's renamed
(e.g., otroff, oawk).

One Dot-Two member rebuffed our objections with the reply, "But, you
see, this isn't UNIX: it's POSIX." ]

Because the meeting was in Europe, attendance at the working group
meetings was lower than normal (20-25 rather than the normal 35-40 in
POSIX.2.  Nevertheless, the choice of location served a purpose.  The
meeting was held in Brussels to garner international support and
participation, particularly from the European Economic Community.
There were many EEC representatives at the background sessions on
POSIX and two or three European working group members in the POSIX.2
meetings who wouldn't normally have attended.  Though it remains to be
seen what will come out of having met in Brussels, I am convinced that
the extra effort will prove to have been justified.

December 1989 Standards Update            IEEE 1003.2: Shell and tools


Volume-Number: Volume 18, Number 4

shar.1003.2.29352
echo 1003.4
cat >1003.4 <<'shar.1003.4.29352'
From [e-mail]  Wed Dec  6 15:06:30 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21884; Wed, 6 Dec 89 15:06:30 -0500
Posted-Date: 6 Dec 89 19:44:12 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA25590; Wed, 6 Dec 89 14:06:18 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05692; Wed, 6 Dec 89 13:45:08 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 6 Dec 89 19:44:12 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions Update

John Gertwagen <jag@laidbak> reports on the November 13-17, 1989
meeting in Milpitas, CA:

Background

The P1003.4 Real-time Working Group, began as the /usr/group technical
committee on real-time extensions.  About two years ago, it was
chartered by the IEEE to develop minimum extensions to POSIX to
support real-time applications.  Over time its scope has expanded, and
P1003.4 is now more a set of general interfaces that extend P1003.1
than a specifically real-time standard.  Its current work is intended
to support not only real-time, but also database, transaction
processing, Ada runtime, and networking environments.  The group is
trying to stay consistent with both the rest of POSIX and other common
practice outside the real-time domain.

The work is moving quickly.  Though we have only been working for two
years, we are now on Draft 9 of the proposed standard, and expect to
go out for ballot before the end of the year.  To help keep up this
aggressive schedule.  P1003.4 made only a token appearance at the
official P1003 meeting in Brussels.  The goal of the Milpitas meeting
was to get the draft standard ready for balloting.

Meeting Summary

Most of the interface proposals are now relatively mature, so there
was a lot of i-dotting and t-crossing, and (fortunately) little
substantive change.  The "performance metrics" sections of several
interface chapters still need attention, but there has been little
initiative in the group to address them, so it looks like the issues
will get resolved during balloting.

The biggest piece of substantive work was a failed attempt to make the

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


                                - 2 -

recently introduced threads proposal clean enough to get into the
ballot.  The stumbling block is a controversy over how to deal with
signals.

There are really two, related problems: how to send traditional
UNIX/POSIX signals to a multi-threaded process, and how to
asynchronously interrupt a thread.

Four options have been suggested: delivering signals to a (somehow)
privileged thread, per Draft 8; delivering a signal to whichever
thread is unlucky enough to run next, a la Mach; delivering the signal
to each thread that declares an interest; and ducking the issue by
leaving signal semantics undefined.

We haven't been able to decide among the options yet; the working
group is now split evenly. About half think signal semantics should
follow the principle of least surprise, and be fully extended to
threads.  The other half think each signal should be delivered to a
single thread, and there should be a separate, explicit mechanism to
let threads communicate with one another.

(Personally, I think the full semantics of process signals is extra
baggage in the "lightweight" context of threads.  I favor delivering
signals to a privileged thread -- either the "first" thread or a
designated "agent" -- and providing a separate, lightweight interface
for asynchronously interrupting threads.  On the other hand, I would
be happy to see threads signal one another in a way that looks,
syntactically and semantically, like inter-process signals.  In fact,
I think the early, simpler versions of signal() look a lot like what's
needed (around V6 or so).  I don't care whether the implementation of
"process" and "thread" signals is the same underneath or not.  That
decision should be left to the vendor.)

Directions

Draft 9 of P1003.4 is being readied for ballot as this is being
written and should be distributed by mid-December.  With a little
luck, balloting will be over by the Summer of '90.

Threads is the biggest area of interest in continued work.  The
threads chapter will be an appendix to Draft 9 and the balloting group
will be asked to comment on the threads proposal as if it were being
balloted.  Unless there is a significant write-in effort, the threads
interface will probably be treated as a new work item for P1003.4.
Then, if the outstanding issues can be resolved expediently, threads
could go to ballot as early as April '90.

With the real-time interfaces defined, it looks like the next task of
this group will be to create one or more Real-time Application

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


                                - 3 -

Portability Profiles (RAPPS?) that define how to use the interfaces in
important real-time application models.  Agreeing on the application
models may be harder than agreeing on the interfaces, but we'll see.

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


Volume-Number: Volume 17, Number 92

shar.1003.4.29352
echo 1003.5
cat >1003.5 <<'shar.1003.5.29352'
From [e-mail]  Fri Jan  5 06:20:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23791; Fri, 5 Jan 90 06:20:54 -0500
Posted-Date: 5 Jan 90 02:38:11 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA29877; Thu, 4 Jan 90 21:52:20 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03695; Thu, 4 Jan 90 20:38:45 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada-language Binding
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 5 Jan 90 02:38:11 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada-language Binding Update

Ted Baker <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

The P1003.5 group is producing an Ada-language binding for 1003.1.
The Brussels meeting had two objectives: to reach consensus on a draft
document to be distributed for mock ballot, and to solicit input from
the European community.  We achieved the first but not the second;
only one of the ten attendees was European (Olle Wikstrom, from
Ericsson).

The technical editor (David Emery) and the chapter authors had worked
very hard between meetings to produce version 3.2 of the document, and
Dave brought copies to the meeting.  The working group reviewed it to
try to correct any serious errors or omissions before mock ballot.

There was a lengthy discussion about schedule and logistics for the
mock ballot.  The present plan is to send out copies of the next
draft, in ISO format, to both the ISO and the entire 1003.5 mock-
ballot mailing list.  [Editor's note: All committees are re-formatting
their documents in ISO format to smooth the way for ISO acceptance
(see Dominic Dunlop's report on WG15 for more details), and an IEEE
copy editor appeared on the scene in Brussels to give P1003.5 guidance
and help in this.] Since there is no way that enough input can be
received before the next POSIX meeting, in January, the group has
scheduled a special meeting for mock ballot resolution, between the
January and April POSIX meetings, to be held in Tallahassee.  The
objective will be to produce a proposed standard to be reviewed at the
April meeting.

Most technical issues discussed were minor, compared with previous
meetings.  The most significant, and complicated, was the treatment of
system configuration limits.  Here are three problem areas:

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update       IEEE 1003.5: Ada-language Binding


                                - 2 -

  1.  Tri-state configuration parameters (true, false, undefined) in
      the POSIX C binding need to be treated differently in the Ada
      binding, because Ada prohibits references to undefined symbols.
      (I.e., Ada lacks an "#ifdef" facility.)

  2.  For the same reason, it isn't clear how an Ada binding can
      accommodate future POSIX extensions.  Suppose, for example, a
      future extension adds a new configuration constant.  How does
      one write an Ada program that takes advantage of the new feature
      on implementations where it's available without preventing the
      same program from compiling on older implementations, where it's
      not?

  3.  Because Ada compilers can do optimizations, such as dead code
      elimination, based on static expressions (the nearest analog to
      some C preprocessor capabilities), it is important to provide
      compile-time constants, where safe.  At the same time, to
      support "bubble pack" software that is usable on different
      system configurations, programs should also be able to defer
      binding such values until run time.

The group did achieve consensus on a treatment of configuration limits
for the mock ballot.  It includes a combination of functions, to allow
software to defer resolution of system limits and characteristics
until runtime, and implementation-defined constants and numeric
ranges, to allow optimizers to take advantage of information available
at compile time.  This does not fully solve all the problems mentioned
above.  Perhaps the mock ballot process will turn up some suggestions
for improvements.

The treatment of process arguments and environment variables, which
must be provided as parameters when starting a new process or calling
Exec produced another controversy.

Unlike C, Ada does not allow pointers to stack or statically allocated
objects.  An Ada POSIX interface implemented over a C-language binding
must bridge this gap somehow.  For example, an implementation might
use a C-compatible data structure and hide the non-Ada details, or use
an Ada data structure and translate between the two forms.  Everyone
agreed that the interface should avoid constraining the
implementation, but the first interface solutions appeared to rule out
desirable implementations.  The present solution permits an
application to insure that if the Ada POSIX interface machinery
allocates any "heap" storage this storage is be recovered, while
allowing an implementation to impose restrictions that would permit
stack allocation.  A price paid for this compromise is that writing
portable applications takes more care: an application that works OK
with one implementation may lose storage or exceed size limits with
another.

At the previous two meetings, we had substantial interaction both with

December 1989 Standards Update       IEEE 1003.5: Ada-language Binding


                                - 3 -

other groups working on language-independence and with P1003.4 (real-
time).  There was much less this time, partly because the group was
concentrating so hard on getting ready for mock ballot, partly because
meetings were spread over several buildings, and partly because
P1003.4 mostly skipped Brussels.

On the administrative side, Steve Deller was promoted from Vice
Chairman to Chairman (in charge of external affairs and running
meetings) and Jim Lonjers was chosen as Vice Chairman (in charge of
administering ballot resolution).  This change was required because
the ex-Chairman (Maj. Terry Fong) has been unable to participate
regularly in the working group recently, owing to conflicts with his
professional duties.

Another issue that came up was whether working group members are at
liberty to publish papers or present talks on the 1003.5 work.  The
answer is, "Yes." Until now, some members have been exercising self-
censorship, based on an earlier agreement designed to discourage
anyone (e.g., defense department personnel) from making commitments
(e.g., requiring use of the POSIX Ada binding in contracts) based on
erroneous (e.g., overly optimistic) progress reports.  It did not take
much discussion to agree that such censorship is now
counterproductive, and may never have been wise.  At this point,
P1003.5 certainly wants public exposure of its draft document, and
hopes that such exposure will generate more reviewers and active
working group members.

December 1989 Standards Update       IEEE 1003.5: Ada-language Binding


Volume-Number: Volume 18, Number 2

shar.1003.5.29352
echo 1003.6
cat >1003.6 <<'shar.1003.6.29352'
From [e-mail]  Fri Dec  8 13:34:30 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24920; Fri, 8 Dec 89 13:34:30 -0500
Posted-Date: 8 Dec 89 18:24:15 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA10976; Fri, 8 Dec 89 12:27:18 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02488; Fri, 8 Dec 89 12:24:59 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 8 Dec 89 18:24:15 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare <[e-mail]> reports on the October
16-20, 1989 meeting in Brussels, Belgium:

The security working group worked the full week, discussing the draft.
The meeting's primary goal was to approve the current draft for
distribution to the international working groups. It was presented, at
the EEC, to new members of the group from the European countries, and
every member introduced himself/herself the first day of the meeting.
Once introductions were out of the way, we dealt with the major topics
that follow.

TRUSIX

A representative from TRUSIX, Charles Testa, gave the usual progress
report on TRUSIX.  [Editor's note -- TRUSIX is an organization
sponsored by the National computer security center (NCSC), developing
a secure UNIX model.  The participants are a number of vendors
developing secure UNIX implementations.] Their modeling subcommittee
has nearly completed a formal model describing the UNIX file system.
They have accepted the "Ina Jo" model to describe Trusted UNIX System
Interfaces.  This model revolves around a MAC-read criterion, MAC-
writes and a DAC constraint, and consists of simple security
properties, confinement properties, and discretionary security
properties representative of the Bell-LaPadula model.

The TRUSIX ACL Rationale and Working Example Document has been
approved by the NCSC and is being reviewed for publication under NCSC
security publications.

One topic of interest to all security readers is prevention and/or
detection of covert channels.  TRUSIX is planning to include this
under the Audit Rationale Document, which will include examples of
typical covert channels and their implications.  Issues such as

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 2 -

bandwidth evaluation will be addressed by a separate white paper.

POSIX Conformance Testing

A representative from 1003.3,the POSIX Conformance Testing group,
presented 1003.3's goal -- to establish a series of specifications for
testing the different POSIX standards. Although they have written the
pseudo-code to test the conformance of a system to 1003.1, they feel
they lack the staff and expertise to produce such tests for all the
1003 groups.  Given this, their current plan is to draw upon each
group for expertise and background knowledge of the subject at hand,
and join those skills with their testing skills to produce a test bed
for each 1003 standard.

Their ultimate goal is to allow testing of all elements of an open
system for POSIX conformance by defining common test methods, which
can then be implemented by private industries as test suites. They
explained how to list the assertions, how to classify them, and what
information they will need to produce a test method for 1003.6.

One factor mentioned was that the description has to address a single
unit of behavior expected of a conformant system at a time. This
implies dissecting interfaces into separate groups of assertions and
generating assertions for both semantic and syntactic descriptions.

Discretionary Access Control (DAC)

The group focused on polishing and adding information to the draft.
It was suggested the standard shouldn't define the behavior of 'chmod'
when old programs are being executed with the DAC mechanism.

It was noted that the current proposed Access Control List (ACL) might
not be fully compatible with the current behavior of a 'chmod' call.
With the current, old-style behavior, when 'chmod' is used to change
owner, group and/or other permissions, the changed permissions
represent the access modes of the file.  In the current proposal for
ACL, a 'chmod' will provide the old behavior for the "owner" and
"other" fields, but the "group" field permissions as set by 'chmod'
and shown by 'stat', wouldn't represent the actual access permissions
of the group associated with that file; instead, it's a summary of all
access permissions included under the ACL list for group entries.  In
other words, it would represent the maximum permissions allowed to the
group entries included in the ACL list.

Some participants argued that 'chmod' should be replaced by other
system calls in a system conforming to 1003.6.  In other words, if
your system were to conform to 1003.6 the behavior of chmod would be

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 3 -

unspecified and unpredictable.

I disagree.  Although defining the behavior of 'chmod' might restrict
some implementations of ACLs, having a well-defined chmod behavior
will provide backward compatibility and ease porting old programs to
1003.6-conformant systems.  Otherwise old programs will have to be
ported to platforms with system-dependent representations of 'chmod'
and 'stat' information.

It was also proposed that the ACL list should allow entry types like
timestamping.  This would allow a policy that is more restrictive than
the DOD, orange-book policy to provide more granularity of file
access.

Mandatory Access Control (MAC)

Kevin Murphy, of British Telecom, presented his views on electronic-
mail-label usage and proposed that such a mechanism should be used as
part of the standard.  The electronic mail security labels consist of
a generic format that includes four major components: security policy
id, security classification, privacy mask, and security categories.
This approach to labels is implemented on X.400 security services.
One clear advantage of using such a format for labels is that it
maximizes the potential synergy between operating-system and
electronic-mail labels.

Chris Hughes from ICL presented British views on MAC information
labels.  Its main characteristics are these: object creation
initializes the label, the label is implementation-defined and changed
by the owner, and the label is not used for access control.  Chris
proposed that the standard should provide a get/set mechanism for the
object information label, and a way to merge and translate information
labels, but should not standardize the labels' contents.

Information labels are useful because they provide added information
on particular objects.  We concluded that information labels should be
in the scope of MAC as part of the standard, and requested that MITRE
provide a presentation on information label use at the next meeting.

Privileges

The whole group heard a presentation of the internal draft of the
privileges document.  We decided that the wording had problems.  The
draft interface description is too obscure and needs a simpler
description of privilege interfaces, before it can be included in the
1003.6 draft document.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 4 -

Although the group argued considerably about the wording, they seemed
to agree on the concepts.  The main points are that privilege is
associated with a process and privilege attributes can be attached to
files.

I do not think I should burden the reader with the brainstorming ideas
of the privilege group until a firmer position is taken at the next
meeting.  One thing I can say is that the process-privilege concepts
described in my last report (permitted, inheritable and effective),
still stand, and a file still has three types of privilege attributes.

Audit

Kevin Brady from AT&T and Doug Steves from IBM presented a combined
proposal, produced by them and Henry Hall from DEC, on how to define
audit interfaces for 1003.6.  Their proposal was meant to contest the
current audit stand, lead by Olin Sibert from Oxford Systems.

The current audit definition is based on the token concept and on a
pure procedural interface.  In the procedural interface all data
manipulation of the audit record is performed by function calls, with
data passed explicitly through function parameters.  Although this
sounds attractive and clear, in practice it requires many function
calls.

Another major point of controversy was the audit trail format.  In
Olin's proposal, conversion cost is minimal because writes and reads
require an explicit specification of the format wanted.  In Kevin,
Doug and Henry's proposal the conversion function is set to one of
three conventional formats: little endian, big endian, or XDR.  In
other words, the information is stored in machine-dependent format
while Olin's chooses a uniform format for all information stored.

One last contested feature was the ability to rewind audit trail
information when viewing it.  Kevin, Doug and Henry's proposal does
not allow a rewind, since information is manipulated at the data-
structure level.

Because of the heated discussion of procedural versus data-structure
interfaces for POSIX, both proposals will be formally written out,
removed from the draft, and presented in the next meeting for a final
vote.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


Volume-Number: Volume 17, Number 94

shar.1003.6.29352
echo 1003.7
cat >1003.7 <<'shar.1003.7.29352'
From [e-mail]  Sat Jan  6 14:06:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11138; Sat, 6 Jan 90 14:06:33 -0500
Posted-Date: 6 Jan 90 15:14:45 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17001; Sat, 6 Jan 90 13:06:28 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01029; Sat, 6 Jan 90 09:15:26 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 6 Jan 90 15:14:45 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration Update

Steven J. McDowall <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

Background

Joe Friday would say, "Just the facts, ma'am." And that's the way I
feel.  The facts are that I'm sick, it's Thanksgiving, I am going to
London for two weeks tomorrow, and 1003.7 is defining a standard way
to administer POSIX systems.

Now, almost everyone agrees that 1003.7 should deal with networks, not
just isolated systems.  To wit, it would be nice if I could administer
all the machines in a network from a single machine with simple
commands.  For example, to add a user to all machines in the domain
"mn.org", all I should need to do is issue a command like "adduser -d
mn.org -options -parameters username". The question is, without any de
facto standard already in place to adopt, how can we achieve this?

The Approach

This is important, so pay attention.  Because the major goal of 1003.7
is to create a standard way to manage a set of objects, the group has
decided to take an object-oriented approach.  Our idea is to begin by
creating a list of objects to manage, then to follow that by defining
the set of commands to manage each object.  This approach is novel for
both system administration and POSIX.  It will probably require more
work on the front end to define the objects, their attributes, and
their relationships, than to define the actual command structure to
support and manipulate them.  Whether this approach will work remains
to be seen.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update      IEEE 1003.7: System Administration


                                - 2 -

The Meeting

The meeting was boring.  To put it bluntly, the week was simply a work
week.  Objects (and sub-objects) were defined and discussed in detail,
then put in the draft.  Little got done on the first and last days,
due to EEC formalities, which left us with three working days instead
of the normal four and a half. Attendance was pretty dramatically
reduced, too.  About half the normal North Americans showed up,
probably because of the location, and only one (yes one...) new
European came even though we were meeting in Europe.  Oh well, except
for my having had my passport stolen, it was a good chance to see
Belgium.

Concerns

  1.  The process is taking a long time to move ahead, both because of
      the difficulty involved and because we seem to attract less
      manpower than many other groups.  Moreover, since we're taking a
      radical approach, it takes extra time to teach the ideas to
      anyone new that does come.

  2.  System administration doesn't have the glamour of some of the
      other areas being standardized.  As the Rodney Dangerfield of
      POSIX, 1003.7 gets no respect.

  3.  The notation we're using to define our objects is ASN.1.  "Why
      ASN.1?" you ask.  Simply because it's a standardized meta-
      language to describe abstract data types.  The feeling was that
      this would help make the whole package more suitable for
      interoperability.  I bring this up because there's some movement
      throughout 1003 to re-do all data structures in a new meta-
      language created by some of the people working on language-
      independence.  Not only would this require that we go back and
      re-do our definitions, but I also think ISO will only allow the
      use of standardized data-languages in their standards.  Does
      anyone out there know if there is such an ISO restriction?  If
      so, it's important for 1003 as a whole, not just for dot seven.

  4.  Currently, almost all working-committee members are from
      vendors.  IBM, DEC, HP, AT&T, and others are well-represented.
      A few interested parties, like OSF and /sys/admin.  are there as
      well, but as far as I can tell, there isn't one real user.  By
      "real user" I mean someone who does nothing but administer a
      system.  All of us are connected somehow with creating an
      administrable system or getting paid to do so.  Of course, I
      should make clear that we all have to administer systems of our
      own, so we're not simply an ivory tower group with no real

December 1989 Standards Update      IEEE 1003.7: System Administration


                                - 3 -

      experience, but representation is still grossly unbalanced.

  5.  Finally, there's been a loss of focus on interoperability
      directly attributable to the loss of our X/OPEN representative,
      Jim Oldroyd.  Jim was well respected and made many valuable
      contributions, but can no longer attend our meetings.  As the
      X/OPEN representative, he was very concerned with multi-vendor
      environments, and was a major force in helping us focus on and
      ensure interoperability.  I am not saying that no one else on
      the committee cares about the issue, but it does seem to be
      being pushed aside in a spirit of, "I think we shouldn't have
      any interoperability problems if we do this, so let's do it and
      worry about it later on." Jim had helped provide a more
      positive, direct approach of determining up front what would be
      needed for true interoperability. If X/OPEN is still interested
      in System Administration, and in making sure the 1003.7 standard
      includes provisions for interoperability, we could still use
      their help.

December 1989 Standards Update      IEEE 1003.7: System Administration


Volume-Number: Volume 18, Number 5

shar.1003.7.29352
echo 1003.8.2
cat >1003.8.2 <<'shar.1003.8.2.29352'
From [e-mail]  Mon Dec 18 02:25:54 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13274; Mon, 18 Dec 89 02:25:54 -0500
Posted-Date: 18 Dec 89 05:24:57 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA29347; Mon, 18 Dec 89 01:25:43 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01566; Sun, 17 Dec 89 23:25:40 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/2: Networking (IPC)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 18 Dec 89 05:24:57 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.8/2: Networking (IPC) Update

Steve Head <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

OVERVIEW

P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX.  The committee is
currently divided into six subcommittees: transparent file access,
network IPC, remote procedure call, OSI/MAP services, X.400 mail
gateway, and directory services.

This report is a summary of the activity in the network IPC
subcommittee, which is currently working on two potential interfaces,
a "detailed" interface (DNI) and a "simple" interface (SNI).  DNI is
roughly (though not exclusively) at the transport level.  SNI is
intended to be somewhat simpler to use than DNI, but at roughly the
same level.

At this meeting, presentations of DNI and SNI were made at the EC
(European Community) headquarters in Brussels.  Discussions on DNI
(definitions) and SNI (routines) continued.  The main topics of
discussion were:

  1.  DNI, SNI presentation to EC

  2.  DNI definitions

  3.  SNI routines

  4.  Schedule

  5.  Security

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


                                - 2 -

  6.  P1003.8/2 -> full POSIX committee

DETAIL

  1.  DNI, SNI presentation to EC

      Keith Sklower and Steve Head gave presentations on DNI and SNI
      respectively to POSIX attendees at CEC (Commission of the
      European Community) headquarters.  This meeting was scheduled in
      Brussels primarily to obtain European input.  The presentations
      went well, and attendees included X/Open and EC representatives.

      No significant differences of opinion or direction were noted
      between the committee and other attendees.  This indicates some
      degree of success (?).  (Other networking groups, such as
      directory services, were not so fortunate.)

      This meeting "broke the ice" with international organizations in
      the area of networking, and we now expect increased interaction
      with those organizations.

  2.  DNI definitions

      The committee discussed DNI definitions.  Steve Head presented a
      paper on the subject.  Suggestions made at the meeting will be
      incorporated into a future version of the paper, which will be
      circulated via electronic mail.  If no further significant
      issues are raised, it will be incorporated into the next DNI
      draft.

  3.  SNI routines

      The committee discussed SNI routines, based on a paper from
      Keith Sklower.  No conclusions were reached, however, this
      particular discussion was very useful since it brought a number
      of goals and requirements for SNI into clear focus.

      SNI is adopting some characteristics of ISODE (the ISO
      Development Environment).  This is probably beneficial since it
      means that SNI will be partially based on a working
      implementation instead of being entirely new.  As such, it may
      gain importance as a migration strategy for transferring
      applications from TCP/IP to ISO.  (ISODE stands for the ISO
      Development Environment, a collection of networking software
      available through public channels that runs over either TCP/IP
      or ISO transport and allows higher level applications to be

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


                                - 3 -

      oblivious to the type of transport a given system provides.)

  4.  Schedule

      The working schedule has been delayed by the need to make
      presentations at Brussels, instead of doing "real work".
      Originally, we had scheduled the topics of connection setup,
      connection tear-down, and name resolution for this meeting.
      These topics were not discussed, and our schedule has been
      shifted back a quarter to reflect this.  These topics will be
      discussed at the next meeting.  (See FUTURE MEETING TOPICS
      below.)

  5.  Security

      We held another joint meeting with the POSIX security group,
      P1003.6.  An electronic mailing list was created for the topic
      of network security.  For more info or to be put on the list,
      please contact Mike Ressler ([e-mail] or bellcore!mpr).
      A list of topics on networking security to begin discussions on
      was initiated.

  6.  P1003.8/2 -> full POSIX committee

      The decision to make P1003.8/2 a full POSIX committee was
      postponed by the POSIX executive committee (SEC).  This subject
      will be re-addressed at the next POSIX meeting in January.

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


                                - 4 -

FUTURE MEETING TOPICS (TENTATIVE)

       DATE             ACTIVITY
    --------------------------------------------------------------------
    Winter 1990 mtg     SNI/DNI connection setup/tear-down
    Spring 1990 mtg     SNI/DNI data transfer
    Summer 1990 mtg     SNI/DNI event management
    Fall   1990 mtg     SNI/DNI POSIX 1003.1 extensions
    Winter 1991 mtg     SNI/DNI protocol-independent options
    Spring 1991 mtg     SNI/DNI miscellaneous functionality
                        DNI protocol-dependent (ISO, ARPA, etc.) options
    Summer 1991 mtg     SNI/DNI definitions
    Fall   1991 mtg     SNI/DNI review drafts
    Winter 1992 mtg     SNI/DNI approve drafts for mock ballot
    Jan.   1992         SNI/DNI mock ballot
    Spring 1992 mtg     SNI/DNI resolve mock ballot objections
    Summer 1992 mtg     SNI/DNI review drafts
    Fall   1992 mtg     SNI/DNI approve drafts for full use ballot
    Nov.   1992         SNI/DNI full use ballot
    Winter 1993 mtg     SNI/DNI resolve full ballot objections
    Spring 1993 mtg     SNI/DNI resolve full ballot objections
    May    1993         SNI/DNI submit approved drafts to IEEE stds. board
    Summer 1993         data representation network interface goals ...

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


Volume-Number: Volume 17, Number 108

shar.1003.8.2.29352
echo 1201
cat >1201 <<'shar.1201.29352'
From [e-mail]  Sat Dec  2 15:57:51 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18722; Sat, 2 Dec 89 15:57:51 -0500
Posted-Date: 2 Dec 89 19:26:24 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06188; Sat, 2 Dec 89 14:57:44 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00613; Sat, 2 Dec 89 13:27:11 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:26:24 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>



            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1201: User Interface Update

Eileen Coons <[e-mail]> reports on the October 16-19, 1989
meeting in Brussels, Belgium:

     "The time has come," the walrus said,
       "To talk of many things:
     Of shoes -- and ships -- and sealing wax --
       Of cabbages -- and kings --
     And why the sea is boiling hot --
       And whether pigs have wings."
               -- Lewis Carroll

The P1201 committee is on a divine mission to define standards for
user interface technologies.  Lewis Carroll would have loved P1201
meetings.

In keeping with the precedent set by previous P1201 meetings, this
latest get-together was spirited.  The quasi-good news is that, by the
end of the session, not one, but 3 PAR's had been defined, as the
group split into 1201.1 (Application Programming Interface), 1201.2
(Drivability - Look & Feel), and 1201.3 (User Interface Definition
Language). One participant aptly named the proceedings "PAR Wars".

There was agonized discussion over the various sub-group's missions,
and an equal amount of agonized, and at times agonizing, wordsmithing
over the .1 and .2 PAR's themselves.  The .3 group thoughtfully
elected to split off and define itself in private.  The PAR's will be
submitted via proper official channels to be blessed at the January
SEC meeting.

For anyone not familiar with the PAR process, PAR is an acronym for
Project Authorization Request.  An individual or group that believes
some work should be done by an IEEE committee drafts a document
describing the work, which is then submitted to the IEEE as a PAR.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update               IEEE 1201: User Interface


                                - 2 -

Usually the PAR is circulated to the IEEE membership in one of its
mailings.

The SEC (Steering Executive Committee) reviews the PAR during its next
scheduled session, typically held during a POSIX meeting.  The SEC
votes on the PAR, and if the PAR is approved by the SEC, it is
presented to TCOS (Technical Committee on Operating Systems).  TCOS
decides in which committee the work will be done.  In the case of the
PAR for User Interface, TCOS elected to divorce the work from the core
POSIX effort (1003), and created P1201.

The PAR becomes part of the statement of work and basic charter for
the group doing the work.

Fortunately, at this meeting the group finally created some real
structure for itself.  Ninety minutes into the meeting, the group
decided to define an agenda!  It also resolved that all meeting
attendees should receive minutes of the meeting, e-mail snafus
notwithstanding.  Jim Isaak, the chair of the 1003 SEC, helped with
structural definition by supplying IEEE rules and charter information,
explaining the balloting process, and listing action options open to
the committee.

Seven ballot alternatives were proposed, ranging from submitting a
proposal for immediate ballot, to disbanding 1201, packing our tents,
and going home.  A vote was called, and although there was no
consensus (hardly a surprise), the heavy favorite was a proposal to
adopt Motif's API as the basis for a standard API specification, and
to extend it to accommodate aspects of Open Look's look & feel.

This general direction was unpopular with a vocal minority, however,
so the group took a break then reconvened, discarded the vote and
returned to its original, pre-poll path of action: defining a
specification for an API based on neither Motif nor Open Look, but on
some new API -- probably a hybrid of the two.

[Editor's note: I've heard more than one person express ill-ease about
the restricted range of choices being considered.  Why is there no
mention of NeXT/Step, for example?  A noticeable feeling among people
who aren't on the committee is that it's too early to try to
standardize in this area, and that the answer to the question, "Motif
or Open Look?" should be, "No thanks."

The answer to the implied question, "Why is there a P1201 and why are
we doing this now, anyway?" seems to be is that NIST, the National
Institute for Standards and Technology (the people who bring you
FIPS), is pushing hard for rapid creation of a GUI standard.]

Two presentations were made: one by AT&T, in favor of the joint API
concept, and one by OSF, arguing against its feasibility. In an
unusual and unfortunate departure from Robert's Rules of Order, this

December 1989 Standards Update               IEEE 1201: User Interface


                                - 3 -

was followed by a critique of -- some thought, attack on -- the second
presentation by one of the acting chairs, Clive Feather of X/OPEN.
P1201 may be many things but, so far, staid isn't one of them...

On a more neutral note, several representatives from organizations
working on UIDL technologies made presentations about what they were
doing in that arena, and then went off to form P1201.3.  God bless
them.

The rest of the group broke into the .1 and .2 sub-groups for working
sessions during most of the remaining meeting time.  Each group
reviewed its newly drafted PAR.  P1201.1 also spent time comparing
Motif and Open Look, identifying and exploring the differences between
the two API's, and looking for potential drivability issues that could
be deferred to P1003.2.  P1003.2 took a similar course of action,
comparing the looks and feels of the two technologies.

It's rumored that the .1 group will be meeting Dec. 4 - 5 in
Cambridge, MA to pursue their quest for a merged API.  Interested
parties should contact Betty Dall, AT&T, for more details.  (E-mail
[e-mail], or phone Betty at 201-522-6386.)

There was also a spirited discussion regarding when and where the next
P1201 meetings should be held.  After various alternatives were
explored, and only two (or was it three...?) votes, the group decided
to keep P1201 meetings in the same vicinity and timeframe as POSIX
meetings, since many attendees need, or want, to participate in POSIX
as well.

All in all, it wasn't too bad.  The weather in Brussels was nice, the
Belgian beer was pretty good, and the meeting was, um...,
entertaining.

December 1989 Standards Update               IEEE 1201: User Interface


Volume-Number: Volume 17, Number 83

shar.1201.29352
exit