domo@tsa.co.uk (Dominic Dunlop) (11/14/90)
Submitted-by: domo@tsa.co.uk (Dominic Dunlop)
Report on ISO/IEC JTC1/SC22/WG15 (POSIX)
Meeting of 23rd - 26th October, 1990
Orcas Island, Washington, U.S.A.
Dominic Dunlop -- domo@tsa.co.uk
The Standard Answer Ltd.
Introduction
Are you a regular reader? I hope so, as this report on the
October meeting of Joint Technical Committee 1, Subcommittee
22, Working Group 15, colloquially known as the ISO POSIX
working group, seems to be particularly replete with
buzzwords, acronyms and jargon. I try to explain these as I
encounter them, but since USENIX and EurOpen (formerly EUUG)
have been sponsoring me to produce these reports for almost
two years now, some of the explanations are buried in
previous editions. For now, you will just have to bear with
me; I will take time to explain how we arrived at the
current state of affairs in a future column. This one
concerns itself mainly with where we are headed, and with
the difficulty of actually getting there.
As far as ISO is concerned, POSIX, like Gaul, is divided
into three parts. Forget all those proliferating IEEE 1003
POSIX working groups (eighteen of them at the last count),
and just think of three standards: IS 9945-1 for a
definition of the services offered by the operating system;
IS 9945-2 describing the shell and tools; and IS 9945-3,
system administration.
The good news is that you can now buy the first edition of
the first of these1. The bad news is that all three ISO
standards projects are running into scheduling difficulties.
And there is even more bad news if you are an AdaTM fan: in
order to ease its own difficulties, the ISO POSIX working
group has put a serious road-block between your favourite
language and an international standard defining how you may
use it to access POSIX services. Why did we do this, and
why don't we feel bad about it? Read on...
__________
1. From the IEEE, which has agreed to print the world's
first combined IEEE/ANSI/ISO standard -- on ISO standard
A4 paper. Ask for IEEE Std. 1003.1:1990. It will cost
you $52.50 if you are an IEEE member, $75.00 otherwise.
Add $5.00 for surface mail to Europe. In the U.S.A.,
call (800) 678-IEEE; elsewhere, +1 908 981 1393. IEEE
accepts "major credit cards".
- 2 -
9945-3_--_System_Administration
As you are probably aware, the IEEE P1003.7 working group on
system administration has decided that current UNIX
administrative tools and practices are sufficiently
obsolete, inadequate and diverse that they are not worth
standardizing. Instead, the group has elected to define a
new, object-based administration scheme which views a system
as a collection of objects to be administered, and a network
of systems simply as a larger collection of such objects.
Although this approach grafts neatly on to the network
administration work which has been going on in the Internet
and Open Systems Interconnection (OSI) communities, it will
be a while before it produces any results. As we shall see
in connection with 9945-2, when ISO delegates responsibility
for the development of a standard to another body, as it has
done with the POSIX standards, it likes the documents to be
in a relatively stable state before they are submitted for
use as ISO Working Documents (WDs). 1003.7 thinks that it
will have something suitable for ISO to start work on by
1992.
Unfortunately, ISO rules state that, unless a project has
resulted in a WD within three years of authorization, the
authorization stands in danger of automatic withdrawal. The
only way out is for a national standards organization
participating in the development of the standard to call for
a vote on project continuation before the time limit
expires. The time limit for the production of a draft for
9945-3 has almost been reached, with no prospect of the
deadline being met.
It seems inevitable that the twenty-four countries
participating in the ISO POSIX project will be formally
balloted as to whether they think that the authorization to
develop a system administration standard should stand,
despite the missed deadline. This is not a particularly big
deal: an examination of ISO's information technology
standardization work reveals that around twenty percent of
projects miss one deadline or another. (OSI standards have
a particularly poor track record.)
Nevertheless, it is embarrassing when the managerial finger
is pointed at one's own project. Already, the special
pleading has started; the SC22 Advisory Group, which makes
recommendations on policy issues to the ISO programming
languages subcommittee, has suggested that "in general
standards developed within SC22 are larger and more complex
than most others, and the time limits given in JTC1
directives2... will therefore often be too short."[1].
- 3 -
This may be true -- although work elsewhere in ISO suggests
that SC22 has no monopoly on large projects. However, it
seems to me that the time limits given by the directives
cannot reasonably be relaxed: if no visible progress has
been made on a project after three years, those involved had
better be given an opportunity to ask themselves why, and to
consider whether they wish to continue giving their support.
I am sure that, if it comes to a vote, the result will
favour the continuation of the system administration
project. Just don't hold your breath waiting for the final
standard.
9945-2_--_Shell_and_Tools
The shell and tools standard is not crowding a deadline as
closely as is system administration, but is not clear of
trouble either. At least we have a committee draft (CD --
one step beyond a WD), corresponding to draft 9 of 1003.2,
but have failed to move it forward to the next stage, a
Draft International Standard (DIS). According to the
directives, we have four years in which to do this before
serious questions get asked, and the ISO directorate makes a
decision about project termination. Although our progress
to date has not been rapid, we have some time in hand.
Our first attempt to register the 1003.2 draft as a DIS
failed. (See my report on WG15's Paris meeting[2].) The
problem was that, while the technical content of a DIS is
supposed to be essentially the same as that which will
appear in the recently International Standard (IS), we all
knew that the content of 1003.2 was still undergoing rapid
and sometimes radical change. There was no way that draft 9
could have been accepted as a DIS. (The U.S. National
Institute for Standards and Technology (NIST) ultimately
decided not to base a Federal Information Processing
Standard (FIPS) on draft 9 for similar reasons.)
Draft 11 (or later) of 1003.2 will be passed to ISO in
January, 1991 (or later), in the hope that it can be
registered as a revised CD, and will stand more chance of
clearing the the remaining hurdles which separate it from IS
status. Until this happens, we have a situation described
__________
2. The rule book which guides our every move is The JTC1
Directives. It is surprisingly readable, and very clear
on general principles and procedures, but seems to be
intentionally vague on many details.
- 4 -
by one normally restrained working group member as a "pure
disaster". We are about to suggest that draft 6 of 1003.2A,
the User Portability Extension, due early in 1991, is
registered as a proposed draft amendment (PDAM) to 9945-2,
without having a stable document to amend3!
In this situation, somebody may ask us why we don't just
roll the amendment into the next, hopefully more stable,
version of the CD. The practical answer to the question is
that the IEEE is treating 1003.2 and 1003.2A as two separate
documents, and we would prefer to do the same. How much
weight such an argument might carry with the ISO secretariat
is another question...
9945-1_--_Operating_System_Interface
Now that 9945-1:1990 operating system interface definition
is an international standard, international standards work
on POSIX has reached the end of its beginning. What do we
do next? The problem is that we are spoiled for choice. An
embarrassing number of the 1003 projects represent
extensions to, or restatements of, the services described in
9945-1:
1003.1A: A 1003.1 extension draft, covering tweaks such
as symbolic links, will be ready for us early in
1991. We shall probably vote to register it at
our next meeting.
1003.1LI: (Provisional name.) This is the language-
independent specification of the services defined
by the current 1003.1 standard in terms of their
C language interface. It may be ready in late
1991, provided that enough IEEE volunteers can be
found to work on it.
1003.1C: (Provisional name.) Building on the definition
provided by 1003.1LI, these C bindings will
correspond exactly to the C interface defined by
the current 1003.1. Again, a draft may be ready
late in 1991.
__________
3. The UPE to 1003.2 describes interactive utilities for
program development, supplementing 1003.2's description
of the non-interactive tools used in shell scripts.
- 5 -
1003.2: The shell and tools standard defines C language
interfaces to regular expression handling,
filename expansion, argument string parsing and
more. Arguably, these belong in 9945-1. They
are also candidates for language-independent
specification.
1003.4: We have requested that the current draft of
1003.44, real-time extensions to the portable
operating system interface, is registered as a
PDAM to 9945-1. The first international POSIX
standard has only just hit the streets, and
already we are trying to amend it!
1003.4A: The 1003.4 working group considers that draft 5
of its threads (lightweight process) standard
will be ready for submission to ISO at the same
time as 1003.4. As yet, we have made no decision
to accept it.
1003.4B: This is simply a language-independent
specification for the services described by
1003.4 in terms of their binding to the C
language. The IEEE working group does not know
when it will be ready, and we don't yet know when
we shall be ready to accept it. The two issues
are connected: if we say we want work on it to be
accelerated, it is likely to be ready more
quickly.
1003.5: The Ada description of the portable operating
systems interface is well on its way to becoming
an ANSI/IEEE standard. Expect to see it in 1992.
Sadly, for reasons explored below, 1003.5 is
unsuitable as a basis for an ISO standard.
1003.6: The security extension to the operating system
interface will be ready for us to have a look at
in January of 1991, although it will be a while
before it is mature enough for PDAM registration.
__________
4. That is, the draft current at the time that the ISO
secretariat requests ANSI to provide a document for
circulation to SC22 and WG15 as a prelude to calling a
vote on registration. This will be draft 10, or, more
probably, draft 11.
- 6 -
1003.8: Transparent file access, that is, transparent
access by a process hosted on one system to files
held by another, is making rapid progress after
narrowing down its goals until it identified an
achievable target. The IEEE working group
expects to have a document suitable for ISO
review by mid-1991.
1003.9: The FORTRAN5 bindings to the operating system
interface definition are written in a manner
which is more to ISO's taste than the Ada
description of the same services, and will be
ready for ISO review in late 1990. However, we
have elected not bring it forward to
international standards status in the near
future. Again, our reasons are explored below.
1003.16: This recently-authorised IEEE project aims to
produce C language bindings to some future
language-independent specification of the POSIX
operating system interface. Like Ada and
FORTRAN, it is tied up with the whole issue of
language independence.
I wrote last time about the background to the language
independence debate[2]. Further discussion and a useful
bibliography can be found in [3]. ISO strongly favours
language-independent service specifications, but very few
people in the U.S. are interested in writing them. ISO has
delegated development responsibility for POSIX to ANSI,
which in turn has passed the buck to the IEEE -- an
organization which ISO cannot officially talk to or aid. As
a result, IEEE is saddled with a problem which it is ill-
equipped to solve.
At our Paris meeting, we signalled our disappointment with
the IEEE's progress towards a language-independent
specification for POSIX by refusing to register drafts of
1003.4, .5 and .9. The list above shows that we have
relented on 1003.4, but have left .5 and .9 out in the cold.
__________
5. Obscure style note: one is supposed to refer to the
proposed 1990 version of the language as Fortran; to
older versions as FORTRAN. 1003.9 is a binding to
FORTRAN 77.
- 7 -
The difference between this meeting and the last is that
they are now definitively out in the cold, and will not be
let into the ISO process until we are very close to having a
language-independent version of IS 9945-1 for them to bind
to. Here, with a few interpolations in square brackets, is
the resolution that says why:
Language-Independent Specifications:
Whereas, SC22 AG [the advisory group mentioned above in
connection with 9945-2] has recommended that the
production of language-independent specifications and
language bindings for POSIX be carried out in such a
way that it does not delay the standardization of the C
language bindings[1] [Thank you. That's just what most
of us wanted to hear.]; and
The production of a language-independent specification
corresponding to IS 9945-1:1990 and subsequent C
language-based amendments, together with a C language
binding to that language-independent specification, is
required by the Division of Work Item JTC 1.22.21 [A
Division of Work Item is an ISO mechanism for splitting
an authorised project into several sub-projects]; and
The production of further language bindings to the
language-independent specification corresponding to
9945-1:1990 as subsequently amended is ultimately
desirable; and
WG15 considers that "thin" language bindings (which
must be read in conjunction with a service definition)
are suitable candidates for standardization, but
"thick" bindings (those which incorporate a service
definition duplicating and possibly conflicting with
the service definition provided by another standard)
are not [The terms "thin" and "thick" derive from the
number of pages in the document in question. 1003.5 is
a "thick" binding, so we do not like it much; 1003.9 is
a "thin" binding, but to the C language specifications
of the current 1003.1];
Therefore, JTC1/SC22/WG15 requests the U.S. member body
[ANSI, which in turn gets the IEEE to do the work] to
provide a schedule for the delivery to WG15 and SC22 of
9945-1-related documents which is subject to the
following constraints (listed in order of precedence,
highest first):
1. The incorporation or development of language
independence features shall not be on the
- 8 -
critical path(s) for the production of C
language-based documents;
2. The ultimate goal is the production of an
extended [extended, that is, by 1003.4, 1003.6,
1003,8...], language-independent 9945-1 and
accompanying "thin" binding to the C language at
the earliest possible date;
3. Every attempt shall be made to observe JTC1/ISO
rules on the bringing forward of amendments etc.,
with the need to seek waivers being highlighted
if this appears necessary in order to satisfy the
constraints above;
4. Language bindings, other than those for the C
language, shall not be brought forward to WG15 or
SC22 for any purpose other than review and
comment before the language-independent 9945-1
has been registered as a DIS; and
5. Where possible in the light of other constraints,
C language-based documents shall include a
informative annex setting out a language-
independent definition of the services defined by
the normative body of the document;
The schedule shall identify timeframes for at least the
following document circulation and registration
milestones:
1. "Thick" C bindings for amendments to 9945-1:1990;
2. Language-independent specifications corresponding
to 9945-1:1990 and subsequent amendments;
3. "Thin" C bindings to language-independent
specifications corresponding to 9945-1:1990 and
subsequent amendments;
4. A combined language-independent 9945-1 and
accompanying "thin" C binding to the services
that it defines; and
5. "Thin" bindings for further languages to the
whole of the combined language-independent
9945-1, or to supersets or subsets of the
services which it defines.
I hope that your eyes have not glazed over: public
statements of policy get convoluted and legalistic at this
- 9 -
level, but all of this verbiage actually represents a
concise description of the problem and what we see as a
route to its solution6. For the first time, this tells the
IEEE exactly what type of document that the ISO working
group wants to see, and in which order:
a. C-based standards first.
b. Language-independent standards with a corresponding
"thin" C binding second.
c. "Thin" (and only thin) bindings to other languages no
sooner than b).
d. Examples of language-independent specifications (as
opposed to definitive standards for them) any time
that IEEE can manage to produce them.
e. All in accordance with ISO rules on the publication of
amendments and revisions to standards (we hope).
There was some understandable objection from the U.S. to
"micro-management" -- if we were defining so many goals,
constraints and checkpoints, why didn't we just write the
schedule ourselves? The answer is that there is still quite
a lot of flexibility allowed: the IEEE has a dozen or more
documents to bring forward, and it can decide on the
ordering. And the dates. We just want to know when those
dates are, and to disallow certain orderings.
The amount of resource that the IEEE can muster to work on
language-independent specifications determines when step b
can occur. Does anybody want to volunteer to make it sooner
than 1995?
The real victim of our newly-defined policy is Ada. It is
clear that that there will be an ANSI/IEEE standard for an
Ada definition of the POSIX operating system interface,
probably within two years. It is now equally clear that,
because it will be a "thick" binding, this standard cannot
move forward to gain international status. There may
ultimately be a "thin" Ada binding to a future language-
independent 9945-1. It may or, more likely, may not define
an interface identical to that defined by 1003.9. We could
face the unpalatable prospect of an ISO standard which
__________
6. Although I could be biased: I drafted the resolution.
- 10 -
differs from the corresponding ANSI standard.
Why don't we feel too bad about this? Well, it seems that
the main requirement for an Ada POSIX standard comes from
within the U.S. 1003.5 will fill this need, and we should
not seek to delay it. The need for an international
standard in this area is less clear, but we have now given
clear guidelines on the form that it should take, just as
soon as anybody wants to develop it.
That said, it is clear that we still have much to learn
about...
Co-ordination
One aim of the IEEE and ISO POSIX projects is that the
international standards that result should be identical to
the corresponding U.S. standards. Another is that ISO
publication should not lag behind IEEE publication by too
long. IS 9945-1 is a benchmark in both cases: by dint of
the IEEE agreeing to print for both organizations, content
is identical, and publication is simultaneous. This will be
a hard act to follow, not least because there are thousands
of pages of IEEE drafts in the pipeline, all of which must
undergo international review before they can even start
going through the three-stage ISO mill which grinds
documents into international standards.
It has been the policy of the IEEE not to submit documents
to ISO until they reach their first IEEE ballots -- that is,
until they are reasonably mature and complete. In view of
our rejection of 1003.2 draft 9 because we did not consider
it mature enough, this seems like a prudent approach. The
trouble is that by the time the IEEE considers a document
mature, it is also likely to be difficult to change in any
significant manner. If we had earlier visibility into the
subject matter and approach of the IEEE's work, we could
comment on its future acceptability to ISO. For example, we
could have suggested that 1003.5 pursued a "thin", rather
than a "thick" binding.
To try and get out of the hole that we have dug for
ourselves, we have requested "early visibility" of IEEE
draft standards. Seeing standards when they are young and
small will also aid international understanding of the
larger, more mature versions when they appear.
- 11 -
OSCRL
The POSIX project bears a growing similarity to an ancient
yet still inhabited castle: some parts are old and
crumbling; others require constant repair if they are to
remain habitable; and, all the time, new walls, doors and
towers are being added. 1003.7 even seems to be demolishing
a few unsightly outbuildings. Co-ordination should ensure
that nobody builds a wall where someone else wants a door.
Or a whole new tower when all that was needed was a new
entrance to an existing one, as happened in the case of
1003.5.
No castle is complete without a ghost, and POSIX has one:
OSCRL -- Operating System Command and Report Language.
Started in the early eighties, it was (to simplify to an
almost indictable extent) an attempt to define a common Job
Control Language for the large computers of the day. It
found a home in SC21, which looks after OSI, just before it
became apparent that UNIX was going to become the "open"
operating system of choice. Ahead of its time, the OSCRL
project attracted a small but enthusiastic following, but,
as the years went by, work tailed off. It was all but non-
existent by the time the ISO POSIX project was set up.
However, it is ISO policy when starting new projects to
examine any related work which it may have undertaken, and
the search turned up OSCRL as covering topics to be
addressed by 9945-2 and 9945-3.
SC21 welcomed the chance to pass the project to another
group, and we reluctantly agreed to take it over. Then the
ISO central secretariat lost all the paperwork. (It is a
fact of life that all bureaucracies lose paperwork.) We had
an excuse to prolong OSCRL's spell among the undead,
provided that we could put up with the periodic howls from
its (few) proponents.
These howls recently resulted in a polite suggestion from
the SC22 AG that we should do something to quiet them. That
something might be the massaging of the existing material
(if it can be found) in to a Technical Report -- a type of
document which few people ever read, and the production of
which is discouraged by ISO. But a TR may just be the sort
of headstone that OSCRL lacks. We will be trying to nail
the coffin lid down at our next meeting, which takes place
in the Netherlands from 14th - 17th May, 1991.
- 12 -
REFERENCES
1. Preliminary Recommendations and Resolutions, ISO/IEEE
JTC1 SC22 Advisory Group, London, October 1990.
2. Report on ISO/IEEE JTC1/SC22/WG15 (Paris), Dominic
Dunlop, comp.std.unix Volume 20, Number 110, USENET, 5
July, 1990 (also published in ;login:, Volume 15, Number
5, September/October, 1990) No. 3, Autumn 1990
3. The Context for Programming Language Independence for
POSIX, Stephen R Walli, comp.std.unix Volume 21, Number
197, USENET, 11th October, 1990
--
Dominic Dunlop
Volume-Number: Volume 22, Number 24fkittred@BBN.COM (Fletcher Kittredge) (11/16/90)
Submitted-by: fkittred@BBN.COM (Fletcher Kittredge) How can I get copies of draft versions of the POSIX 1003.x standards? I am particularly interested in the 1003.4[ab] draft. I am a member of the IEEE. regards, fletcher Fletcher E. Kittredge Senior Engineer Platforms and Tools Group BBN Software Products Company 10 Fawcett St. Cambridge, MA. 02138 617-873-3465 fkittred@bbn.com or fkittred@endor.harvard.edu Volume-Number: Volume 22, Number 25
domo@tsa.co.uk (Dominic Dunlop) (11/19/90)
Submitted-by: domo@tsa.co.uk (Dominic Dunlop) In article <14723@cs.utexas.edu> fkittred@spca.bbn.com (Fletcher Kittredge) writes: > How can I get copies of draft versions of the POSIX 1003.x standards? > I am particularly interested in the 1003.4[ab] draft. I am a member > of the IEEE. The contact for IEEE TCOS mailings is Charles Habermann NAPS International 117 Mackubin Street, Suite 6 St. Paul, MN 55102 U.S.A. +1 (612) 224-9299 (voice) +1 (612) 222-2924 (fax) cjh@bungia.mn.org I suggest that you contact him, and he should send you a form to be filled out and returned, together with payment, to the IEEE. The idea is that you pay in advance for 500 page units of mailing at $30 each. Subscribers do not have to be IEEE members. Overseas subscribers must pay an additional $400 for express delivery independent of how many or few units that they pay for. (This has always struck me as a rather strange approach -- why not just bump up the cost of each unit if express delivery is required?) The form allows one to specify the groups (1003.x, 1201,z, 1224, 1238) in which one is interested, and whether one wants to receive all paperwork or just draft standards. I am not aware of any way in which individual drafts can be obtained. I suspect that that's what Fletcher really wants. -- Dominic Dunlop Volume-Number: Volume 22, Number 27
ahby@bungia.Bungia.MN.ORG (Shane P. McCarron) (11/20/90)
Submitted-by: ahby@bungia.Bungia.MN.ORG (Shane P. McCarron) In article <14858@cs.utexas.edu> domo@tsa.co.uk writes: >Submitted-by: domo@tsa.co.uk (Dominic Dunlop) > >In article <14723@cs.utexas.edu> fkittred@spca.bbn.com (Fletcher Kittredge) >writes: >> How can I get copies of draft versions of the POSIX 1003.x standards? >> I am particularly interested in the 1003.4[ab] draft. I am a member >> of the IEEE. > >The contact for IEEE TCOS mailings is > > Charles Habermann Actually, the contact for obtaining drafts is Lisa Granoien at the IEEE Computer Society (+1 202-371-0101). NAPS does not distribute draft standards piecemeal >Subscribers do not have to be IEEE members. Overseas subscribers must >pay an additional $400 for express delivery independent of how many or >few units that they pay for. (This has always struck me as a rather >strange approach -- why not just bump up the cost of each unit if >express delivery is required?) Actually, the exact cost of overseas express delivery is debited from each subscribers "account" as materials are shipped. The $400 is a ballpark figure that IEEE uses. Here is the subscription form, in case anyone needs it. It is current: IEEE TCOS-Standards Document Distribution Service 6-20-90 INVOICE and Fee Schedule Name: ________________________________ Date: _______________________ Address:________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Phone: ________________________ E-Mail: ________________________ Master Card/Visa/AmEx #: _______________________ Expiration: _________ (circle one) Signature: ________________________________________________________ Instructions: Select the working groups from which you would like to receive information. Next select the number of pages of material you would like to pay for at this time. Group All Drafts Materials Only Status (notices, status reports, document lists) ____ n/a ALL (You will receive materials for new groups ____ ____ automatically as they are created) 1003.0 POSIX Guide ____ ____ 1003.1 System Interface ____ ____ 1003.2 Shell & Utilities ____ ____ 1003.3 Test Methods ____ ____ 1003.4 Real Time ____ ____ 1003.5 Ada Bindings ____ ____ 1003.6 POSIX Security ____ ____ 1003.7 System Admin. ____ ____ 1003.8 Transparent File Access ____ ____ 1003.9 Fortran Bindings ____ ____ 1003.10 Supercomputing ____ ____ 1003.11 Transaction Processing ____ ____ 1003.12 Protocol Independent Interfaces ____ ____ 1003.ns Name Space/Directory Services ____ ____ 1003.13 Real Time (assigned to .4) ____ ____ 1003.14 Multiprocessing AEP ____ ____ 1003.15 Batch Services (assigned to .10) ____ ____ 1201.1 Windowing Toolkit API ____ ____ 1201.2 User Interface Driveability ____ ____ 1224 X.400 Gateway API ____ ____ 1237 RPC ____ ____ 1238 Common OSI API & FTAM API ____ ____ Number of 500 pages units you wish to pay for: ____ x US$40 _______ (an average mailing of all materials is over 2000 pages) International Express Mail fee: ____ US$400 _______ (regular delivery can take up to 8 weeks) Annual TCOS-Stds meeting attendance fees may be prepaid: ____ US$400 _______ (or may be paid quarterly at the meetings) Total amount due for above services: _______ Receipt Requested? Yes No Payment: BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT. Payment may be made by charge card (above), or by check or money order payable to IEEE 1003. Please retain a copy of this form for your records. Send the materials to: For Subscriptions Send to: For inquiries about your current subscription: TCOS Standards Subscriptions Charles Habermann c/o Lisa Granoien NAPS International IEEE Computer Society 117 Mackubin St. Suite 6 1730 Massachusetts Ave. NW St. Paul, MN 55102 Washington DC 20036-1903 +1 (612) 224-9239 202-371-0101 +1 (612) 222-2924 (fax) cjh@bungia.mn.org uunet!bungia.mn.org!cjh -- Shane P. McCarron Phone: +1 612-224-9239 Project Manager Internet: ahby@bungia.mn.org Volume-Number: Volume 22, Number 28