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

Internet Message Format | 1989-01-07 | 70KB

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 1: Overview
Message-ID: <[e-mail]>
Date: 10 Dec 88 23:24:34 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 96
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
Because the report, like the committees it reports on,
has become long and involved, it is being posted in parts,
currently nine, with perhaps more to follow.  Feel free
to reply or follow up to any part or to the whole thing.

Much of the information in the report was collected through
the USENIX Standards Watchdog Committee.  If you want to
participate, see the addresses in Part 1 below.  -mod ]


      An update on UNIX|= Standards Activities - Part 1

                          Overview

                      December 8, 1988

           Shane P. McCarron, NAPS International

This is the fourth in a series of articles on Unix related
standards activities.  In this edition I am going to cover a
slightly wider area than usual.  There have been
developments at the ANSI X3 level, the National Bureau of
Standards, and within the POSIX committees that all deserve
attention.  Because there is so much material this article
has been divided into a series for posting to Usenet. I will
apologize at the outset for the length of this series, but I
feel that all of the information is timely and important.
In addition to information on group activities, included
with each report is a contact person from whom you can get
more information about these developments, and the names of
Watchdog Committee members through whom you can relay your
opinions to the specific standards committees.

On the subject of the Watchdog Committee, this series is now
an activity of that group.  Last quarter I used the article
to solicit participation in the committee, and I am pleased
to report that we have a number of new associate members.
While I am not familiar with everyone now involved, I would
like to thank those who contributed heavily to this series:
Ted Baker, Mark Colburn, Doug Gwyn, Sol Kavy, Doris
Lebovits, Kevin Lewis.  We are still in search of members
for this group.  While we will accept all comers, we are
particularly interested in filling out our rather lean
international input department.  If you would like to be
involved in the Watchdog activities, or know of someone who
might be a good candidate, please contact:

          John S. Quarterman
          Texas Internet Consulting
          701 Brazos, Suite 500
          Austin, TX  78701-3243
          [phone]
          [e-mail]
or

__________

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


                           - 2 -

          Mark Colburn
          NAPS International
          117 Mackubin St.
          Suite 1
          St. Paul, MN  55102
          [phone]
          [e-mail]

IEEE P1003 - The POSIX Committees

The POSIX committees met October 24th - 28th in Honolulu,
Hawaii.  At this meeting there were a record breaking 200+
attendees and meetings for eight working groups.  Included
in this series are updates on each of the groups within
P1003, with the exception of IEEE P1003.6 and 1003.8.  We
are awaiting further information on those groups.

Please look to the subsequent postings in this series for
all of the reports.  If you have any comments or
suggestions, please contact me at:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          [phone]
          [e-mail]
          uunet!bungia.mn.org!ahby

Volume-Number: Volume 15, Number 36

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 2:  C Language Standard
Message-ID: <[e-mail]>
Date: 11 Dec 88 00:07:13 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 183
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]



      An update on UNIX|= Standards Activities - Part 2

                    C Language Standard

                     November 18, 1988

           Shane P. McCarron, NAPS International

C Language Standard

X3J11 (ANSI C standardization committee) met 26-30 Sep. 1988
at Sunnyvale, CA.  Principal business of the meeting was to
respond to comments received during the third round of
formal public review, which had closed earlier that month.
In addition to the 15 letters formally registered with
CBEMA's X3 Secretariat, 27 unregistered letters were
included.  There were 632 items contained in these 42
letters.  In order to address them all, the committee was
divided into response preparation subgroups, each of which
tackled a subset of the total list of items.  From time to
time, the whole committee reassembled to hear issues that
the subgroups were not able to completely resolve by
themselves.  In several cases a straw vote was taken to
determine the sense of the committee. The resulting
responses were formatted to produce the official X3J11
Response Document.

At the Sunnyvale meeting, several editorial changes to the
draft standard were approved. The working definition of
``editorial'' was:  A change is editorial if it clarifies
the original intent of the committee; it is substantive if
it changes the committee's intent.

There were several issues that were of particular interest
to the UNIX/POSIX community:

   o+ A change was made that clarified the ability of an
     application to portably reestablish a signal handler
     for the signal that caused entry to the handler.  This
     is indeed allowed under the standard.  The important
     passage reads:

          If the signal occurs other than as a result of
          calling the abort or raise function, the behavior

__________

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


                           - 2 -

          is undefined if the signal handler calls any
          function in the standard library other than the
          signal function itself (with a first argument of
          the signal number corresponding to the signal that
          caused the invocation of the handler) or refers to
          any object with static storage duration other than
          by assigning a value to a static storage duration
          variable of type volatile sig_atomic_t.

   o+ IEEE Std 1003.1-1988 (POSIX) requires that the fflush
     function specified by X3J11 have some additional
     semantics.  The committee confirmed that this was
     indeed allowed by ANSI C.

   o+ The IEEE P1003.1 working group had asked X3J11 to
     consider making the symbol "environ" a reserve external
     identifier.  This would mean that a ANSI C conforming
     portable application could not use the symbol.  This
     request was made because in traditional UNIX
     implementations application launch routines initialize
     this variable to be a pointer to the user's environment
     variable list, and this may not be what a strictly
     conforming ANSI C application would expect.  This issue
     was raised before the committee, but found no support
     for a change; the committee response for this was as
     follows:

          The ANSI C and IEEE 1003.1-1988 standards are not
          necessarily in conflict here, although it is true
          that in order to avoid the name-space conflict a
          mutually conforming implementation must rely on
          some mechanism such as `global symbolic equate' or
          a zero-size global object `environ' in a separate
          library module immediately preceding the module
          that defines storage for `__environ' (the name
          used by the C run-time startup code).  Implementor
          control over the way the linker operates, while
          inappropriate to require for the more universal C
          Standard (hence the constraint on uniqueness of
          external identifiers), is not unrealistic to
          expect for most POSIX implementations.  Several
          implementors have in fact indicated their
          intention to provide such a feature.

          Another solution, of course, would be to use
          separate run-time startup modules for strict
          ANSI-conforming and vendor-extended (possibly
          POSIX-conforming) implementations, perhaps via a
          compiler flag.  This may be useful anyway, for
          hiding extensions in certain standard headers.''


                           - 3 -

Because no substantive changes to the proposed standard
resulted from the third-round review process, X3J11 voted
unanimously to submit the standard as edited to reflect
approved editorial changes to CBEMA X3 as the proposed ANSI
C standard, pending completion of additional review as
described below.

The draft Response Document was reviewed first by a small
group of X3J11 members using electronic mail, then by a
group meeting at Plum-Hall in Cardiff, NJ on 20-21 Oct.
1988.  The responses were checked for completeness,
consistency, and accuracy, and occasionally the original
responses were changed to achieve those goals, or to meet
the additional requirement that no unauthorized substantive
change to the proposed standard could be promised by any
response.  Changes made at the review meeting were
subsequently edited into the master Response Document.  Two
significant areas of the standard were affected by editorial
changes resulting from the response review process: The
description of pointer arithmetic was substantially reworked
to avoid reliance on an assumption of byte addressability,
and the specification of the role of type qualifiers was
rewritten to clarify the significance of what was called the
``top type'' (now called ``type category'').

On 1 Nov. 1988, the draft proposed Standard itself was
reviewed by several X3J11 members in a meeting at Summit,
NJ.  Since the draft already contained the results of the
Sunnyvale meeting and response review meeting, very few
changes were found to be necessary at the draft review
meeting.

On 9 Nov. 1988, the Rationale Document (designed to
accompany the Standard) was reviewed by a group of X3J11
members meeting in Cambridge, MA.

On 14 Nov. 1988, copies of all three documents (Response,
Standard, Rationale) were express-mailed to the 15 X3-
registered commenters, who have 15 working days (from
November 18th) in which to reply to X3 if they feel that
their items were not properly addressed by X3J11.  The
commenters were encouraged to first discuss problems with
X3J11 members, in hopes of reducing the amount of negative
feedback to X3.

On 9 Dec. 1988, all three documents plus any feedback from
the commenters are to be submitted to CBEMA's X3 Secretariat
as the official X3J11 proposal for the ANSI Standard for
Programming Language C.  After review by X3, assuming no
problems arise the proposed Standard will then be submitted
to ANSI for official ratification as an ANSI standard.  It


                           - 4 -

seems probable that the final ANSI C standard will be
published some time during 1989.

The Watchdog contact person in X3J11 is Doug Gwyn.  He can
be reached at:

          Doug Gwyn
          US Army Ballistic Research Lab
          801 L Cashew Ct.
          Belair, MD  21014
          [e-mail]
          [phone]


Volume-Number: Volume 15, Number 37

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 3: NIST FIPS
Message-ID: <[e-mail]>
Date: 11 Dec 88 01:12:11 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 137
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 3

    NIST (NBS) Federal Inforamtion Processing Standards

                     November 18, 1988

           Shane P. McCarron, NAPS International

National Institute of Standards and Technology

On August 30th, 1988 (4 days after publication of the last
article in this series) the NIST (formerly the National
Bureau of Standards) published their Federal Information
Processing Standard for POSIX.  I have written much about
this in the past, so I won't go into the details of it now.
Suffice it to say that this FIPS is finally approved, but
differs substantially from the approved IEEE standard in a
few key areas.  The NIST is now working to revise the FIPS
so that it is more in line with the real standard.  This new
FIPS should be announced in the Federal Register in early
January, and after time for public comment and review will
be formally approved.  The NIST expects approval sometime in
the summer of 1989.

In the last article I mentioned that the NIST had announced
their intent to create FIPS in a number of other areas.
They have now released a preliminary FIPS for System
Administration, and are about to release one for Shell and
Tools. They have also stated that by year's end they will
release a FIPS on utilities with User Interfaces (like vi).
While in the case of Shell and Tools the NIST is going to
use Draft 8 of the 1003.2 standard, there are no existing
formal standards in the other areas.  Instead of waiting for
standard bodies to develop mature documents, the NIST is
going to a number of different versions of UNIX, and picking
those things that look neat.  The System Administration FIPS
in particular is disturbing.  There are a number of
utilities in there from AIX (IBM's version of UNIX), Xenix
(SCO or Microsoft, I can't tell), and of course the SVID
(from AT&T).  This ensures that there is no existing system
that will conform to the FIPS on day one, and also shackles
the newly formed IEEE working group on System
Administration.

__________

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


                           - 2 -

I really don't know what the NIST is trying to achieve.  It
appears as if they are working toward their stated goal of
creating a full suite of specifications to flesh out the
Applications Portability Profile (a conceptual model of
portability specifications created by the NBS over the last
few years).  I used to think that they had some sort of
hidden agenda, but I don't believe that any more.  I used to
think that they were trying to railroad standards to make
sure that the government's needs were satisfied.  In this I
have also been proven wrong.  They have now shown their
ability to create standards at will, thereby invalidating
the work of the standards bodies before they can even begin.
This interesting turn of events proves that in their
previous heinous acts they were just being nice.  They could
have superceded the process altogether if they had really
wanted to!

It was bad enough when the work of the committees was being
affected by the arbitrary timelines imposed by the NIST, but
now they have created a framework within which any standard
on, say, System Administration will have to fall if it is to
be taken seriously by the vendor community.  What vendor in
its right mind would conform to a formal standard that was
not in line with the standard being required by all U.S.
federal agencies?  The obvious answer is "vendors that don't
want to sell to the government."  In other words - none.
Moreover, what vendor sponsored committee member is going to
propose something for a standard that would make their
employer not be able to sell to the federal government?
Again, none.

I have given the NIST an opportunity to rebut the comments
made above, and they are in the process of doing so.  I will
publish their comments as soon as I have them available.
However, I would guess that they will say something like
"These are just first cuts.  In the future we will modify
the FIPS to conform to standards produced by standards
making bodies."  That's great, but it really doesn't help.
First, it would be a disservice to the federal user
community to force them to change from an environment in
which they have become comfortable.  Second, it is a mistake
to assume that the vendors are going to want to conform to
one standard for a while, and then change over later.  If
there is a standard that is being required by a substantial
part of the user community, then that is the one to which
vendors are going to conform.  And if vendors conform to it,
it then becomes the existing practice that must be
formalized by standards bodies like IEEE P1003.  It's a
vicious circle, and in the end the losers are the users.
They are being handed an ill-considered standard;  one that
is being foist upon them just because some small group of


                           - 3 -

people, after consulting with a handful of their (rather
unique) user community, have decided that this is the way it
is going to be.

In defense of the NIST, I know that they are not trying to
destroy the standards making process.  In reality they are
just a bunch of people trying to do their jobs the best way
they know how.  It is unfortunate that in doing so they may
end up doing more harm than good.

The Watchdog committee has no contact person with the NIST.
For further information on NIST activities you can contact
me or Roger Martin.

          Roger Martin
          National Institute of Standards and Technology
          Software Engineering Group
          Technology Blvd.
          Room B266
          Gaithersburg, MD  20899
          [e-mail]
          [phone]


Volume-Number: Volume 15, Number 38

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 4: 1003.0 and 1003.1
Message-ID: <[e-mail]>
Date: 11 Dec 88 16:40:23 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 159
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 4

              POSIX 1003.0 and 1003.1 Updates

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.0 - POSIX Guide

At this meeting of 1003.0 the group was presented with the
first working draft of the guide document.  Throughout the
week the committee met in both small groups and in plenary
sessions to expand on the first draft and start nailing down
the exact focus of the project.  In particular the group
concentrated on the issues that had been raised and entered
in the Issues Log, the overall objectives and the scope of
the document.  The purpose of the discussions was in part to
clarify the strategic goals of the committee, and in part to
prioritize those items that have already been decided upon.

Each small group that met worked on a particular area of the
draft, expanding on its contents.  As the full working group
could not decide on the level of detail that should be
included in each section, it was left up to each small group
and revisited later.  Topics that are being covered include:
The Benefits of Open Systems, Key Open Systems Areas.

The Watchdog contact for 1003.0 is Kevin Lewis.  He can be
reached at:

          Kevin Lewis
          DEC
          1331 Pennsylvania Avenue NW
          Suite 645
          Washington, DC  20004
          [e-mail]
          [phone]

1003.1 - System Services Interface

The big news from this meeting of the 1003.1 working group
is that its Chair, Jim Isaak, has resigned after 5 years of
work.  Jim is also Chair of 1003, the convenor of the ISO

__________

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


                           - 2 -

work item on POSIX, and a pacel of other things;
consequently he felt that he could no longer contribute the
amount of time to 1003.1 that is really necessary for a
working group chair.  I would like to take this opportunity
to thank Jim for all of the effort he put in to making the
first POSIX standard a reality.  We are fortunate that there
are people like him in the industry.

The new chair of the committee is Donn Terry.  Donn has been
co-chair for a couple of years now, and has been the real
chair (if not in name, then in actions) since the standard
went to ballot in November of 1987.  He is one of the
original members of 1003.1, and is also the chair of the US
Technical Advisory Group on POSIX to ANSI.  Donn coordinated
the last two rounds of balloting on the 1003.1 standard, and
did an excellent job.  I'm confident that he will prove to
be as able a chair as Mr. Isaak.

Almost as important is that the standard is now available in
print.  The bound version of the standard, while almost
unreadable because of IEEE enforced formatting changes, and
hard on the eyes because of its ugly split-pea-green cover,
is now available for $16 (members) or $32 (non-members) from
the IEEE office in New Jersey.  For a copy, please contact:

          IEEE Service Center
          445 Hoes Ln.
          Piscataway, NJ 08854
          [phone]

After electing the new chair, the working group got down to
business.  They continued their work on extending the first
POSIX standard, IEEE Std 1003.1-1988.  Their primary areas
of focus are now a new archive format, a functional
interface for terminal interaction, and cleanup of the first
standard.  In addition the group starting forming a sub
group to be the interpretations committee for the released
standard.  Each standard must have a "supreme court" of
sorts.  Users of the standard may submit formal questions to
the IEEE, and those questions will in turn be conveyed to
the interpretations committee.  It is up to this committee
to figure out the answers to the questions, and then to
modify the standard if necessary so that in future printings
the question doesn't come up.  More about this as it
develops.

One issue of great import is internationalization of the
standard.  The international community has some concerns,
particularly in the areas of character sets and the use of
the words "byte" and "character".  These concerns were in
particular voiced by the Japanese representatives at the


                           - 3 -

October meeting of WG15 in Tokyo.  The committee tried to be
very careful when drafting the standard, but apparently not
everything was covered.  In any event, the working group now
has to write an appendix to the standard which specifies the
intent of the group regarding international implementations
of POSIX.  The standard is not really an implementors guide,
but the appendix should provide a better guide to the intent
of the group.  Hopefully this appendix will be enough to
keep the international community at bay long enough for the
standard to be ratified as an ISO Draft International
Standard (DIS).

On a related note, the ISO Working Group for POSIX (ISO/IEC
JTC1/Sc22/WG15) has recommended that DP 9945 (the draft
proposed international standard POSIX) be elevated to a DIS.
This means that the standard has to go through another
(international) balloting period before it can be a real
international standard.  Personally, I don't anticipate any
trouble.

The 1003.1 committee hopes to ballot a revised version of
the standard within two years.  This revised version would
contain a new archive format, some additional functions
there were left out of the original, but are now felt to be
necessary, and any clarifications that have come from the
interpretations committee.  In addition all of the
interfaces in the standard will be described in a way that
is programming language independent, and there will be a
chapter that has the C language binding to this language
independent description.  It sounds like a big job, but the
committee is optimistic.  It is also small enough now that
it might just get it done in that time frame.

I am the Watchdog committee contact for 1003.1:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          [phone]
          [e-mail]
          uunet!bungia.mn.org!ahby


Volume-Number: Volume 15, Number 40

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 5: IEEE 1003.2
Message-ID: <[e-mail]>
Date: 11 Dec 88 16:44:10 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 223
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 5

                    POSIX 1003.2 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.2 - Shell and Tools Interface

This working group never ceases to impress me.  In September
the group was given about three weeks to go over draft 7 of
the standard and review it as if it were a formal ballot.
This means that problems discovered in the draft must be
reported to the committee using the formal POSIX balloting
format, within the specified time limits, in order to be
considered.  A surprising number of people were able to work
very hard and come up with about 1500 objections to the 600
page document.

Okay, so a lot of people, given 3 weeks, can really find a
lot of problems with a somewhat immature document.  Maybe
not terribly impressive.  Then a group of 40 people meet in
Hawaii, not a place known to be conducive to work, and
manage to review every single objection and resolve them!
This is truly amazing, and I think everyone at that meeting
(including myself) deserves a medal.  Moreover, I would like
to take this opportunity to publicly eat the words I wrote
last quarter.  They may just pull it off!  The draft that
goes out for balloting in the formal IEEE process is
certainly in much better shape than the 1003.1 document was
when it first went out.  Also, P1003 learned a lot from the
.1 ballot, and that knowledge should help make the balloting
of .2 smoother.

Reaching back a bit for a transition, there were 1500
objections.  That is really quite a few, but its not as bad
as it sounds (unless you had to carry them around for a
week).  It is true that many changes were made to the
standard, and I couldn't tell you what most of them were.
What I can tell you is that they were primarily
inconsequential.  Some objections requested changes in
functionality or interface, pointing out existing or new
practice that should be standardized.  But all of the rest

__________

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


                           - 2 -

can be broken down to spelling or grammatical corrections,
requests for clarification, or questions about the necessity
of specifications or lack of same.  Some specific changes of
interest were:

   o+ Based on a decision from the previous meeting and
     several balloting objections, the fgrep and egrep
     commands have been removed from the standard, and the
     functionality that they provide is being encompassed in
     the definition of grep.  This new grep will have
     options -E and -F which will give it the exact
     functionality of egrep or fgrep, respectively.

   o+ The draft has a command in it called colldef.  Colldef
     allows the portable definition of collating sequences,
     which can then be used by utilities that do string
     comparisons with the C Standard function strcoll.  The
     theory goes that an implementation will provide
     applications with a means for creating collation
     sequence definitions (colldef), and then also allow the
     application to specify which collation sequence to use
     when calling utilities like sort (through the
     environment variable LC_COLLATE).

     It all sounds pretty good, but the definition of
     colldef was so incomplete and confusing that some
     balloters suggested it be removed from the standard
     altogether.  The definition of this utility now
     provides for a lot of additional functionality, and is
     much clearer than it used to be. While this part of the
     standard is not talked about much, I believe that it is
     probably the most important part.  The international
     aspects of POSIX are sort of obscure, but they will
     allow for more portable applications, and also allow
     for some previously unheard of uses for utilities like
     sort.

   o+ A closely related utility, xform, was placed in the
     standard to allow for the transformation of strings by
     a shell script just as can be done using the strxfrm
     function in Standard C.  After much discussion in the
     small group, this command was removed from the draft.
     While there was some dissenting opinion, the majority
     thought that this would have very limited usefulness to
     a portable shell application.  As I was the dissenter,
     I can say that I wanted it in because there is no other
     way to portably compare strings in the shell from an
     international perspective.  If a user enters something
     and then later you want them to enter it again, you
     cannot portably compare those strings without the xform
     utility.  Alas, you win some...


                           - 3 -

   o+ An interesting development was the decision that the C
     language functions in the standard be moved into a
     chapter for C Language interfaces, and that their
     original position in the document be reserved for the
     language independent descriptions of some of the
     functions.  In the end it may be that some of the
     functions are really not ones that need to exist in
     other languages, and as such should not be in the
     language independent section.  This event is
     interesting because it shows the intent of this working
     group, and indeed all of the POSIX working groups, to
     describe their standards in a language independent
     manner.  This was a requirement of the international
     community, and I am glad to see that it is being
     carried out.

   o+ In what I consider a victory for the users of the
     world, the UUCP style commands in the standard have
     been moved out of the document and into an appendix.
     These commands, uuxqt and uuname, have been in the
     standard for about a year, but no one could really
     figure out why.  As described there was no underlying
     transport mechanism or protocol defined, so they could
     not possibly have been reliable in any event.  They
     were placed in the standard as a spear; something that
     you could throw out and have no idea if it worked or
     not.  The working group has now realized that this is
     not really a service to the application developer, and
     has moved the commands (and concepts) into an appendix.
     Depending on the feeling of the balloting group, these
     commands will either be fleshed out into a full
     definition of the UUCP "networking" system, or removed
     from the standard altogether.  It may be that these
     concepts will fit into the P1003.8 standard on
     networking, but I doubt it.  While it is probably the
     most widely used form of electronic networking on UNIX
     systems, it is not really something that should be
     carried into the future.

   o+ While the UUCP commands are gone, the message sending
     command sendto is still in the standard.  This command
     allows an application to send text to an address with
     an implementation defined format to be deposited in an
     implementation defined location and delivered in an
     implementation defined manner.  No kidding.  That's
     what it says.  It also used to say sendto -r would try
     to read from your personal implementation defined
     storage location, but that it might not do anything.
     Fortunately, the working group couldn't figure out a
     single reason why a portable application would want to
     read mail.  While this is usually not enough cause to


                           - 4 -

     remove something from a standard, when coupled with the
     danger that it might not do anything if executed, the
     evidence seemed to lean toward removal.  This option
     has been axed.

   o+ There is now a section of the standard on application
     installation.  Actually, there has always been a
     section for that, but until now it has been full of
     stuff that wasn't really worth reading.  The new
     definition is a little bit complex, but it seems to be
     fine.  It allows for an application, on installation,
     to determine what system resources are available, and
     to then sort of dynamically inform itself about them.
     There is also a system resource database, and all sorts
     of other neat stuff.  I don't have a handle on all of
     it yet, so stay tuned.  If I decide I hate it, I will
     be sure to let you know.

There were all sorts of other changes made to the draft, but
they are primarily editorial, and are of course all subject
to review by the balloting group.

The schedule for balloting goes something like this:
Assuming the document gets to the balloting group in mid-
january, the period will close in mid-february.  Then all of
the received objections will have to be resolved or
commented on, and it will be recirculated.  This may happen
several times before the document is finalized.  Since each
recirculation/resolution period takes 3 to 4 months, it
could be early 1990 before we see a ratified standard.

In the mean time, since the working group doesn't have
anything to do with a standard while it is going through
balloting, work will progress on the new User Portability
Extensions supplement.  The idea here is that a supplement
to 1003.2 will be released soon after the initial standard.
This supplement will describe the traditional UNIX utilities
that have user interfaces (e.g. vi).  Note that the
utilities to be described are the traditional ones, and have
nothing to do with windowing/mouse interfaces.  Work on that
topic is progressing in other areas.

I am the Watchdog committee contact for 1003.2:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          [phone]
          [e-mail]
          uunet!bungia.mn.org!ahby


Volume-Number: Volume 15, Number 41

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 6: IEEE 1003.4
Message-ID: <[e-mail]>
Date: 11 Dec 88 16:46:40 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 68
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 6

                    POSIX 1003.4 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.4 - Real Time Extensions to POSIX

In the past I have written some things about this committee
that were pretty critical.  I saw them as progressing too
slowly to have the impact I hoped they would have.  I know
that nothing I wrote or said motivated them, but I am now
happy to report the following:  1003.4 is almost ready to go
to mock ballot!  Apparently it all came together in the last
couple of months, and they are now ready to ask a wider
group for an opinion.  They plan, at the January meeting, to
go through all of their working papers and appendices,
integrate them into the draft, and them submit it for a mock
ballot before the April meeting.  The results of the trial
ballot will tell them how much more work they need to do
before going to formal ballot.  If all goes well, they
should be able to ballot after the July, 1989 meeting.
Given the way ballots tend to go, that would mean a
completed standard in early to mid 1990.  This is
particularly exciting since previously dates in 1991 had
been bandied about.  Getting this standard out a full year
earlier is astounding.

Many people are probably curious as to what is contained in
a Real Time standard.  Well, many things that didn't make it
into 1003.1, for starters.  Here is a partial list:
Asynchronous I/O, Shared Memory, IPC, Asynchronous Event
Notification, Process Memory Locking, Timers, Priority
Scheduling, Semaphores, Synchronous I/O, and Realtime Files

Some of these are going to be particularly contentious.  In
particular Events and Memory Locking could be a problem.
The mock balloting should flush out these issues so it can
be cleaned up before formal balloting in the fall.

The Watchdog committee contact for 1003.4 is Sol Kavy:  He
can be reached at:

__________

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


                           - 2 -

          Sol Kavy
          Hewlett-Packard
          19477 Pruneridge
          Cupertino, CA  95014
          [e-mail]
          hpda!sol
          [phone]


Volume-Number: Volume 15, Number 42

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 7: IEEE 1003.5
Message-ID: <[e-mail]>
Date: 12 Dec 88 08:00:11 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 147
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 7

                    POSIX 1003.5 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.5 - Ada Language Binding

This group is interesting.  They have now distributed draft
1 of their standard to the working group, but they are very
close to finishing.

The primary goal of the P1003.5 working group is to produce
an Ada language binding for the operating system services
interface defined by the P1003.1 standard.  This work has
progressed to the stage of circulating draft chapters within
the group.  These chapters are to be reviewed at the next .5
meeting (in January).

The last .5 meeting was 7-9 September 1988 in Minneapolis,
Minnesota.  One of the issues discussed there was improving
coordination with the rest of P1003.  The last two P1003
meetings conflicted with major Ada meetings, so that .5
chose to meet separately.  This has not been good for
communication.  Fortunately, there are no major conflicts
with the Fort Lauderdale meeting, and we will attempt to
synchronize future meetings with the rest of the P1003
working groups.

Major issues which were discussed at the September meeting
included: (1) the relationship of Ada I/O and POSIX I/O, and
how this relates to P1003.0; (2) (missing) support for Ada
in the P1003.2 standard; (3) real-time features required by
Ada, and whether P1003.4 will provide these; (4) changes to
.1 between draft 12 and the final version that will require
changes to the .5 draft chapters; (5) the relationship of
Ada tasks to POSIX processes; (6) whether the organization
of the P1003.5 document should mirror the .1 document.

One of the central problems they face is reconciling the
relationship between Ada tasks and POSIX processes.  Unlike
POSIX processes, Ada tasks share a common logical address

__________

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


                           - 2 -

space.  If they map Ada tasks onto distinct POSIX processes,
they need a way to share memory and file handles (opened
after fork) between processes, which is not provided in .1.
(Support for shared memory is on the .4 agenda, but the
final form remains uncertain.)  Moreover, there are
applications of Ada tasks that require task switching,
creation, and termination to be performed much faster than
may be possible for POSIX processes.

On the other hand, we might implement tasks as multiple
threads of control within a process, but then they run into
other problems.  Unfortunately, multiple threads of control
within a process cannot be supported well without some
cooperation from the OS.  For example, a blocking system
call by one thread should not block other threads.  For
another example, what happens when one task is in the middle
of a system call and another one forks?  (For now, P1003.5
agreed that Fork/Exec should be allowed, but that their
effects in a multitasking Ada program are implementation
dependent.)

The concept of POSIX support for "light-weight processes" is
appealing.  The group will explore the applicability of such
a solution.  In order to broaden the base of interest, we
have agreed to sponsor a "Birds of a Feather" discussion on
this issue at the Ft.  Lauderdale meeting.

Another major problem is reconciling POSIX signals with Ada
semantics.  The .5 group has done some preliminary work on
this.  The concept most closely corresponds to an
asynchronous Ada exception, but this construct is of
questionable legality.  The legal Ada mechanism appears to
be entry calls, but this presents other problems.  Much work
remains.

A third problem area is data representation, and character
sets in particular.  POSIX already has problems with
international character sets, arising from special uses of
certain glyphs, and from an implicit assumption that
characters are represented as bytes.  Ada makes this worse,
since it specifies a very specific standard character set
(ASCII).  The .5 group proposes to recognize POSIX
characters (and strings) as distinct from the Ada versions,
and to provide transfer functions for situations where one
must be converted to the other.

Due to a comflict with the ACM Tri-Ada conference, 1003.5
was not able to meet with the rest of the POSIX committees
in Hawaii.  However, several individual members volunteered
to attend as liaison with the other groups.  This will
probably turn out to have been very helpful in resolving


                           - 3 -

some questions about division of responsibility.  The
Watchdog Committee contact met with both 1003.1 and 1003.4
during the week.

It became clear during the 1003.1 meeting that but should
move ahead boldly to create a true Ada interface.  Further,
it appeared that due to Ada's strong typing requirements
(required by ISO) than the present .1 standard, and might
well influence the form of the future .1.

Meetings with the .4 revealed that support for Ada's real-
time requirements might be provided by that group, but not
necessarily in a suitable form or soon enough.  In
particular, the subject of lightweight processes, which
might be used to implement Ada tasks, is not on the .4
agenda.  This leaves the subject open to be addressed by .5.

These, and observations by other .5 members serving as
liaisons are likely to influence the direction of work when
the group next gets together.

The Watchdog committee contact for 1003.5 is Ted Baker.  He
can be reached at:

          Ted Baker
          Department of Computer Science
          Florida State University
          Tallahassee, FL 32306
          [phone]
          [e-mail]
          [e-mail]


Volume-Number: Volume 15, Number 43

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 8: IEEE 1003.7 (system administration)
Message-ID: <[e-mail]>
Date: 12 Dec 88 08:02:10 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 84
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


      An update on UNIX|= Standards Activities - Part 8

                    POSIX 1003.7 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.7 - System Administration

This new working group met as a Birds of a Feather session
during the Hawaii meeting.  During that session the group
convenor outlined the goals and solicited input from the
attendees.  At a subsequent meeting in Monterey (in
conjunction with the Usenix Large System Administration
Workshop) the group took the input from that meeting and the
work that had been going on off line and began producing a
draft document.

So, what is the purpose of this body?  To define a portable
user interface for System Administration Utilities which
would allow users to administer systems in a portable way,
and allow developers to build system administration tools on
top of consistent underlying commands and libraries.  Since
the work of this body will overlap with almost every other
P1003 working group (and possibly other groups outside of
POSIX), coordination is a major part of the standard
development effort.  Also, because the charter of this group
is so broad (what is an administrative tool, anyway?), it is
going to take quite a while to complete the standard.

Just to give you a rough idea of what is going to covered by
this group, here are some possible areas:  machine startup,
process management, network, software licensing management,
user management, password management, etc...  At the meeting
in Hawaii it quickly became apparent that the scope of this
group is too large to accomplish anything in a reasonable
period of time.  Some of the time at the Monterey meeting
was spent narrowing the scope of the group to a more
manageable size.  The group tried to identify items which
could form a basic set of libraries and commands, and could
be finalized in a two to three year time frame.  After the
initial standard is released, there may be continuing work
into areas that the first cut was not able to address.

__________

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


                           - 2 -

When I last wrote about this group, I was very critical of
its charter and the possibility of it succeeding.  I think
it only fair to relate that a number of people wrote me and
said that I was too judgemental, and that I should take a
wait and see attitude.  Bowing to the will of the people, I
am not going to draw any conclusions about the working group
at this time.  After the January meeting, when they have
formalized the areas they are going to address, I will
relate all of that information and you can decide if what
they are doing is a good thing.  In the interim, if you want
more information, or would like to share your opinions with
me, please drop me a line.

The Watchdog Committee's contact on 1003.7 is Mark Colburn.
Her can be reached at:

          Mark Colburn
          NAPS International
          117 Mackubin St.
          Suite 1
          St. Paul, MN  55102
          [phone]
          [e-mail]


Volume-Number: Volume 15, Number 44

From news  Sun Sep 11 17:45:59 1988
Path: longway!std-unix
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 9: IEEE 1003.3 (POSIX Guide)
Message-ID: <[e-mail]>
Date: 12 Dec 88 08:04:38 GMT
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Lines: 107
Approved: [e-mail] (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]



      An update on UNIX|= Standards Activities - Part 9

                    POSIX 1003.3 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.3 - Testing and Verification

This POSIX working group met along with the others in
Honolulu in October.  The agenda included a status report on
NIST activities, review of previously assigned action items,
developing a strategy for future work with other P1003
(POSIX) working groups, revision of Draft 7.1 document, and
assigning new action items.

Roger Martin (NIST* & P1003.3 Chair) gave a status report on
the current NIST FIPS** and their Conformance Testing
Policies for the POSIX FIPS.  He stated that this "Initial"
POSIX FIPS has been approved and they intend to revise the
FIPS now that the P1003.1 Standard is finalized.  The NIST
Test Suite, PCTS, has been provided to NTIS (National
Technical Information Service) for public distribution at a
price of $2500 and is being distributed since September 5,
1988.  Its distribution was awaiting FIPS approval.  Roger
Martin also presented a proposed schedule for a series of
Application Portability Workshops sponsored by NIST.  He
described a workshop that had taken place in September 1988
covering Shell & Tools, System Administration and X Windows.
One of the areas to be covered in a future Application
Portability Profile FIPS and workshop include the Terminal
Interface Extension.  The workshops are intended for
implementors and users.

The remainder of the meeting concentrated on rewriting and
restructuring the Draft 7.1 document, including test
assertions.

__________

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

  * NIST was formerly the National Bureau of Standards, NBS

 ** FIPS is Federal Information Processing Standard
    developed by NIST


                           - 2 -

During the week of meetings one small group of Test
Assertion Reviewers                   continued to update
the 1003.3 Draft 7.1 assertions.

Two other small groups concentrated on rewriting and
restructuring 1003.3 Draft 7.1 document. One group's
emphasis was the development of a 1003.3 Generic Test Method
chapters (i.e. terminology, testing levels, generic PCTS
output). The second group's emphasis was in developing
1003.1 specific Test Method sections.

The P1003.3 group is gearing up for balloting this standard
in early 1989.  Each P1003.3 member is part of the "mock"
ballot group, identifying and formulating any possible
objections.

The group defined the following ballot schedule:
11/18/88  1003.3 Draft 8.0 "MOCK" BALLOT
12/31/88  "MOCK" BALLOT CLOSED
1/9-13/89  REVIEW "MOCK" BALLOT RESULTS AT NEXT MEETING
2/15/89    1003.3 Draft 9.0 IEEE BALLOT
4/3/89     1003.3 BALLOT CLOSED

Future work of the P1003.3 committee was also addressed.
The P1003.3 Working Group wants to influence the other P1003
Working Groups into writing testable standards. To achieve
this, a liaison program will be implemented to have members
from P1003.3 working in a liaison fashion in each of the
other working groups.

The P1003.3 working group Project Authorization (PAR) will
need to be revised in order for the group to develop an
overall Test Method standard and the development of specific
standards for each appropriate 1003 activity.

The Watchdog committee contact for 1003.3 is Doris Lebovits.
She can be reached at:

          Doris Lebovits
          AT&T
          Rm 5-211
          190 River Rd,
          Summit, NJ  07901
          [e-mail]
          attunix!lebovits
          [phone]


Volume-Number: Volume 15, Number 45

From root  Mon Jan  2 01:41:23 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA09191; Mon, 2 Jan 89 01:41:23 EST
From: Shane P. McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Part 10:  IEEE 1003.6;  Security
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Shane P. McCarron <[e-mail]>
Date: 1 Jan 89 17:54:23 GMT
Apparently-To: std-unix-archive

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


     An update on UNIX|= Standards Activities - Part 10

                    POSIX 1003.6 Update

                     December 18, 1988

           Shane P. McCarron, NAPS International

1003.6 - Security Extensions to POSIX

The 1003.6 committee met with the other POSIX committees in
Hawaii.  At this meeting they decided to divide the work
into different groups.  The groups were addressing: Audit,
Definitions, P1003.6 Scope, DAC, and Privileges.

Each small working group met every day, and on the morning
of the final day of the meeting a wrap-up session was held
to update all the members of each working group's progress.
The following information was presented:

   o+ Audit

       1.  Goals:

              - Satisfy TCSEC Requirement.

              - Reduce the amount of changes to POSIX as
                much as possible.

              - Primarily to make audit trail entries.

              - Portability for audit
                administration/analysis packages/private
                applications.

              - Audit Data Interchange Format.

       2.  Areas of Investigation:

              - Definitions

              - Event/Classes (what are they?)

__________

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


                           - 2 -

              - Pre/Post Selection Criteria

              - SSO Interface

              - Subsystem Interface

              - Record/File Format

              - IDs (audit ids,...)

       3.  Future:

              - Detailed Input Requested

              - Interim Event/Classes

              - BNF for Audit Token Grammar

     Note that the administration interface issues have been
     considered to be a HANDS-OFF right now.

   o+ Definitions

     The following information was presented:

       1.  The structure of the definitions will be similar
           to 1003.1 structure: terminology section,
           conformance section, general terms, general
           concepts and acronyms.

       2.  The draft 0 definitions were based on four
           documents: ISO, ECMA, IEEE Std 1003.1-1988, and
           the Orange Book.

       3.  The GOAL of this group is to assure that 1003.6
           definitions are consistent and relevant to 1003.6
           areas without overstepping or duplicating
           existing definitions from other 1003.x groups.
           In case some of the 1003.6 definitions conflict
           with 1003.X ones, the action will be to propose a
           redefinition of the term.

   o+ P1003.6 Scope

     The proposed Scope was discussed and the conclusion was
     that it needed reworking. The area of I&A was
     considered not addressed, as well as trusted recovery
     (which the real-time people may need) and others.  In
     the draft a lot of the issues that will not be
     supported right now are marked so because of lack of
     experience or not enough technical maturity.  The


                           - 3 -

     important point is not if we have the experience or
     not, it is to be aware of areas where users want
     security, areas where the committee thinks security
     should be provided, and point them out in the Scope.
     If areas become a problem later, they can be dealt with
     at that time.

     For the next draft of the 1003.6 document, the table of
     contents will contain: Scope, Definitions, Feature
     Overview, Existing 1003.1 Functions, Existing 1003.2
     Commands, Section for Each Feature, and an Appendix.

     The Feature Overview covers a discussion, functional
     interface summary and command summary of each feature.
     Then in the feature section there will be the
     functions, commands, descriptions and security
     specifications.

     In the appendix there will be a rationale that maps to
     the document sections.

     It was remarked that all the future features such as
     Networking and System Administration should be
     annotated in an appendix as areas that will be covered
     as extensions.

   o+ Discretionary Access Controls

     This group was the one with the most activity,
     generating a lot of conflicting ideas even within
     itself.  However, they did resolve to put together
     first the Rationale section of the document and work on
     the agreeable parts, then later debate the contentious
     ones.  One of the conflicting topics was default Access
     Control Lists.  This is probably needed, but apparently
     will not be within the scope of the standard.

   o+ Privileges

     Privileges is a topic wrought with philosophy, and
     computer professionals love to be philosophers.  In
     spite of this, definitions of privilege and certain
     types of privileges were completed.  A paper from IBM
     was taken as a framework for the privilege section.
     During the meeting a few operations were identified as
     necessary, although the list is far from complete:
     getpriv, setpriv, enable/disable_priv, droppriv.

Another issue brought to the whole group was
Internationalization, and the decision was not to address it
as long as they can.  This is unfortunate, as the charter of


                           - 4 -

POSIX is to be as international as possible.  The 1003.1
committee learned the hard way that internationalization
cannot just be stapled on later.  It must be in there from
day one or it becomes extremely difficult to make it work.
In the case of security, labeling is an area in which
internationalization is a must.  If it is not placed in
there initially, it may never get in.

The upshot of all this is that the small groups produced the
guidelines for the next meeting and the topics that are
going to be covered for the near future.

This group has targeted mid-1990 for a complete draft ready
to ballot.  The Usenix Standards Watchdog Committee contact
for this group is Anna Maria de Alvare.  She can be reached
at:

          Anna Maria de Alvare
          Lawrence Livermore National Laboratories
          PO Box 808
          L-303
          Livermore, CA  94450
          [phone]
          [e-mail]
          uunet!lll-lcc.llnl.gov!annamaria


Volume-Number: Volume 15, Number 53

From root  Mon Jan  2 01:53:51 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA09938; Mon, 2 Jan 89 01:53:51 EST
From: Shane P. McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Part 11: IEEE 1003.8; Networking
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Jan 89 18:01:24 GMT
Apparently-To: std-unix-archive

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]


     An update on UNIX|= Standards Activities - Part 11

                    POSIX 1003.8 Update

                     December 18, 1988

           Shane P. McCarron, NAPS International

1003.8 - Networking Extensions to POSIX

IEEE P1003.8's charter (not yet formally approved by IEEE,
but pending) is to help develop an IEEE POSIX networking
standard.  This was the committee's first formal meeting,
and it was devoted mostly to organizational matters,
particularly on setting specific technical goals and how to
divide the work into subcommittees.

This working group has emerged out of the work done by the
/usr/group Technical Committee's subcommittee on networking.
Once this committee has been formally formed, the /usr/group
networking committee will be considered to merge with the
P1003.8 committee, and meet concurrently whenever P1003.8
does.  Ultimately, the /usr/group committee is likely to
disband completely in favor of P1003.8.

The charter ("project authorization request", or PAR) was
reviewed briefly:

                           SCOPE

  1.  Define Network Services required by portable
      applications consistent with existing and emerging
      standards such as OSI.

  2.  Define interfaces to the network services defined
      above, and where possible, language and protocol
      independent programming interfaces.

  3.  Identify the requirements for new network
      services/protocols and liason with appropriate
      standards bodies (national and international) and
      interested organizations when appropriate.

__________

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


                           - 2 -

                          PURPOSE

Define and/or adopt a set of paradigms to permit the
implementation of portable applications in a network
environment.

Areas to be addressed by this committee include:

  A.  Interoperability between POSIX applications and non-
      POSIX applications.

  B.  Bindings to OSI application layer services.

  C.  Identification of language requirements not
      appropriate to applications portability, and liason
      with appropriate standards bodies to ensure that
      action is taken where appropriate.

  D.  The evaluation and definitions, where require, of
      binding to lower layer OSI services.

  E.  The requirements to ensure interoperability among
      POSIX-based distributed applications and services.

  F.  Network Services profile definitions for portable
      applications (POSIX).

Subcommittee Organization

A poll was held to find out what the most important topics
were as far as the group was concerned.  These turned out to
be: process to process communication, directory services,
network management, transparent file access, and remote
procedure call.  Three main subcommittees were formed to
look at some of these tasks.  Roughly, these committees were
"interprocess communication", "remote procedure call", and
"transparent file access".

Directory services and network management were recognized as
important, but also as cutting across other functional
areas.  Also, it was noted that there were not in attendance
enough people with sufficient expertise in these topics to
form a useful body of opinion on proposals in these areas.

Transaction processing was generally felt to be within the
domain of the committee, but as a special case of remote
procedure call.  It was noted that others who were not on
the committee may feel otherwise.

The committee split up into subcommittees for a day to
refine the definitions of the most important end products


                           - 3 -

identified for the committee to concentrate on.

Specific Technical Goals

The following is a summary of what the committee as a whole
agreed on as a result of the input from the individual
subcommittees.

   o+ Transparent File Access

     It was decided that the products should be client-only
     interfaces.  Three products were identified:

       1.  Full POSIX-semantic transparent file access
           interface.  This would include previous
           /usr/group DFS Committee work on DFS (distributed
           file system).

       2.  Administrative interface to support (1).

       3.  Subset-semantic transparent file access
           interfaces.  This could be vendor (e.g., MS-DOS,
           Apple, etc.) or protocol (e.g., FTAM) specific.

     Work items identified so far include:

       1.  Definition of file operations

       2.  Liason to system administration; definitions of
           transparent file access specific system
           administrative utilities and/or interfaces

       3.  Liason with directory working group

       4.  "Appropriate approach" to the protocol invention
           problem

     This group expects to finish relatively quickly (6
     months or so was the estimate given), because it was
     felt that a significant amount of the work needed to
     produce standards in this area is already done by
     definition (the P1003.1 standard).

   o+ Remote Procedure Call:

     The RPC folks apparently did not define their charter
     so much as identify issues that need to be addressed.
     The following was their list of issues along with
     tentative resolutions (if any):


                           - 4 -

       1.  Level of service

       2.  POSIX-to-POSIX versus POSIX-to-other (address
           POSIX-to-other)

       3.  Language binding (initial target: C)

       4.  TP support

       5.  Connection re-use

       6.  Call-back/recursion

       7.  Compiler language

       8.  Data canonicalization

       9.  Authentication

      10.  Our scope versus X.500

      11.  Standard suite of services need to confer with
           X3T5 on possible charter issues

      12.  Idempotency - execute once only guaranteed

      13.  Long running processes - keepalive/timeouts
           probably needed

      14.  Crash recovery

      15.  Real Time issues - no real time interface

      16.  Directory services

      17.  Multiple protocol stacks

     The subgroup chose not to identify the next step in the
     process (apparently meaning that they will wait for
     proposals).

   o+ Interprocess Communication:

     Four products were identified:

       1.  Simple Protocol-Independent Network Interface

           Features:

          * Bidirectional byte stream virtual circuits


                           - 5 -

          * Connectionless message exchange

          * Read/write support

          * Protocol-independent naming

          * Asynchronous communication services

          * Support for both client and server processes

          * POSIX-to-non-POSIX support

           Issues:

          * How to resolve names in a protocol-independent
            manner?

          * What should the individual functions look like?

       2.  Simple Structured Data Network Interface

           Features:

           All of (1), with extensions for data description
           and machine-independent representation.

          * Description of the syntactic structure of the
            data; when you send the data, you reference the
            structure.

          * Not all functions from (1) may work (such as,
            read/write)

           Issues:

          * Structure alternatives: ASN.1, ...

          * C data structures (stub compilers)

       3.  Protocol-Option-Extended Network Interface

           Features:

          * Provides the ability to access protocol
            dependent options

          * Migration path to potential future protocols

          * POSIX-to-any


                           - 6 -

          * Virtual circuits, datagrams

           Issues:

          * Limited lifespan (?)

          * Limited utility

          * Usefulness as a migration tool

          * Relationship to (1)

       4.  OSI application level interface

           Features:

          * A family of interfaces with consistent style and
            syntax which provides OSI application level
            services, e.g.  FTAM, VT, ACSE, ROSE, ...

           Issues:

          * Complexity

          * Prioritization (which ones to focus on first)

     One issue that surfaced very quickly in the network IPC
     discussions was the differences and relative merits of
     sockets and XTI.  Some went as far as to say that the
     differences were significant enough to guarantee
     "religious wars" over the issue, and/or make any kind
     of progress impossible in the area of product (3).

     Whatever the cause, a majority (8/0/3/3) of
     participants expressed interest in working on product
     (1), with products (3) and (4) having a relatively weak
     level of interest.

     The committee will get down to serious business at the
     next meeting (in January; 5 days).  For the next
     meeting, proposals are being solicited in all areas.
     The Usenix Standards Watchdog Committee contact on this
     committee is Stephen Head.  He can be reached at:

               Stephen Head
               Hewlett Packard
               263 Mackintosh St.
               Fremont, CA  94539
               [phone]
               [e-mail]
               uunet!hpda!smh

Volume-Number: Volume 15, Number 54