Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!cs.utexas.edu!
longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 1: Overview
Message-ID: <268@longway.TIC.COM>
Date: 10 Dec 88 23:24:34 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 96
Approved: j...@longway.tic.com (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
(512) 320-9031
j...@longway.tic.com
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
(612) 224-9108
m...@naps.mn.org
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
+1 (612) 224-9239
a...@bungia.mn.org
uunet!bungia.mn.org!ahby
Volume-Number: Volume 15, Number 36
Path: utzoo!attcan!uunet!longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 3: NIST FIPS
Message-ID: <270@longway.TIC.COM>
Date: 11 Dec 88 01:12:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 137
Approved: j...@longway.tic.com (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
rmar...@swe.icst.nbs.gov
+1 (301) 975-3295
Volume-Number: Volume 15, Number 38
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!cs.utexas.edu!longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 4: 1003.0 and 1003.1
Message-ID: <272@longway.TIC.COM>
Date: 11 Dec 88 16:40:23 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 159
Approved: j...@longway.tic.com (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
kle...@gucci.dec.com
+1 (202) 383-5633
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
+1-201-981-0060
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
+1 (612) 224-9239
a...@bungia.mn.org
uunet!bungia.mn.org!ahby
Volume-Number: Volume 15, Number 40
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!cs.utexas.edu!longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 5: IEEE 1003.2
Message-ID: <273@longway.TIC.COM>
Date: 11 Dec 88 16:44:10 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 223
Approved: j...@longway.tic.com (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
+1 (612) 224-9239
a...@bungia.mn.org
uunet!bungia.mn.org!ahby
Volume-Number: Volume 15, Number 41
Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!cs.utexas.edu!
longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 6: IEEE 1003.4
Message-ID: <274@longway.TIC.COM>
Date: 11 Dec 88 16:46:40 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 68
Approved: j...@longway.tic.com (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
s...@hpda.hp.com
hpda!sol
+1 (408) 477-6395
Volume-Number: Volume 15, Number 42
Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!cs.utexas.edu!
longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 7: IEEE 1003.5
Message-ID: <275@longway.TIC.COM>
Date: 12 Dec 88 08:00:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 147
Approved: j...@longway.tic.com (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
+1 904 644-5452
tba...@ajpo.sei.cmu.edu
b...@nu.cs.fsu.edu
Volume-Number: Volume 15, Number 43
Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!cs.utexas.edu!
longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 8: IEEE 1003.7 (system administration)
Message-ID: <276@longway.TIC.COM>
Date: 12 Dec 88 08:02:10 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 84
Approved: j...@longway.tic.com (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
(612) 224-9108
m...@naps.mn.org
Volume-Number: Volume 15, Number 44
Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!cs.utexas.edu!
longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 9: IEEE 1003.3 (POSIX Guide)
Message-ID: <277@longway.TIC.COM>
Date: 12 Dec 88 08:04:38 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron < a...@bungia.bungia.mn.org>
Lines: 107
Approved: j...@longway.tic.com (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
lebov...@attunix.att.com
attunix!lebovits
+1 (201) 522-6586
Volume-Number: Volume 15, Number 45
Path: utzoo!attcan!uunet!longway!std-unix
From: a...@bungia.bungia.mn.org (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 11: IEEE 1003.8; Networking
Message-ID: <287@longway.TIC.COM>
Date: 1 Jan 89 18:01:24 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: std-u...@uunet.uu.net
Lines: 324
Approved: j...@longway.tic.com (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 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
+1 (408) 447-2740
s...@hpda.hp.com
uunet!hpda!smh
Volume-Number: Volume 15, Number 54
|