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

Text File | 1990-05-09 | 100.4 KB | 2,546 lines

echo intro
cat >intro <<'shar.intro.321'
From jsq  Fri Nov  3 17:37:41 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA28287; Fri, 3 Nov 89 17:37:41 -0500
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update on IEEE 1003 July San Jose meeting
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: John S. Quarterman <[e-mail]>
Date: 20 Oct 89 20:52:07 GMT
Apparently-To: std-unix-archive

From: John S. Quarterman <[e-mail]>

This is the first posting in the set of articles about the July 1989
IEEE 1003.1 meeting in San Jose, California (not about the Brussels
meeting going on this week).  My apologies for not having posted them
when they arrived a couple of weeks ago.  Work and earthquakes and such
shouldn't be an excuse.

Here is a list of 1003 subcommittees:

    1003.0    POSIX Guide
*    1003.1    Systems Interface
*    1003.2    Shell and Tools Interface
    1003.3    Verification and Testing
    1003.4    Real Time
    1003.5    Ada Binding for POSIX
    1003.6    Security
    1003.7    System Administration
    1003.8    Distributed Services
*    1003.9    Fortran Bindings
*    1003.10    Supercomputing
    1003.11    Transaction Processing
*    1201    Interfaces for User Portability

* No report.

We really need somebody to snitch on 1003.2, the shell and tools group,
since it's the next one that's likely to produce a final standard.
Perhaps someone who goes to that committee's meetings could volunteer?

As the report editor, Jeffrey S. Haemer, says:
    This is more reports than we posted last time, but I still don't
    have a full set.  One of my goals for Brussels is to establish a
    working snitch for each group.

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

Volume-Number: Volume 17, Number 37

shar.intro.321
echo 1003.0
cat >1003.0 <<'shar.1003.0.321'
From jsq  Fri Nov  3 17:48:04 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00153; Fri, 3 Nov 89 17:48:04 -0500
From: Jeffrey S. Haemer <[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: 20 Oct 89 21:49:37 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide Update

Kevin Lewis <[e-mail]> reports on the July 10-14,
1989 meeting in San Jose, California:

As 1003.0 passes the mid-point of calendar year 1989, progress can be
earmarked by the arrival of line numbers to the guide document.  I
remember the first time I saw line numbers on a document within the
IEEE 1003 arena.  My first thought was "this committee is really doing
precise, exacting work".  Thus was my reaction again when I saw line
numbers on our document.  My balloon was burst, when one of our active
members -- and by "active member" I mean someone who commits
contributions in writing, not just someone who comes to voice an
opinion in a talk-show-like atmosphere -- pointed to our ISSUE LOG,
which states that the committee needs to do more work.  (There's that
word again.) Alas, I came back down to earth.  I have "miles to go
before I sleep."

Dot Zero continues to converge.  Our document is finally beginning to
tie together the standards and elements that comprise a POSIX open
system.  Key events continue to be the definition of terms that will
eventually make it to the IEEE Glossary and the identification of
areas where terms still need definition.

The group is still generating discussion/debate/argument/food-fights
over behemoth macro-questions such as, "What is the role of the
guide?" and, "What is the PROPER audience?" In addition, the group has
made valiant attempts at addressing specific areas such as graphics
and data interchange without the benefit of focused expertise. We now
agree on our ignorance in these areas, and will seek help and/or to
point to other committees that, we believe, can come up with the
answers.

Overall, we must meet our objective of going to ballot in October
1990, because that is what I told my wife, who is still trying to
figure out what in the world a "dot zero" might be.

__________

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

September 1989 Standards Update               IEEE 1003.0: POSIX Guide

Volume-Number: Volume 17, Number 38

shar.1003.0.321
echo 1003.3
cat >1003.3 <<'shar.1003.3.321'
From jsq  Sun Nov  5 12:17:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA08553; Sun, 5 Nov 89 12:17:11 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 22:02:11 GMT
Apparently-To: std-unix-archive

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

[ This is a reposting because the original doesn't even appear on uunet.  -mod ]




            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods Update

Doris Lebovits <[e-mail]> reports on the July 10-14,
1989 meeting in San Jose, California:

  1.  Overview
      This was the thirteenth meeting of P1003.  Monday through
      Wednesday, the group began work on a verification standard
      corresponding to 1003.2 (Shell and Tools).  Following the close
      of the formal meeting, the technical reviewers of the draft 10
      ballot met for the remainder of the week.

  2.  Meeting Summary
      This was the first meeting to develop the verification standard
      for P1003.2, which will contain test methods and test assertions
      for measuring 1003.2 conformance.  This standard will ultimately
      form part III of P1003.3.  (Part I contains definitions, generic
      test methods, and so forth; part II is test methods for
      measuring P1003.1 conformance, including test assertions.  As
      other P1003 standards reach maturity, their verification will,
      in turn, be covered in new parts of the P1003.3 standard.)

      The chair's aggressive goal is to be ready to bring part III to
      ballot after four quarterly meetings.  A detailed schedule and
      milestones will be developed at the next meeting.

      Attendees included representatives of AT&T, NIST, OSF,
      Mindcraft, IBM, DEC, HP, Data General, Cray Research, Unisys,
      Perennial and Unisoft Ltd.  The meeting agenda included:

         o+ the confirmation of new officers for the the part III work

              o+ Chair: Roger Martin

              o+ Vice-chair: Ray Wilkes

__________

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

September 1989 Standards Update              IEEE 1003.3: Test Methods


                                - 2 -

              o+ Technical Editor: Andrew Twigger

              o+ Secretary: Lowell Johnson

         o+ the rough scheduling and setting of general milestones for
           part III

         o+ a meeting with the P1003.2 working group to discuss testing
           issues

         o+ action item assignments

         o+ identification of items for the next meeting

      In addition, small groups formed to discuss and resolve three
      specific issues.  One group investigated the difficulty of
      thorough testing of the more complex utilities: awk, bc, ed,
      lex, make, pax, sh, and yacc.  (The resulting action item was to
      produce a prototype set of assertions.)  A second group scoped
      the writing of assertions for BNF type structures: "[]"
      expressions, regular expressions, and extended regular
      expressions.  The third reviewed "Verification of Commands
      Interface", a paper by Andrew Twigger of Unisoft Ltd.  The paper
      covers:

         o+ character set and locale

         o+ internationalized utilities

         o+ underlying OS primitives

         o+ regular expression testing

         o+ pattern matching notation

         o+ utility syntax rules

         o+ errors from P1003.1 associated functions

         o+ environment variables

         o+ standard output format

         o+ standard error format

         o+ environmental changes

         o+ symbolic limits

September 1989 Standards Update              IEEE 1003.3: Test Methods


                                - 3 -

         o+ obsolescent features

         o+ job control

         o+ read-only variables

         o+ signal numbers

      NIST has contributed its current 1003.2 test assertions to
      provide a basis for the 1003.2 verification work.  Sheila
      Frankel of NIST gave a short presentation on the current state
      of the these assertions, which include approximately 900
      Mindcraft test assertions, plus 2600 newly-created assertions,
      all based on P1003.2 Draft 8.

  3.  Technical Reviewer's Meeting
      In parallel to the verification work for P1003.2, balloting and
      revision is taking place on draft 10 of parts I and II.

      As of July 6, 1989, 77 responses had been received from the 125
      members in the balloting group. Eighteen additional responses
      will bring this to the 75% response needed to officially close
      the ballot.
      The tally of the 77 responses:
           28      positive        (36%)
           31      negative        (40%)
           18      abstain         (24%)

      The technical reviewers held a plenary session to evaluate and
      respond to the comments and objections to this draft.  Group
      consensus decided each issue and each decision was final.  Part
      I was reviewed completely but only a few chapters of part II
      were reviewed.  The remaining part II work was assigned to
      volunteers.

      Draft 11 is planned for ballot recirculations in October, 1989,
      and an approved standard for parts I and II is anticipated by
      the first quarter of 1990.

September 1989 Standards Update              IEEE 1003.3: Test Methods


Volume-Number: Volume 17, Number 39

shar.1003.3.321
echo 1003.4
cat >1003.4 <<'shar.1003.4.321'
From jsq  Sun Nov  5 12:33:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09101; Sun, 5 Nov 89 12:33:24 -0500
From: Jeffrey S. Haemer <[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: 20 Oct 89 22:05:45 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions Update

John Gertwagen <jag@laidbak> reports on the July 10-14, 1989 meeting
in San Jose, California:

The P1003.4 meeting in San Jose was very busy.  The meeting focused on
resolving mock-ballot objections and comments. Despite limited
resources for documenting changes, a lot of work got done.  Here's
what stood out.

Shared memory
     The preferred interface falls somewhere between shared-memory-
     only and a mapped-files interface, such as AIX's mmap(), which
     allows files to be treated like in-core arrays.  Group direction
     was to reduce the functionality to support only shared memory, so
     long as the resulting interfaces could be implemented as a
     library over mmap().

Process memory locking
     The various region locks were clarified and, thus, simplified;
     the old definitions were fuzzy and non-portable.  For those who
     haven't seen it, there is actually a memory residency interface
     (i.e., fetch and store operations to meet some metric) instead of
     a locking interface.  Most vendors will probably implement it as
     a lock, but some may want it to impose highest memory priority in
     the paging system.

Inter-process communication
     Members questioned whether the interface definitions could really
     support a broader range of requirements; they're like no others
     in the world today.  Having been designed to meet the real-time
     group's wish list, there are lots of bells and whistles -- far
     more than in System V IPC -- but it's not clear, for example,
     that they are network extensible.  Discussions in these areas
     continue.

__________

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

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions


                                - 2 -

Events and semaphores
     Members were concerned about possible overlap with other
     mechanisms, especially those being considered for threads. The
     question is basically, "Should there be separate functions for
     different flavors or a single function with multiple options?"
     General sentiment (including our snitch's) seems to be for
     multiple functions; however an implementation might choose to
     make them library interfaces to a common, more general system
     call.  There is, however, a significant minority opinion the
     other way.

Scheduling
     Many balloters found process lists and related semantics
     confusing.  An attempt was made to re-cast the wording to be more
     strictly in terms of process behavior.

Timers
     Inheritance was brought in line with existing (BSD) practice.

Outside of the mock ballot, there were two other major news items.

First, there is a movement afoot to make the .4 interfaces part of
1003.1.  They would become additional chapters and might be voted
separately or in logical groups.  This would bring P1003 in line with
the ISO model of a base standard plus application profiles. POSIX.4
would become the real-time profile group.  This is a non-trivial
change.

Up to now, the criterion for .4 has been that of "minimum necessary
for real-time", and has coincidentally been extended to support other
requirements "where convenient".  This is not a good starting point
for a base interface.  For example, mmap(), or something very much
like it, is probably the right base for "shared storage objects", but
real-time users want an interface for shared memory, not for mapped
files.  Our snitch worries that things might look a bit different had
the group been working on a base standard from the beginning.

Second, the committee officially began work on a threads interface,
forming a threads small group and creating a stub chapter in the .4
draft.  A working proposal for the interface, representing the
consensus direction of the working group, will be an appendix to the
next draft.

A lot of work remains to be done before .4 can go to ballot and the
current January '90 target may not be realistic.  If the proposed re-
organization occurs, a ballot before the summer of 1990 seems unlikely.

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 17, Number 40

shar.1003.4.321
echo 1003.5
cat >1003.5 <<'shar.1003.5.321'
From jsq  Sun Nov  5 12:42:52 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09731; Sun, 5 Nov 89 12:42:52 -0500
From: Jeffrey S. Haemer <[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: 20 Oct 89 23:08:44 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada-language Binding Update

Ted Baker <[e-mail]> reports on the July 10-14, 1989
meeting in San Jose, California:

The Ada-language binding for 1003.1 is progressing steadily, though
behind schedule.  The group agreed to try to prepare a document for
the October meeting in Brussels that is ready for mock ballot.  Those
at the meeting will decide whether the document has achieved this
goal.  If not, we will try again at the January meeting in New Orleans.

The slow progress is mainly due to the long time between meetings and
the limited workforce available to do the writing. The members, all
volunteers, must steal time for POSIX from their "real" (i.e.  paying)
jobs.  Attending quarterly meetings already puts most members near the
limit of time they can spare.

Most significant technical issues seem to be resolved; the remaining
controversies center on almost-religious issues, such as the exact
grouping of interface declarations into Ada packages, naming,
capitalization conventions, and where to strike the balance between
providing full functionality and idiot-proofing the interface.

Each chapter has been assigned to a person for review and editing,
based on decisions made at the San Jose meeting.  Quite a lot of
writing still needs to be done.  Chapter 7 ("Device- and Class-
Specific Functions" --i.e. terminal interfaces) is still empty, and
some others are still mostly just Ada code, with no discussion.  Most
of the rationale remains to be written.  Mitch Gart has agreed to
coordinate this, including a chapter on "meta-issues" -- design
decisions affecting the entire interface.  David Emery will combine
the chapters to produce the next draft.

Interaction with 1003.4 (Real-Time Extensions) has heated up, with
1003.4's consideration of support for multi-threaded processes.  Ada
language implementations must support multiple tasks (i.e. threads)

__________

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

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 2 -

within a POSIX process, to comply with the Ada language standard.
Neither the 1003.1 standard nor the 1003.4 draft that just completed
mock balloting supports multithreaded processes, so the Ada
implementor is currently forced to hack out some sort of internal
concurrency scheme, with its own layer of dispatching, for each Ada
process.  This tends to run aground when one Ada task makes a blocking
system call, since the whole process is forced to wait.  Naturally,
Ada implementors and users would be pleased if the POSIX interface
provided for concurrency within a process.

The Ada group is very interested in the threads proposal, and most
members would like to see some support for threads in the 1003.4
standard that goes to formal ballot.  Some members are a little bit
concerned that those working on the proposal may not understand Ada
tasking well enough to insure that the proposed threads will be
adequate to implement Ada tasking semantics.  This has been very
frustrating for members of the Ada group, since the discussions of the
threads proposal were all in parallel with meetings of 1003.5.  The
best the Ada group was able to do was to keep one observer present (on
rotation) at the review of the threads proposal.  It is not clear
whether this was adequate.

[Editor's note: What's going on here, and in the second paragraph, is
that some groups are much larger than others.  1003.5 is among the
smallest.  The 1003.4 session I saw had about forty, overworked
attendees.  The 1003.5 sessions I saw had five to ten.

1003.5 could use a lot more participation from the Ada community.
Unfortunately, this may be a case of "once burned, twice shy".  For
years, there's been a lot of talk about "Ada environments", all of
which seem, from a UNIX perspective, like enormous, cumbersome
projects that might actually come into widespread use in, if not our
children's lifetimes, perhaps their children's.

Make no mistake about it: the Ada community is huge.  And easy
availability of machines with implemented, Ada-language bindings to
POSIX-conformant operating systems would be immensely useful to that
community.  The ability to buy a box, off-the-shelf, with a portable
environment for running Ada programs in the next couple of years,
would make Ada programmers' lives immensely easier and even be a big
aid in implementing the richer and more complex environments mentioned
in the previous paragraph.

Still, you can guess what the average, UNIX-naive, Ada programmer must
think: "Whoopie, another standard/environment.  I'll have to take a
look at it in a few years to see how it's coming along." If the IEEE
could make some non-vanishing fraction of the Ada community understand
that POSIX is on the verge of being here, now, dot 5 might get a lot
more help.

This seems to us (that's the editorial "we", folks) like a

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 3 -

quintessential marketing problem.  If 1003.5 could enlist the help of
1003.0 in this matter, they might be able to make some real headway
here.  ]

The 1003.5 group is also very interested in the progress of the
language-independent versions of the POSIX standard.  Much of the
labor of the Ada binding group has been devoted to separating the
essential semantics of the 1003.1 interface from the details of its
expression in the C language (for example, setjmp()/longjmp(), and
signal handlers).  This labor may be of use to those working on the
language-independent version of 1003.1, but the Ada group does wish
that new standards, such as 1003.4, would start out with a language-
independent document, rather than adding to the language-bias problem.

There was one change in the leadership of the 1003.5 working group.
Stowe Boyd, of Meridian, had been vice-chair but is no longer able to
spare time from his job to work on this project.  Steve Deller, of
Verdix, has agreed to replace him.  This is a very important job,
since the vice-chair of the 1003.5 group takes direct responsibility
for setting the technical agenda and running meetings.

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding

Volume-Number: Volume 17, Number 41

shar.1003.5.321
echo 1003.6
cat >1003.6 <<'shar.1003.6.321'
From jsq  Sun Nov  5 12:54:58 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10360; Sun, 5 Nov 89 12:54:58 -0500
From: Jeffrey S. Haemer <[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: 21 Oct 89 03:06:21 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 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 July
10-14, 1989 meeting, in San Jose, California:

P1003.6 (security) is split into four main groups: privileges,
mandatory access control (MAC), audit, and discretionary access
control (DAC).  In addition, there is a definitions group, whose
charter is to define terms and to insure that definitions used by
1003.6 do not clash with definitions in other 1003 groups.

  1.  DEFINITIONS

      The definitions group reviewed all definitions new to draft two.
      The majority were from the audit group and were approved.
      Amusingly, the lone exception was the definition of "audit",
      which included an interpretation of an audit record; the
      definition group considered this to be outside the audit group's
      goals.

      The group also chose a global naming convention,
      PREFIX_FUNCTIONNAME, where PREFIX represents the security
      section/topic.  Current prefixes are "priv_", "mac_", "aud_",
      and "acl_" (DAC).  The same prefix rule extends to data
      structures (e.g. "priv_t").

  2.  MAC

      Several issues were resolved.

         o+ A 'write up' standard will be neither restricted nor
           guaranteed.

__________

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

September 1989 Standards Update       IEEE 1003.6: Security Extensions


                                - 2 -

         o+ The 'upgrade directories' function was dropped, since a
           'write up' without a read does not guarantee success.

         o+ Change file label/level and change process label operations
           will be accepted for privileged processes

         o+ The MAC_PRESENT variable will be added to the sysconf, to
           indicate that a MAC mechanism is installed in the system.
           MAC_CONTROLLED and MAC_ALWAYS were also proposed.
           MAC_CONTROLLED would return the value of a file controlled
           by a MAC mechanism, and MAC_ALWAYS would indicate that all
           objects on the system contain associated MAC information.

         o+ A set of six privileges were defined: P_upgrade,
           P_covertchannel, P_MAC_READ, P_MAC_WRITE, P_LABEL_OBJ,
           P_LABEL_SUBJ.  The last two might be folded under
           READ/WRITE privileges, however these two are the most
           sensitive of all.

      The next meeting will see discussions of SUN's multiple-level
      directories, the recalculation function, and information labels.
      The group will also review the .6 draft, the MAC common
      description language interface, and 1003.1/.1a.

  3.  PRIVILEGES

      The privilege group has defined interfaces for file privileges.
      For example, priv_fstate_t() will return whether privilege for
      the file is required, allowed, or forbidden.  A process's
      privilege can be permitted, effective, or inheritable.

      Also, there is now a list of needed privileges, including
      PRIV_SETUID and PRIV_SETGID (set the uid and gid of a file or
      process), PRIV_FOWNER (change the owner uid of a file),
      PRIV_ADMIN (do administrative operations like unlinking a file),
      PRIV_RESOURCE (set the sticky bit or be able to use memory),
      DAC_READ/WRITE (override access search or read and access write)

      The process-privilege interface is still an open issue, and will
      be discussed in October.  These three suggestions are on the
      table:

        1.  A function pair.  priv_set_priv(id,attr,value) and valuet
            priv_get_priv(id,attr).  (Something of type "valuet" can
            take on the values "required", "allowed", or "forbidden".)

September 1989 Standards Update       IEEE 1003.6: Security Extensions


                                - 3 -

        2.  An interface to set or unset multiple privileges at a
            time.

        3.  A requirement that the operating system re-calculate
            privileges for each process every time that process
            manipulates an object.

      Next meeting, the privilege group will focus on developing
      functional interface descriptions in both English and in Common
      Descriptive Language (CDL).

  4.  DAC

      The DAC group decided to describe interfaces using a procedural
      interface.  They defined the minimum set of functions required
      for access control lists (ACLs) -- open, close, write, sort,
      create_entry, get_entry, dup_entry, delete_entry, set_key,
      get_key, and add/delete permission -- and the minimum set of
      commands -- getacl and setacl.  They also defined the needed
      privileges and passed their list to the privilege group.  The
      October meeting will focus on polishing the current draft and
      addressing default ACL interfaces.

  5.  AUDIT

      The group discussed portability, especially data portability.
      Should only privileged processes write to audit logs?  (The
      consensus is, "Yes.") And how much should the record format be
      standardized?

      The October meeting will see a draft review, plus discussions on
      event identification, classes, style and data representation,
      and token grammar.

  6.  NEW GROUP: NETWORK/SYSTEM ADMINISTRATION

      Because interconnectivity is at the heart of many security and
      administration issues, "interconnectivity" between P1003.6,
      P1003.7 (system administration), and P1003.8 (networking) had to
      improve.  A joint, evening meeting of the three groups set this
      in motion, and five members of 1003.6 have signed up to review
      drafts from the other two groups.  They intend to begin working
      on this area formally in October.

September 1989 Standards Update       IEEE 1003.6: Security Extensions


Volume-Number: Volume 17, Number 42

shar.1003.6.321
echo 1003.6.a
cat >1003.6.a <<'shar.1003.6.a.321'
From jsq  Sun Nov  5 13:57:55 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14079; Sun, 5 Nov 89 13:57:55 -0500
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: <[e-mail]>
Organization: Harris GISD, Melbourne, FL
Date: 25 Oct 89 14:41:51 GMT
Apparently-To: std-unix-archive

From: <[e-mail]>

In article <[e-mail]> you write:
[with sections liberally elided...]
[I've removed more from the quoted message.  -mod]
>From: Jeffrey S. Haemer <[e-mail]>
>...
>IEEE 1003.6: Security Extensions Update
>Ana Maria de Alvare <[e-mail]> reports on the July
>10-14, 1989 meeting, in San Jose, California:
>  3.  PRIVILEGES
>
>      The privilege group has defined interfaces for file privileges.
>      For example, priv_fstate_t() will return whether privilege for
>      the file is required, allowed, or forbidden.  A process's
>      privilege can be permitted, effective, or inheritable.
Could you explain the meanings of the priv_fstate_t() values?
I'm guessing:
process:
    permitted -- process may turn on this privilege
    effective -- process has turned on this privilege
    inheritable -- upon an exec, privilege remains in effect
file (effect when exec occurs):
    required -- ORs with the permitted and effective
    allowed -- ORs with the permitted
    forbidden -- removes inheritable privileges (and (NOT forb))

p->permitted = (p->inheritable | ip->required | ip->allowed) & ~ip->forbidden
p->effective = ((p_effective & p->inheritable) | ip->required) & ~ip->forbidden

Is this the intent?
--
    -----    -    -    -    -    -    -    -    ----
Bernard A. Badger Jr.    407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: [e-mail]|'s/./&&/g' Tom sed expansively.

Volume-Number: Volume 17, Number 48

shar.1003.6.a.321
echo 1003.7
cat >1003.7 <<'shar.1003.7.321'
From jsq  Sun Nov  5 13:07:08 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10998; Sun, 5 Nov 89 13:07:08 -0500
From: Jeffrey S. Haemer <[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: 21 Oct 89 03:09:21 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration Update

Steven J. McDowall <[e-mail]> reports on the July 10-14, 1989
meeting, in San Jose, California:

        War and Remembrance  - How I survived a Posix Meeting

Listen closely to this tale of wonder and bewilderment and hope that
you shall never have to face such horrors as I.  Yes, I was there
when, in a flurry of activity, the 1003.7 committee elected Steven
Carter to the chair.  To show he was a good choice, Carter immediately
sat on the chair to which he'd been elected.  This was swiftly
followed by the election of Vice-chairs Martin Kirk and Dave Hinnant
(though I shall speculate not on what vices they may have perpetrated
on those chairs); Mark Colburn, Secretary (owing to a proven ability
to take dictation lying on a pool-side sun bed); and their honors Bob
Bauman and Shoshana O'Brien, Technical Editors.

You may sense that I feel few exciting things happened in San Jose.
Correct.  I wish this group would get into some real fights, like
other groups.  Interoperability may prove our only hope.  Still,
progress is progress, however uncontentious. Here's what else seemed
to me to be important.

  1.  Language Independence

      The group voted, nearly unanimously, that the country of
      Language should be independent.  We were uncertain about where,
      precisely, it might be, but tentatively put it near Borneo.

      We chose to use ASN.1 ("Abstract Syntax Notation - 1") as our
      internal notation for data structures. The group also appointed
      me representative to the 1003.1 language-bindings group to watch
      what those pursuers of knowledge are doing in this area.

__________

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

September 1989 Standards Update     IEEE 1003.7: System Administration


                                - 2 -

  2.  Interoperability

      X/Open continues to push this into the foreground.  Luckily for
      us, they also continue to help us understand what it entails.
      Group consensus holds that interoperability is within the
      purview of 1003.7.  What we're still uncertain of is how far
      down we should standardize; only through the application layer?
      down to the packet layer?

      For example, a standard application-layer protocol insuring
      interoperability might require that certain Application Program
      Interface (API) calls be available, with given arguments and
      results, but say nothing about how those calls are made.  In
      contrast, a transport-level protocol might require that the
      information be fed into the API will be in a pseudo-ASN.1 format
      to help in non-homogeneous networks.  A still lower level
      protocol might detail the exact packet structure, including
      ASN.1 format for the object data, to prevent foreign machines in
      a non-homogeneous network from throwing out otherwise
      unrecognizable packets.

      Most committee members have strong, idiosyncratic ideas about
      this subject and the issue is certain to re-surface in Brussels.
      We need input on this from the community at large. Where do YOU
      think a standards organization like the IEEE should draw the
      line in ensuring interoperability?

      [Editor's note -- This is not a rhetorical question.  Things you
      do in the future may be affected by decisions P1003.7 makes in
      this arena.  If you have an opinion on this subject, speak up.]

      As an aside, the current X/OPEN representative, Jim Oldroyd of
      the Instruction Set, Ltd., who has really helped the group a
      great deal in this area, may not attend the next 1003.7 meeting.
      We think this would be a real loss, and hope that X/OPEN and his
      employer find a way to arrange for him to go.

  3.  Misc.

      Some progress was made in doing the ASN.1 syntax for a few of
      the basic objects the committee decided on for phase I of the
      standard.  Everyone is discovering that defining such objects
      (File Systems, Devices, Spools, etc.) in a non-ambiguous way
      using a meta-language like ASN.1 might not be as easy as we
      first thought.  Live and learn, eh?

September 1989 Standards Update     IEEE 1003.7: System Administration


Volume-Number: Volume 17, Number 43

shar.1003.7.321
echo 1003.8.1
cat >1003.8.1 <<'shar.1003.8.1.321'
From [e-mail]  Sat Dec  2 14:28:47 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06564; Sat, 2 Dec 89 14:28:47 -0500
Posted-Date: 2 Dec 89 17:52:17 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA03286; Sat, 2 Dec 89 13:28:38 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00241; Sat, 2 Dec 89 11:52:59 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/1: POSIX Transparent File Access
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 17:52:17 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/1: POSIX Transparent File Access Update

An anonymous correspondent reports on the July 10-14, 1989 meeting, in
San Jose, California:

[Editor's note -- Though this report came in substantially later than
the other July reports, I think it's still useful, provocative, and
well worth reading. -jsh]

                 Overview of New 1003.8 Developments

  1.  All standards produced by POSIX committees (with the exception
      of language-binding standards like 1003.5 and 1003.9) must be
      specified in a language-independent fashion, and must include at
      least one language-specific binding.  Since P1003 will not have
      guidelines and rules for constructing a language-independent
      specification before April 1990, no POSIX networking group can
      possibly ballot a document before July 1990.  "Mock" ballots
      (aka trial-use ballots) are unaffected by this, but their
      usefulness will be diminished.

  2.  Two new POSIX Networking working groups either have submitted or
      will soon submit PARs to begin work, bringing the total number
      of POSIX Networking working groups to six.  These new groups are
      the Name Space and Directory Services Interface and the X.400
      Mail Gateway Interface.  [Editor's note -- The SEC approved the
      PAR for the former, but decided that the latter transcends
      POSIX, and recommended that the IEEE form a separate, numbered
      group, analogous to 1003 or 1201, to handle X.400.  See below.
      -jsh]

  3.  Due to the rules governing IEEE and IEEE-TCOS standards
      activities, as well as the logistical nightmare six sub-working
      groups cause, the hierarchical structure of the P1003.8 POSIX
      networking committee will be flattened out, with each current
      sub-group submitting PARs to cover their current work.
      Coordination will be provided by a "POSIX Networking Steering
      Committee", made up of the chairs and vice-chairs of each

__________

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

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 2 -

      networking-related working group and the current chair and
      vice-chair of 1003.8.  [Editor's note -- This is still being
      debated by the SEC. -jsh]

  4.  Since each of the 1003.8 sub-groups will be submitting separate
      PARs, the P1003 Sponsor's Executive Committee (SEC) is taking
      the opportunity to evaluate the degree to which each PAR is
      intended to represent a part of the "POSIX Environment" or is a
      component which has no relationship to the rest of POSIX and
      should, hence, stand alone.  The result of this is that several
      of the 1003.8 sub-groups may be issued project numbers outside
      of the P1003 family.  There is some precedent for this; the X11
      interface group was assigned project number P1201 for just this
      reason.

               Activity in the TFA Subgroup, P1003.8/1

The group is making slow but steady progress towards the goals of a
fully-specified programmatic interface for networked file access and
the semantics and suggested syntax for administrative interfaces for
such a functionality.  The group is dominated by a faction, apparently
lead by Sun Microsystems, with a goal of ensuring that NFS, in some
form, is a sufficient mechanism to provide the service required by the
"full TFA" interface.  The balance of the committee is composed of
people who simply want a standard they can use as an acquisition tool.

Achievements

   + Enough consensus and material was obtained to permit development
     of a first draft of the programmatic interface part of the
     specification; this draft should be complete in time for the
     second mailing, due out on September 8.

   + Liaison activities with 1003.7 (System Administration) continued;
     .7 indicated that all of the options for the TFA mount/unmount
     model were, in fact, of use in administering such a system.  They
     also agreed that they owned responsibility for all file-system
     commands not completely unique in function to TFA, and that they
     would pursue input from the TFA group when the time was right.

   + Further progress was made on identifying status and usage
     information which must be obtainable from the provider of a TFA
     service.

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 3 -

Problem Areas

  1.  Representation in the group is unbalanced; there is, as of this
      time [Editor's note -- July, '89 -jsh], no substantial
      representation of the "stateful" side of the semantic issues.
      The chairman has, so far, been unsuccessful in encouraging a
      more balanced group viewpoint so representation from the
      stateful camp has been solicited (with minimal success) for
      future meetings.

  2.  Several "grey areas" in the semantics of IEEE 1003.1-1988 have
      been identified by the TFA group over the last several months.
      The suggested "fixes" have been slanted in a way that would let
      the TFA interface avoid relaxing 1003.1 semantics while
      permitting a stateless implementation of the TFA service; i.e.
      rather than strengthening 1003.1 to define the actual behavior
      of a single stand-alone system, the proposals have been so weak
      that they underconstrain single-system behavior.  It appears
      that the majority of the 1003.1 committee will not approve of
      this approach, and will require the "fix" to be of the proper
      strength to correctly specify single-system behavior.

      Let me give an example.  The original 1003.1 standard is silent
      on the issue of when the effects of a write are visible to a
      subsequent read of the same byte of the file.  If process A
      writes byte 123 of file "foo", then process B does a read of
      byte 123 of file "foo", at what point is B guaranteed to see the
      byte A wrote?

      Immediately?  If so, stateless solutions employing read caches
      fail; if process B is remote on system "bsys" and reading the
      file via NFS, byte 123 might come out of the file cache on bsys
      and not from the file cache on the system where A lives.

      Immediately if A and B are on the same system, and at some
      implementation-defined time otherwise?  This requires 1003.1 to
      define what it means by "the same system", and doesn't
      adequately address multi-processor single systems with
      "interesting" caches.  It also means a truly portable
      application that is interested in running in a distributed
      environment can *never* know when the byte written by A is
      visible to B.

      Only in the presence of byte locking?  In other words, A locks
      byte 123, writes it, unlocks it; if B then locks and reads 123,
      it is guaranteed to see what A wrote.  Not a bad solution, but
      it breaks existing applications and in fact is a relaxation of
      the intended semantics of 1003.1.

      Basically, the "intent" developing in 1003.1 is that the effect
      of the write must be seen immediately by any other process with

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 4 -

      that file open, without regard to process location, without
      recourse to O_SYNC mode opens, without the necessity for
      locking, and so on.  1003.1-1988 is silent on the issue; the
      proposed fix from TFA (basically a compromise I did not like and
      knew would fail) was that read-after-write be guaranteed only
      for co-located processes and in the presence of locking.  This
      gave 1003.1 a chance to avoid relaxing their intended semantics
      while leaving TFA a "loophole" to change semantics without
      having to indicate a change in wording from 1003.1.

      This is what got rejected by 1003.1, which is getting pretty
      damned tired of TFA's trying to claim that the full TFA
      semantics are "just like" 1003.1 but with gaping differences
      that are introduced silently due to weak or weasel wording in
      1003.1-1988.

  3.  1003.7, System Administration, is making distressingly slow
      progress.  If this continues, 1003.8 will have two choices with
      respect to client-side administrative commands:

         - Do not standardize them; give feedback to 1003.7 and wait
           for them to complete their specification.  This risks
           incompatible implementations.

         - Standardize them insofar as they relate to TFA
           administration.  This risks incompatibility between the TFA
           aspects of those commands and their more general aspects.
           An example is the "mount" command; if 1003.7 is unhappy
           with the form of the TFA mount command, they are under no
           constraint to remain compatible with it.  If the group
           ballots far enough in advance of 1003.7, this sort of clash
           could be frequent.

  4.  Many of the contentious issues have been "resolved" through the
      various mechanisms POSIX provides for introducing optional
      behavior; most frequently, these involve either
      "implementation-defined" behavior, or the addition of path-
      specific attributes whose status can be determined through the
      pathconf() function.  Several of these options should be viewed
      by the ballot group as being "gratuitous" in some sense, i.e.
      the TFA committee should take a stand one way or another, and be
      willing to be beaten up in ballot for it.  The POSIX standards
      are wishy-washy enough without the addition of gratuitous
      options.

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


Volume-Number: Volume 17, Number 80

shar.1003.8.1.321
echo 1989.10
cat >1989.10 <<'shar.1989.10.321'
echo intro
cat >intro <<'shar.intro.24760'
From jsq  Fri Nov  3 17:37:41 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA28287; Fri, 3 Nov 89 17:37:41 -0500
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update on IEEE 1003 July San Jose meeting
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: John S. Quarterman <[e-mail]>
Date: 20 Oct 89 20:52:07 GMT
Apparently-To: std-unix-archive

From: John S. Quarterman <[e-mail]>

This is the first posting in the set of articles about the July 1989
IEEE 1003.1 meeting in San Jose, California (not about the Brussels
meeting going on this week).  My apologies for not having posted them
when they arrived a couple of weeks ago.  Work and earthquakes and such
shouldn't be an excuse.

Here is a list of 1003 subcommittees:

    1003.0    POSIX Guide
*    1003.1    Systems Interface
*    1003.2    Shell and Tools Interface
    1003.3    Verification and Testing
    1003.4    Real Time
    1003.5    Ada Binding for POSIX
    1003.6    Security
    1003.7    System Administration
    1003.8    Distributed Services
*    1003.9    Fortran Bindings
*    1003.10    Supercomputing
    1003.11    Transaction Processing
*    1201    Interfaces for User Portability

* No report.

We really need somebody to snitch on 1003.2, the shell and tools group,
since it's the next one that's likely to produce a final standard.
Perhaps someone who goes to that committee's meetings could volunteer?

As the report editor, Jeffrey S. Haemer, says:
    This is more reports than we posted last time, but I still don't
    have a full set.  One of my goals for Brussels is to establish a
    working snitch for each group.

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

Volume-Number: Volume 17, Number 37

shar.intro.24760
echo 1003.0
cat >1003.0 <<'shar.1003.0.24760'
From jsq  Fri Nov  3 17:48:04 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00153; Fri, 3 Nov 89 17:48:04 -0500
From: Jeffrey S. Haemer <[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: 20 Oct 89 21:49:37 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide Update

Kevin Lewis <[e-mail]> reports on the July 10-14,
1989 meeting in San Jose, California:

As 1003.0 passes the mid-point of calendar year 1989, progress can be
earmarked by the arrival of line numbers to the guide document.  I
remember the first time I saw line numbers on a document within the
IEEE 1003 arena.  My first thought was "this committee is really doing
precise, exacting work".  Thus was my reaction again when I saw line
numbers on our document.  My balloon was burst, when one of our active
members -- and by "active member" I mean someone who commits
contributions in writing, not just someone who comes to voice an
opinion in a talk-show-like atmosphere -- pointed to our ISSUE LOG,
which states that the committee needs to do more work.  (There's that
word again.) Alas, I came back down to earth.  I have "miles to go
before I sleep."

Dot Zero continues to converge.  Our document is finally beginning to
tie together the standards and elements that comprise a POSIX open
system.  Key events continue to be the definition of terms that will
eventually make it to the IEEE Glossary and the identification of
areas where terms still need definition.

The group is still generating discussion/debate/argument/food-fights
over behemoth macro-questions such as, "What is the role of the
guide?" and, "What is the PROPER audience?" In addition, the group has
made valiant attempts at addressing specific areas such as graphics
and data interchange without the benefit of focused expertise. We now
agree on our ignorance in these areas, and will seek help and/or to
point to other committees that, we believe, can come up with the
answers.

Overall, we must meet our objective of going to ballot in October
1990, because that is what I told my wife, who is still trying to
figure out what in the world a "dot zero" might be.

__________

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

September 1989 Standards Update               IEEE 1003.0: POSIX Guide

Volume-Number: Volume 17, Number 38

shar.1003.0.24760
echo 1003.3
cat >1003.3 <<'shar.1003.3.24760'
From jsq  Sun Nov  5 12:17:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA08553; Sun, 5 Nov 89 12:17:11 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 22:02:11 GMT
Apparently-To: std-unix-archive

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

[ This is a reposting because the original doesn't even appear on uunet.  -mod ]




            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods Update

Doris Lebovits <[e-mail]> reports on the July 10-14,
1989 meeting in San Jose, California:

  1.  Overview
      This was the thirteenth meeting of P1003.  Monday through
      Wednesday, the group began work on a verification standard
      corresponding to 1003.2 (Shell and Tools).  Following the close
      of the formal meeting, the technical reviewers of the draft 10
      ballot met for the remainder of the week.

  2.  Meeting Summary
      This was the first meeting to develop the verification standard
      for P1003.2, which will contain test methods and test assertions
      for measuring 1003.2 conformance.  This standard will ultimately
      form part III of P1003.3.  (Part I contains definitions, generic
      test methods, and so forth; part II is test methods for
      measuring P1003.1 conformance, including test assertions.  As
      other P1003 standards reach maturity, their verification will,
      in turn, be covered in new parts of the P1003.3 standard.)

      The chair's aggressive goal is to be ready to bring part III to
      ballot after four quarterly meetings.  A detailed schedule and
      milestones will be developed at the next meeting.

      Attendees included representatives of AT&T, NIST, OSF,
      Mindcraft, IBM, DEC, HP, Data General, Cray Research, Unisys,
      Perennial and Unisoft Ltd.  The meeting agenda included:

         o+ the confirmation of new officers for the the part III work

              o+ Chair: Roger Martin

              o+ Vice-chair: Ray Wilkes

__________

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

September 1989 Standards Update              IEEE 1003.3: Test Methods


                                - 2 -

              o+ Technical Editor: Andrew Twigger

              o+ Secretary: Lowell Johnson

         o+ the rough scheduling and setting of general milestones for
           part III

         o+ a meeting with the P1003.2 working group to discuss testing
           issues

         o+ action item assignments

         o+ identification of items for the next meeting

      In addition, small groups formed to discuss and resolve three
      specific issues.  One group investigated the difficulty of
      thorough testing of the more complex utilities: awk, bc, ed,
      lex, make, pax, sh, and yacc.  (The resulting action item was to
      produce a prototype set of assertions.)  A second group scoped
      the writing of assertions for BNF type structures: "[]"
      expressions, regular expressions, and extended regular
      expressions.  The third reviewed "Verification of Commands
      Interface", a paper by Andrew Twigger of Unisoft Ltd.  The paper
      covers:

         o+ character set and locale

         o+ internationalized utilities

         o+ underlying OS primitives

         o+ regular expression testing

         o+ pattern matching notation

         o+ utility syntax rules

         o+ errors from P1003.1 associated functions

         o+ environment variables

         o+ standard output format

         o+ standard error format

         o+ environmental changes

         o+ symbolic limits

September 1989 Standards Update              IEEE 1003.3: Test Methods


                                - 3 -

         o+ obsolescent features

         o+ job control

         o+ read-only variables

         o+ signal numbers

      NIST has contributed its current 1003.2 test assertions to
      provide a basis for the 1003.2 verification work.  Sheila
      Frankel of NIST gave a short presentation on the current state
      of the these assertions, which include approximately 900
      Mindcraft test assertions, plus 2600 newly-created assertions,
      all based on P1003.2 Draft 8.

  3.  Technical Reviewer's Meeting
      In parallel to the verification work for P1003.2, balloting and
      revision is taking place on draft 10 of parts I and II.

      As of July 6, 1989, 77 responses had been received from the 125
      members in the balloting group. Eighteen additional responses
      will bring this to the 75% response needed to officially close
      the ballot.
      The tally of the 77 responses:
           28      positive        (36%)
           31      negative        (40%)
           18      abstain         (24%)

      The technical reviewers held a plenary session to evaluate and
      respond to the comments and objections to this draft.  Group
      consensus decided each issue and each decision was final.  Part
      I was reviewed completely but only a few chapters of part II
      were reviewed.  The remaining part II work was assigned to
      volunteers.

      Draft 11 is planned for ballot recirculations in October, 1989,
      and an approved standard for parts I and II is anticipated by
      the first quarter of 1990.

September 1989 Standards Update              IEEE 1003.3: Test Methods


Volume-Number: Volume 17, Number 39

shar.1003.3.24760
echo 1003.4
cat >1003.4 <<'shar.1003.4.24760'
From jsq  Sun Nov  5 12:33:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09101; Sun, 5 Nov 89 12:33:24 -0500
From: Jeffrey S. Haemer <[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: 20 Oct 89 22:05:45 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions Update

John Gertwagen <jag@laidbak> reports on the July 10-14, 1989 meeting
in San Jose, California:

The P1003.4 meeting in San Jose was very busy.  The meeting focused on
resolving mock-ballot objections and comments. Despite limited
resources for documenting changes, a lot of work got done.  Here's
what stood out.

Shared memory
     The preferred interface falls somewhere between shared-memory-
     only and a mapped-files interface, such as AIX's mmap(), which
     allows files to be treated like in-core arrays.  Group direction
     was to reduce the functionality to support only shared memory, so
     long as the resulting interfaces could be implemented as a
     library over mmap().

Process memory locking
     The various region locks were clarified and, thus, simplified;
     the old definitions were fuzzy and non-portable.  For those who
     haven't seen it, there is actually a memory residency interface
     (i.e., fetch and store operations to meet some metric) instead of
     a locking interface.  Most vendors will probably implement it as
     a lock, but some may want it to impose highest memory priority in
     the paging system.

Inter-process communication
     Members questioned whether the interface definitions could really
     support a broader range of requirements; they're like no others
     in the world today.  Having been designed to meet the real-time
     group's wish list, there are lots of bells and whistles -- far
     more than in System V IPC -- but it's not clear, for example,
     that they are network extensible.  Discussions in these areas
     continue.

__________

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

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions


                                - 2 -

Events and semaphores
     Members were concerned about possible overlap with other
     mechanisms, especially those being considered for threads. The
     question is basically, "Should there be separate functions for
     different flavors or a single function with multiple options?"
     General sentiment (including our snitch's) seems to be for
     multiple functions; however an implementation might choose to
     make them library interfaces to a common, more general system
     call.  There is, however, a significant minority opinion the
     other way.

Scheduling
     Many balloters found process lists and related semantics
     confusing.  An attempt was made to re-cast the wording to be more
     strictly in terms of process behavior.

Timers
     Inheritance was brought in line with existing (BSD) practice.

Outside of the mock ballot, there were two other major news items.

First, there is a movement afoot to make the .4 interfaces part of
1003.1.  They would become additional chapters and might be voted
separately or in logical groups.  This would bring P1003 in line with
the ISO model of a base standard plus application profiles. POSIX.4
would become the real-time profile group.  This is a non-trivial
change.

Up to now, the criterion for .4 has been that of "minimum necessary
for real-time", and has coincidentally been extended to support other
requirements "where convenient".  This is not a good starting point
for a base interface.  For example, mmap(), or something very much
like it, is probably the right base for "shared storage objects", but
real-time users want an interface for shared memory, not for mapped
files.  Our snitch worries that things might look a bit different had
the group been working on a base standard from the beginning.

Second, the committee officially began work on a threads interface,
forming a threads small group and creating a stub chapter in the .4
draft.  A working proposal for the interface, representing the
consensus direction of the working group, will be an appendix to the
next draft.

A lot of work remains to be done before .4 can go to ballot and the
current January '90 target may not be realistic.  If the proposed re-
organization occurs, a ballot before the summer of 1990 seems unlikely.

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 17, Number 40

shar.1003.4.24760
echo 1003.5
cat >1003.5 <<'shar.1003.5.24760'
From jsq  Sun Nov  5 12:42:52 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09731; Sun, 5 Nov 89 12:42:52 -0500
From: Jeffrey S. Haemer <[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: 20 Oct 89 23:08:44 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada-language Binding Update

Ted Baker <[e-mail]> reports on the July 10-14, 1989
meeting in San Jose, California:

The Ada-language binding for 1003.1 is progressing steadily, though
behind schedule.  The group agreed to try to prepare a document for
the October meeting in Brussels that is ready for mock ballot.  Those
at the meeting will decide whether the document has achieved this
goal.  If not, we will try again at the January meeting in New Orleans.

The slow progress is mainly due to the long time between meetings and
the limited workforce available to do the writing. The members, all
volunteers, must steal time for POSIX from their "real" (i.e.  paying)
jobs.  Attending quarterly meetings already puts most members near the
limit of time they can spare.

Most significant technical issues seem to be resolved; the remaining
controversies center on almost-religious issues, such as the exact
grouping of interface declarations into Ada packages, naming,
capitalization conventions, and where to strike the balance between
providing full functionality and idiot-proofing the interface.

Each chapter has been assigned to a person for review and editing,
based on decisions made at the San Jose meeting.  Quite a lot of
writing still needs to be done.  Chapter 7 ("Device- and Class-
Specific Functions" --i.e. terminal interfaces) is still empty, and
some others are still mostly just Ada code, with no discussion.  Most
of the rationale remains to be written.  Mitch Gart has agreed to
coordinate this, including a chapter on "meta-issues" -- design
decisions affecting the entire interface.  David Emery will combine
the chapters to produce the next draft.

Interaction with 1003.4 (Real-Time Extensions) has heated up, with
1003.4's consideration of support for multi-threaded processes.  Ada
language implementations must support multiple tasks (i.e. threads)

__________

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

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 2 -

within a POSIX process, to comply with the Ada language standard.
Neither the 1003.1 standard nor the 1003.4 draft that just completed
mock balloting supports multithreaded processes, so the Ada
implementor is currently forced to hack out some sort of internal
concurrency scheme, with its own layer of dispatching, for each Ada
process.  This tends to run aground when one Ada task makes a blocking
system call, since the whole process is forced to wait.  Naturally,
Ada implementors and users would be pleased if the POSIX interface
provided for concurrency within a process.

The Ada group is very interested in the threads proposal, and most
members would like to see some support for threads in the 1003.4
standard that goes to formal ballot.  Some members are a little bit
concerned that those working on the proposal may not understand Ada
tasking well enough to insure that the proposed threads will be
adequate to implement Ada tasking semantics.  This has been very
frustrating for members of the Ada group, since the discussions of the
threads proposal were all in parallel with meetings of 1003.5.  The
best the Ada group was able to do was to keep one observer present (on
rotation) at the review of the threads proposal.  It is not clear
whether this was adequate.

[Editor's note: What's going on here, and in the second paragraph, is
that some groups are much larger than others.  1003.5 is among the
smallest.  The 1003.4 session I saw had about forty, overworked
attendees.  The 1003.5 sessions I saw had five to ten.

1003.5 could use a lot more participation from the Ada community.
Unfortunately, this may be a case of "once burned, twice shy".  For
years, there's been a lot of talk about "Ada environments", all of
which seem, from a UNIX perspective, like enormous, cumbersome
projects that might actually come into widespread use in, if not our
children's lifetimes, perhaps their children's.

Make no mistake about it: the Ada community is huge.  And easy
availability of machines with implemented, Ada-language bindings to
POSIX-conformant operating systems would be immensely useful to that
community.  The ability to buy a box, off-the-shelf, with a portable
environment for running Ada programs in the next couple of years,
would make Ada programmers' lives immensely easier and even be a big
aid in implementing the richer and more complex environments mentioned
in the previous paragraph.

Still, you can guess what the average, UNIX-naive, Ada programmer must
think: "Whoopie, another standard/environment.  I'll have to take a
look at it in a few years to see how it's coming along." If the IEEE
could make some non-vanishing fraction of the Ada community understand
that POSIX is on the verge of being here, now, dot 5 might get a lot
more help.

This seems to us (that's the editorial "we", folks) like a

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 3 -

quintessential marketing problem.  If 1003.5 could enlist the help of
1003.0 in this matter, they might be able to make some real headway
here.  ]

The 1003.5 group is also very interested in the progress of the
language-independent versions of the POSIX standard.  Much of the
labor of the Ada binding group has been devoted to separating the
essential semantics of the 1003.1 interface from the details of its
expression in the C language (for example, setjmp()/longjmp(), and
signal handlers).  This labor may be of use to those working on the
language-independent version of 1003.1, but the Ada group does wish
that new standards, such as 1003.4, would start out with a language-
independent document, rather than adding to the language-bias problem.

There was one change in the leadership of the 1003.5 working group.
Stowe Boyd, of Meridian, had been vice-chair but is no longer able to
spare time from his job to work on this project.  Steve Deller, of
Verdix, has agreed to replace him.  This is a very important job,
since the vice-chair of the 1003.5 group takes direct responsibility
for setting the technical agenda and running meetings.

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding

Volume-Number: Volume 17, Number 41

shar.1003.5.24760
echo 1003.6
cat >1003.6 <<'shar.1003.6.24760'
From jsq  Sun Nov  5 12:54:58 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10360; Sun, 5 Nov 89 12:54:58 -0500
From: Jeffrey S. Haemer <[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: 21 Oct 89 03:06:21 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 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 July
10-14, 1989 meeting, in San Jose, California:

P1003.6 (security) is split into four main groups: privileges,
mandatory access control (MAC), audit, and discretionary access
control (DAC).  In addition, there is a definitions group, whose
charter is to define terms and to insure that definitions used by
1003.6 do not clash with definitions in other 1003 groups.

  1.  DEFINITIONS

      The definitions group reviewed all definitions new to draft two.
      The majority were from the audit group and were approved.
      Amusingly, the lone exception was the definition of "audit",
      which included an interpretation of an audit record; the
      definition group considered this to be outside the audit group's
      goals.

      The group also chose a global naming convention,
      PREFIX_FUNCTIONNAME, where PREFIX represents the security
      section/topic.  Current prefixes are "priv_", "mac_", "aud_",
      and "acl_" (DAC).  The same prefix rule extends to data
      structures (e.g. "priv_t").

  2.  MAC

      Several issues were resolved.

         o+ A 'write up' standard will be neither restricted nor
           guaranteed.

__________

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

September 1989 Standards Update       IEEE 1003.6: Security Extensions


                                - 2 -

         o+ The 'upgrade directories' function was dropped, since a
           'write up' without a read does not guarantee success.

         o+ Change file label/level and change process label operations
           will be accepted for privileged processes

         o+ The MAC_PRESENT variable will be added to the sysconf, to
           indicate that a MAC mechanism is installed in the system.
           MAC_CONTROLLED and MAC_ALWAYS were also proposed.
           MAC_CONTROLLED would return the value of a file controlled
           by a MAC mechanism, and MAC_ALWAYS would indicate that all
           objects on the system contain associated MAC information.

         o+ A set of six privileges were defined: P_upgrade,
           P_covertchannel, P_MAC_READ, P_MAC_WRITE, P_LABEL_OBJ,
           P_LABEL_SUBJ.  The last two might be folded under
           READ/WRITE privileges, however these two are the most
           sensitive of all.

      The next meeting will see discussions of SUN's multiple-level
      directories, the recalculation function, and information labels.
      The group will also review the .6 draft, the MAC common
      description language interface, and 1003.1/.1a.

  3.  PRIVILEGES

      The privilege group has defined interfaces for file privileges.
      For example, priv_fstate_t() will return whether privilege for
      the file is required, allowed, or forbidden.  A process's
      privilege can be permitted, effective, or inheritable.

      Also, there is now a list of needed privileges, including
      PRIV_SETUID and PRIV_SETGID (set the uid and gid of a file or
      process), PRIV_FOWNER (change the owner uid of a file),
      PRIV_ADMIN (do administrative operations like unlinking a file),
      PRIV_RESOURCE (set the sticky bit or be able to use memory),
      DAC_READ/WRITE (override access search or read and access write)

      The process-privilege interface is still an open issue, and will
      be discussed in October.  These three suggestions are on the
      table:

        1.  A function pair.  priv_set_priv(id,attr,value) and valuet
            priv_get_priv(id,attr).  (Something of type "valuet" can
            take on the values "required", "allowed", or "forbidden".)

September 1989 Standards Update       IEEE 1003.6: Security Extensions


                                - 3 -

        2.  An interface to set or unset multiple privileges at a
            time.

        3.  A requirement that the operating system re-calculate
            privileges for each process every time that process
            manipulates an object.

      Next meeting, the privilege group will focus on developing
      functional interface descriptions in both English and in Common
      Descriptive Language (CDL).

  4.  DAC

      The DAC group decided to describe interfaces using a procedural
      interface.  They defined the minimum set of functions required
      for access control lists (ACLs) -- open, close, write, sort,
      create_entry, get_entry, dup_entry, delete_entry, set_key,
      get_key, and add/delete permission -- and the minimum set of
      commands -- getacl and setacl.  They also defined the needed
      privileges and passed their list to the privilege group.  The
      October meeting will focus on polishing the current draft and
      addressing default ACL interfaces.

  5.  AUDIT

      The group discussed portability, especially data portability.
      Should only privileged processes write to audit logs?  (The
      consensus is, "Yes.") And how much should the record format be
      standardized?

      The October meeting will see a draft review, plus discussions on
      event identification, classes, style and data representation,
      and token grammar.

  6.  NEW GROUP: NETWORK/SYSTEM ADMINISTRATION

      Because interconnectivity is at the heart of many security and
      administration issues, "interconnectivity" between P1003.6,
      P1003.7 (system administration), and P1003.8 (networking) had to
      improve.  A joint, evening meeting of the three groups set this
      in motion, and five members of 1003.6 have signed up to review
      drafts from the other two groups.  They intend to begin working
      on this area formally in October.

September 1989 Standards Update       IEEE 1003.6: Security Extensions


Volume-Number: Volume 17, Number 42

shar.1003.6.24760
echo 1003.7
cat >1003.7 <<'shar.1003.7.24760'
From jsq  Sun Nov  5 13:07:08 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10998; Sun, 5 Nov 89 13:07:08 -0500
From: Jeffrey S. Haemer <[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: 21 Oct 89 03:09:21 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration Update

Steven J. McDowall <[e-mail]> reports on the July 10-14, 1989
meeting, in San Jose, California:

        War and Remembrance  - How I survived a Posix Meeting

Listen closely to this tale of wonder and bewilderment and hope that
you shall never have to face such horrors as I.  Yes, I was there
when, in a flurry of activity, the 1003.7 committee elected Steven
Carter to the chair.  To show he was a good choice, Carter immediately
sat on the chair to which he'd been elected.  This was swiftly
followed by the election of Vice-chairs Martin Kirk and Dave Hinnant
(though I shall speculate not on what vices they may have perpetrated
on those chairs); Mark Colburn, Secretary (owing to a proven ability
to take dictation lying on a pool-side sun bed); and their honors Bob
Bauman and Shoshana O'Brien, Technical Editors.

You may sense that I feel few exciting things happened in San Jose.
Correct.  I wish this group would get into some real fights, like
other groups.  Interoperability may prove our only hope.  Still,
progress is progress, however uncontentious. Here's what else seemed
to me to be important.

  1.  Language Independence

      The group voted, nearly unanimously, that the country of
      Language should be independent.  We were uncertain about where,
      precisely, it might be, but tentatively put it near Borneo.

      We chose to use ASN.1 ("Abstract Syntax Notation - 1") as our
      internal notation for data structures. The group also appointed
      me representative to the 1003.1 language-bindings group to watch
      what those pursuers of knowledge are doing in this area.

__________

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

September 1989 Standards Update     IEEE 1003.7: System Administration


                                - 2 -

  2.  Interoperability

      X/Open continues to push this into the foreground.  Luckily for
      us, they also continue to help us understand what it entails.
      Group consensus holds that interoperability is within the
      purview of 1003.7.  What we're still uncertain of is how far
      down we should standardize; only through the application layer?
      down to the packet layer?

      For example, a standard application-layer protocol insuring
      interoperability might require that certain Application Program
      Interface (API) calls be available, with given arguments and
      results, but say nothing about how those calls are made.  In
      contrast, a transport-level protocol might require that the
      information be fed into the API will be in a pseudo-ASN.1 format
      to help in non-homogeneous networks.  A still lower level
      protocol might detail the exact packet structure, including
      ASN.1 format for the object data, to prevent foreign machines in
      a non-homogeneous network from throwing out otherwise
      unrecognizable packets.

      Most committee members have strong, idiosyncratic ideas about
      this subject and the issue is certain to re-surface in Brussels.
      We need input on this from the community at large. Where do YOU
      think a standards organization like the IEEE should draw the
      line in ensuring interoperability?

      [Editor's note -- This is not a rhetorical question.  Things you
      do in the future may be affected by decisions P1003.7 makes in
      this arena.  If you have an opinion on this subject, speak up.]

      As an aside, the current X/OPEN representative, Jim Oldroyd of
      the Instruction Set, Ltd., who has really helped the group a
      great deal in this area, may not attend the next 1003.7 meeting.
      We think this would be a real loss, and hope that X/OPEN and his
      employer find a way to arrange for him to go.

  3.  Misc.

      Some progress was made in doing the ASN.1 syntax for a few of
      the basic objects the committee decided on for phase I of the
      standard.  Everyone is discovering that defining such objects
      (File Systems, Devices, Spools, etc.) in a non-ambiguous way
      using a meta-language like ASN.1 might not be as easy as we
      first thought.  Live and learn, eh?

September 1989 Standards Update     IEEE 1003.7: System Administration


Volume-Number: Volume 17, Number 43

shar.1003.7.24760
echo 1003.11
cat >1003.11 <<'shar.1003.11.24760'
From jsq  Sun Nov  5 13:34:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA12450; Sun, 5 Nov 89 13:34:24 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11:  Application Transaction Processing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 23 Oct 89 20:14:31 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.11:  Application Transaction Processing Update

Bob Snead <[e-mail]> reports on the July 10-14, 1989 meeting
in San Jose, California:

1003.11 (application transaction processing, or TP) is one of two
recently approved working groups -- the other being P1003.10
(supercomputing) -- whose charter is to write an application
environment profile (AEP).  A profile is simply a list of pointers to
existing standards within the POSIX OSE (Open System Environment).
Where the group finds functionality missing from this set of
standards, the group may either commission its definition by some
other POSIX group or write a new PAR to request that IEEE create a
standard in the area.

This was our first meeting as 1003.11; the previous three meetings
were as a study group.  This study group was formed last year at the
Ft. Lauderdale meeting to investigate the feasibility of extending
POSIX into transaction processing.  In those first three meetings
there was consensus that POSIX should address transaction processing.

At this point, the TP group is reviewing existing standards in detail
to find out what's already been done.  To this end, they have split
into two subgroups, one to review models, the other to search out and
review other relevant standards.  There seems to be some consensus
that once we understand what is available, there will still be new
interfaces to define.

TP under Unix is currently sort of a funny domain.  Database vendors
believe that transaction processing is theirs.  They build TP
primitives into their products that let application developers define
transactions over modifications to data.  More and more UNIX
application developers want, instead, to write applications that bind
a group of modifications to data managed by assorted vendors products,
including multiple databases, screen managers and file systems.
Sensing this need, X/OPEN boldly chartered a group to define such
services.  In addition, ISO, some time ago, recognized the need for

__________

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

September 1989 StandarIdEsEEUp1d0a0t3e.11:  Application Transaction Processing


                                - 2 -

services to define transactions which span heterogeneous open systems,
and began a group to define such services.  ISO also has groups
defining CCR (Commitment, Concurrency, and Recovery) and RDA (Remote
Data Access), each of which is an essential part of TP, especially
distributed TP.

Both efforts are pretty far along.  X/OPEN has defined a model and a
set of interfaces but, since they are not a real standards body,
referencing their work may present some problems for P1003.11.  The
ISO group recently resolved all outstanding objections to their model,
services and protocols.  What remains for us then is to place the
relevant portions of their work into a POSIX framework, filling in the
holes.

September 1989 StandarIdEsEEUp1d0a0t3e.11:  Application Transaction Processing


Volume-Number: Volume 17, Number 46

shar.1003.11.24760
echo 1003.8.1
cat >1003.8.1 <<'shar.1003.8.1.24760'
From [e-mail]  Sat Dec  2 14:28:47 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06564; Sat, 2 Dec 89 14:28:47 -0500
Posted-Date: 2 Dec 89 17:52:17 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA03286; Sat, 2 Dec 89 13:28:38 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00241; Sat, 2 Dec 89 11:52:59 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/1: POSIX Transparent File Access
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 17:52:17 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/1: POSIX Transparent File Access Update

An anonymous correspondent reports on the July 10-14, 1989 meeting, in
San Jose, California:

[Editor's note -- Though this report came in substantially later than
the other July reports, I think it's still useful, provocative, and
well worth reading. -jsh]

                 Overview of New 1003.8 Developments

  1.  All standards produced by POSIX committees (with the exception
      of language-binding standards like 1003.5 and 1003.9) must be
      specified in a language-independent fashion, and must include at
      least one language-specific binding.  Since P1003 will not have
      guidelines and rules for constructing a language-independent
      specification before April 1990, no POSIX networking group can
      possibly ballot a document before July 1990.  "Mock" ballots
      (aka trial-use ballots) are unaffected by this, but their
      usefulness will be diminished.

  2.  Two new POSIX Networking working groups either have submitted or
      will soon submit PARs to begin work, bringing the total number
      of POSIX Networking working groups to six.  These new groups are
      the Name Space and Directory Services Interface and the X.400
      Mail Gateway Interface.  [Editor's note -- The SEC approved the
      PAR for the former, but decided that the latter transcends
      POSIX, and recommended that the IEEE form a separate, numbered
      group, analogous to 1003 or 1201, to handle X.400.  See below.
      -jsh]

  3.  Due to the rules governing IEEE and IEEE-TCOS standards
      activities, as well as the logistical nightmare six sub-working
      groups cause, the hierarchical structure of the P1003.8 POSIX
      networking committee will be flattened out, with each current
      sub-group submitting PARs to cover their current work.
      Coordination will be provided by a "POSIX Networking Steering
      Committee", made up of the chairs and vice-chairs of each

__________

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

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 2 -

      networking-related working group and the current chair and
      vice-chair of 1003.8.  [Editor's note -- This is still being
      debated by the SEC. -jsh]

  4.  Since each of the 1003.8 sub-groups will be submitting separate
      PARs, the P1003 Sponsor's Executive Committee (SEC) is taking
      the opportunity to evaluate the degree to which each PAR is
      intended to represent a part of the "POSIX Environment" or is a
      component which has no relationship to the rest of POSIX and
      should, hence, stand alone.  The result of this is that several
      of the 1003.8 sub-groups may be issued project numbers outside
      of the P1003 family.  There is some precedent for this; the X11
      interface group was assigned project number P1201 for just this
      reason.

               Activity in the TFA Subgroup, P1003.8/1

The group is making slow but steady progress towards the goals of a
fully-specified programmatic interface for networked file access and
the semantics and suggested syntax for administrative interfaces for
such a functionality.  The group is dominated by a faction, apparently
lead by Sun Microsystems, with a goal of ensuring that NFS, in some
form, is a sufficient mechanism to provide the service required by the
"full TFA" interface.  The balance of the committee is composed of
people who simply want a standard they can use as an acquisition tool.

Achievements

   + Enough consensus and material was obtained to permit development
     of a first draft of the programmatic interface part of the
     specification; this draft should be complete in time for the
     second mailing, due out on September 8.

   + Liaison activities with 1003.7 (System Administration) continued;
     .7 indicated that all of the options for the TFA mount/unmount
     model were, in fact, of use in administering such a system.  They
     also agreed that they owned responsibility for all file-system
     commands not completely unique in function to TFA, and that they
     would pursue input from the TFA group when the time was right.

   + Further progress was made on identifying status and usage
     information which must be obtainable from the provider of a TFA
     service.

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 3 -

Problem Areas

  1.  Representation in the group is unbalanced; there is, as of this
      time [Editor's note -- July, '89 -jsh], no substantial
      representation of the "stateful" side of the semantic issues.
      The chairman has, so far, been unsuccessful in encouraging a
      more balanced group viewpoint so representation from the
      stateful camp has been solicited (with minimal success) for
      future meetings.

  2.  Several "grey areas" in the semantics of IEEE 1003.1-1988 have
      been identified by the TFA group over the last several months.
      The suggested "fixes" have been slanted in a way that would let
      the TFA interface avoid relaxing 1003.1 semantics while
      permitting a stateless implementation of the TFA service; i.e.
      rather than strengthening 1003.1 to define the actual behavior
      of a single stand-alone system, the proposals have been so weak
      that they underconstrain single-system behavior.  It appears
      that the majority of the 1003.1 committee will not approve of
      this approach, and will require the "fix" to be of the proper
      strength to correctly specify single-system behavior.

      Let me give an example.  The original 1003.1 standard is silent
      on the issue of when the effects of a write are visible to a
      subsequent read of the same byte of the file.  If process A
      writes byte 123 of file "foo", then process B does a read of
      byte 123 of file "foo", at what point is B guaranteed to see the
      byte A wrote?

      Immediately?  If so, stateless solutions employing read caches
      fail; if process B is remote on system "bsys" and reading the
      file via NFS, byte 123 might come out of the file cache on bsys
      and not from the file cache on the system where A lives.

      Immediately if A and B are on the same system, and at some
      implementation-defined time otherwise?  This requires 1003.1 to
      define what it means by "the same system", and doesn't
      adequately address multi-processor single systems with
      "interesting" caches.  It also means a truly portable
      application that is interested in running in a distributed
      environment can *never* know when the byte written by A is
      visible to B.

      Only in the presence of byte locking?  In other words, A locks
      byte 123, writes it, unlocks it; if B then locks and reads 123,
      it is guaranteed to see what A wrote.  Not a bad solution, but
      it breaks existing applications and in fact is a relaxation of
      the intended semantics of 1003.1.

      Basically, the "intent" developing in 1003.1 is that the effect
      of the write must be seen immediately by any other process with

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 4 -

      that file open, without regard to process location, without
      recourse to O_SYNC mode opens, without the necessity for
      locking, and so on.  1003.1-1988 is silent on the issue; the
      proposed fix from TFA (basically a compromise I did not like and
      knew would fail) was that read-after-write be guaranteed only
      for co-located processes and in the presence of locking.  This
      gave 1003.1 a chance to avoid relaxing their intended semantics
      while leaving TFA a "loophole" to change semantics without
      having to indicate a change in wording from 1003.1.

      This is what got rejected by 1003.1, which is getting pretty
      damned tired of TFA's trying to claim that the full TFA
      semantics are "just like" 1003.1 but with gaping differences
      that are introduced silently due to weak or weasel wording in
      1003.1-1988.

  3.  1003.7, System Administration, is making distressingly slow
      progress.  If this continues, 1003.8 will have two choices with
      respect to client-side administrative commands:

         - Do not standardize them; give feedback to 1003.7 and wait
           for them to complete their specification.  This risks
           incompatible implementations.

         - Standardize them insofar as they relate to TFA
           administration.  This risks incompatibility between the TFA
           aspects of those commands and their more general aspects.
           An example is the "mount" command; if 1003.7 is unhappy
           with the form of the TFA mount command, they are under no
           constraint to remain compatible with it.  If the group
           ballots far enough in advance of 1003.7, this sort of clash
           could be frequent.

  4.  Many of the contentious issues have been "resolved" through the
      various mechanisms POSIX provides for introducing optional
      behavior; most frequently, these involve either
      "implementation-defined" behavior, or the addition of path-
      specific attributes whose status can be determined through the
      pathconf() function.  Several of these options should be viewed
      by the ballot group as being "gratuitous" in some sense, i.e.
      the TFA committee should take a stand one way or another, and be
      willing to be beaten up in ballot for it.  The POSIX standards
      are wishy-washy enough without the addition of gratuitous
      options.

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


Volume-Number: Volume 17, Number 80

shar.1003.8.1.24760
echo 1003.6.a
cat >1003.6.a <<'shar.1003.6.a.24760'
From jsq  Sun Nov  5 13:57:55 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14079; Sun, 5 Nov 89 13:57:55 -0500
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: <[e-mail]>
Organization: Harris GISD, Melbourne, FL
Date: 25 Oct 89 14:41:51 GMT
Apparently-To: std-unix-archive

From: <[e-mail]>

In article <[e-mail]> you write:
[with sections liberally elided...]
[I've removed more from the quoted message.  -mod]
>From: Jeffrey S. Haemer <[e-mail]>
>...
>IEEE 1003.6: Security Extensions Update
>Ana Maria de Alvare <[e-mail]> reports on the July
>10-14, 1989 meeting, in San Jose, California:
>  3.  PRIVILEGES
>
>      The privilege group has defined interfaces for file privileges.
>      For example, priv_fstate_t() will return whether privilege for
>      the file is required, allowed, or forbidden.  A process's
>      privilege can be permitted, effective, or inheritable.
Could you explain the meanings of the priv_fstate_t() values?
I'm guessing:
process:
    permitted -- process may turn on this privilege
    effective -- process has turned on this privilege
    inheritable -- upon an exec, privilege remains in effect
file (effect when exec occurs):
    required -- ORs with the permitted and effective
    allowed -- ORs with the permitted
    forbidden -- removes inheritable privileges (and (NOT forb))

p->permitted = (p->inheritable | ip->required | ip->allowed) & ~ip->forbidden
p->effective = ((p_effective & p->inheritable) | ip->required) & ~ip->forbidden

Is this the intent?
--
    -----    -    -    -    -    -    -    -    ----
Bernard A. Badger Jr.    407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: [e-mail]|'s/./&&/g' Tom sed expansively.

Volume-Number: Volume 17, Number 48

shar.1003.6.a.24760
exit
shar.1989.10.321
echo 1003.11
cat >1003.11 <<'shar.1003.11.321'
From jsq  Sun Nov  5 13:34:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA12450; Sun, 5 Nov 89 13:34:24 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11:  Application Transaction Processing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 23 Oct 89 20:14:31 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.11:  Application Transaction Processing Update

Bob Snead <[e-mail]> reports on the July 10-14, 1989 meeting
in San Jose, California:

1003.11 (application transaction processing, or TP) is one of two
recently approved working groups -- the other being P1003.10
(supercomputing) -- whose charter is to write an application
environment profile (AEP).  A profile is simply a list of pointers to
existing standards within the POSIX OSE (Open System Environment).
Where the group finds functionality missing from this set of
standards, the group may either commission its definition by some
other POSIX group or write a new PAR to request that IEEE create a
standard in the area.

This was our first meeting as 1003.11; the previous three meetings
were as a study group.  This study group was formed last year at the
Ft. Lauderdale meeting to investigate the feasibility of extending
POSIX into transaction processing.  In those first three meetings
there was consensus that POSIX should address transaction processing.

At this point, the TP group is reviewing existing standards in detail
to find out what's already been done.  To this end, they have split
into two subgroups, one to review models, the other to search out and
review other relevant standards.  There seems to be some consensus
that once we understand what is available, there will still be new
interfaces to define.

TP under Unix is currently sort of a funny domain.  Database vendors
believe that transaction processing is theirs.  They build TP
primitives into their products that let application developers define
transactions over modifications to data.  More and more UNIX
application developers want, instead, to write applications that bind
a group of modifications to data managed by assorted vendors products,
including multiple databases, screen managers and file systems.
Sensing this need, X/OPEN boldly chartered a group to define such
services.  In addition, ISO, some time ago, recognized the need for

__________

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

September 1989 StandarIdEsEEUp1d0a0t3e.11:  Application Transaction Processing


                                - 2 -

services to define transactions which span heterogeneous open systems,
and began a group to define such services.  ISO also has groups
defining CCR (Commitment, Concurrency, and Recovery) and RDA (Remote
Data Access), each of which is an essential part of TP, especially
distributed TP.

Both efforts are pretty far along.  X/OPEN has defined a model and a
set of interfaces but, since they are not a real standards body,
referencing their work may present some problems for P1003.11.  The
ISO group recently resolved all outstanding objections to their model,
services and protocols.  What remains for us then is to place the
relevant portions of their work into a POSIX framework, filling in the
holes.

September 1989 StandarIdEsEEUp1d0a0t3e.11:  Application Transaction Processing


Volume-Number: Volume 17, Number 46

shar.1003.11.321
exit