Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.16/text0042.txt

Text File | 1989-08-11 | 17.6 KB | 411 lines

[ The following report is one in a new series about the ISO POSIX
committee that have been commissioned jointly by EUUG and USENIX.
It is intended to run in parallel with the existing series about
IEEE 1003 POSIX, for which we are still seeking a new editor
(decision probably to be made this week).  -jsq ]


        ISO JTC1 SC15 WG 22 (POSIX) MEETING, OTTAWA
                     1st-3rd May, 1989

            ``Snitch Report'' to EUUG and USENIX

                       Dominic Dunlop

                  The Standard Answer Ltd.

     This document is intended for publication
     (possibly after editing) in any forum available to
     EUUG or USENIX.

Red Flag Items

  1.  The Comite' Europe'en de Normalisation (CEN  --  European
      Committee for Standardisation) is in the process of
      voting on a proposal from West Germany that the whole
      of the X/Open Portability Guide, Third Edition, 1988
      (XPG3) should become a ``draft European Prestandard''
       --  one step away from being a European standard.
      (Conformance to European standards is almost mandatory
      for purchases made by European Community government
      organisations, and is strongly recommended in European
      Free Trade Association member governments.) This idea
      seems half-baked, not least because XPG3 covers a lot
      of ground, overlapping and conflicting with several
      existing European standards or prestandards.  Since
      X/Open is committed to alignment with international
      standards as they appear, to have CEN, an
      international body, aligning with X/Open would
      introduce an unmanageable circularity.  Consequently,
      the ISO POSIX working group has, in effect asked CEN
      to drop consideration of XPG3 in favour of the draft
      POSIX standard.

  2.  The International Standards Organisation POSIX working
      group has recommended that ISO should adopt draft IEEE
      standard 1003.2, Shell and Application Utility
      Interface for Computer Operating System Environments
      as a ``draft proposal'' in September.  Effectively,
      this means that the shell and tools have started on
      their journey to becoming an international standard.

  3.  The working group has decided not to recommend that
      ISO make an early start towards standardisation of
      ``an object-orientated language based on C''.  No
      agreement could be reached on whether such a language
      should be

         - C++ or something else (such as Objective C); and

         - Constrained to be a true superset of ANSI C or
           not so constrained.


                           - 2 -

  4.  While, for reasons of verifiability, the working group
      wants to work towards the specification of POSIX in a
      Formal Definition Language, rather than in a less
      formal language, or in any particular computer
      language, it recognises that this can only be a long-
      term goal.  Consequently, a message of comfort has
      been sent to the IEEE's 1003.1 group, encouraging it
      to continue in its work on a language-independent  --
      but not strictly formal  --  definition.  This should
      allow the IEEE to produce the first edition of the
      1003.4 Real-Time standard in a language-independent
      form.

  5.  ISO appears to be setting up a new sub-committee
      concerned with all aspects of computer security
      (including both operating systems and communications).
      The POSIX group is working to ensure that the work of
      the new group does not conflict with the security
      requirements of POSIX, as developed by IEEE 1003.6.

  6.  Following the formation of two new IEEE working groups
       --  1003.10, Supercomputing Application Environment
      Profile, and 1003.11 Transaction Processing
      Application Environment Profile, the ISO working group
      has been asked to consider its attitude to such
      profiles  --  definitions of application-specific
      variants or enhancements of an underlying POSIX-
      compliant operating system.

Introduction

This is the first of a series of reports which I shall be
making on the activities of (pause for deep breath) Working
Group 15 of Sub-Committee 22 of Technical Committee 1 of the
International Standards Organisation (ISO TC1/SC22/WG15).
It is this group which is taking the work of the Institute
of Electrical and Electronic Engineers (IEEE) on POSIX, a
portable operating system interface, from its current
official status as an American national standard to its
final goal as an international standard.  I have been
sponsored by the European UNIX systems User Group (EUUG) and
USENIX to attend the meetings of the working group on your
behalf, representing your views and reporting back on
developments which affect your interests.  In these reports,
I shall be asking for feed-back from you.  As I write, there
is no formal mechanism in place to handle this feed-back, so
you can either post comments to the newsgroup in which you
are reading this, or send mail to me directly.  My address
is [e-mail].  (Subject to change  --  check this
newsgroup for amendments).


                           - 3 -

The Structure of ISO

     Although a description of the manner in which ISO
     works could form a proper and useful part of this
     submission, I do not feel sure enough of my ground
     to include this material in my report for
     publication at this stage.  I have drafted such a
     description, and will include it in the
     accompanying private report to the executives of
     EUUG and USENIX.  While, at their discretion, the
     executives may choose to publish the material in
     this form, I should prefer that they wait until I
     can check the facts.  I anticipate that this will
     take around a month, as I have to get hold of some
     ISO papers.  When I have completed my review, I
     will forward material which I consider to be
     suitable for publication.

Meeting Report

Hosted in Ottawa by the Standards Council of Canada, May's
three-day meeting of ISO TC1/SC22/WG15 was attended by five
``technical experts'' (representatives) from the USA, three
from the UK, two from Denmark, and one each from Canada,
France, Japan and the Netherlands.  There were three
``invited experts'': myself, invited by the UK delegation to
represent the EUUG and USENIX; Shane McCarron, invited by
the USA on behalf of UNIX International; and Mike Lambert of
X/Open Company Ltd.

Mike was invited by Jim Isaak, convener of the working
group, to set out X/Open's mission and its position in
relation to ISO's activities.  It was clear that this was
necessary as, in the responses to a previous ballot on the
working group's work-in-progress, several respondents
effectively asked ``Why are we doing this?  Doesn't it
duplicate the work of X/Open?'' What is more, CEN is voting
on the adoption of XPG3 in its entirety as a ``draft
European Prestandard''  --  see Red Flag Items above.  (In
fact, there is officially no such beast as a draft European
Prestandard; there are ``Draft Standards'' and
``Prestandards''.  It seems that Prestandard is the intended
meaning.)

X/Open's position is clear: ``X/Open is not'', as the
preface to each XPG volume states, ``a standards-setting
organisation.'' Instead, X/Open is committed to align itself
with international standards as soon as these are agreed,
suggesting that its members adhere to other, less formal,
national or de-facto standards only when no international
standard is in place.  In order that national and


                           - 4 -

international standards can be arrived at in a timely
manner, X/Open fully endorses the activities of
organisations such as the IEEE, ANSI and ISO, and provides
resources to aid in their activities, as it has done  --
and continues to do  --  in the case of the IEEE's 1003
(POSIX) developments.  Consequently, the Working Group
considers that it is inappropriate for an international
standards body such as CEN to align itself with the XPG; the
XPG is not itself intended to be a formal standard, but
rather a series of moving pointers to other standards.  As
such, it performs a valuable service to industry by
indicating areas where more formal standardisation work
should take place in the future.  Each XPG pointer keeps
moving until the area it addresses has become the subject of
an agreed international standards.  It is unlikely that CEN
would tolerate such moving pointers, and would effectively
freeze the XPG in its current state.

Another problem is that XPG3 specifies C, COBOL and FORTRAN
 --  languages covered by other European Standardisation
efforts.  It also calls out communications protocols, media
formats and a graphics interface (X) which may or may not
overlap or conflict with other standards.  It is not clear
that these matters were considered before CEN moved to a
vote.

Happily, well-defined mechanisms exist for communication
between ISO and CEN, and ``maximum alignment with ... ISO
... DP9945'' is a requirement of the European Community's
``order form'' to CEN requesting that a POSIX-based European
Standard be produced.  The working group is using the
channels to suggest that DP9945, and, in the near future,
the draft IEEE 1003.2 standard, replace XPG3 in their
deliberations.

The issue of C++ standardisation was raised in the working
group, as there was a (rather vague) feeling that object-
oriented facilities were essential for future developments
in operating systems, user interfaces, communications
systems...  well, most things, really.  WG15's parent,
subcommittee 22, has responsibility for language
standardisation.  A resolution was drafted recommending that
work be started on standardisation of an object-orientated
programming language based on C.  (The bulk of any such work
would probably be farmed out to ANSI, just like the work on
C itself.) However, several valid objections resulted in the
resolution being dropped:

   - It is not clear whether the best basis for such a
     standard would be AT&T's C++, Stepstone's Objective C,
     or something else.  (The issue is known to excite
     religious fervour.)


                           - 5 -


   - It is not clear whether or not the language (whatever
     it is) should be constrained to be a superset of C.
     Such a constraint would be desirable from the point of
     view of compatibility, but might compromise the
     ideological soundness of the language.  (Religion
     again.)

   - The business of WG22 is the definition of an operating
     system interface.  It should not concern itself with
     the means of implementation of an operating system
     which presents that interface  --  even if almost
     everything that conforms to the definition happens to
     be written in on particular language  --  C.

All this may seem to be somewhat arcane  --  distanced from
reality.  What it boils down to is that WG22 does not think
that the time is yet ripe for international standardisation
of an object-oriented C derivative.  More work needs to be
done by industry groupings and national standards bodies  -
-  and more users need to vote with their feet  --  before
the terms of reference for an international standard become
clear.

The working group discussed the path towards a language-
independent definition of POSIX, an issue which took on
added urgency because the working group's decision was
required in order that the IEEE could determine the initial
format of its 1003.4 standard (real-time extensions to
1003.1), which moves to ballot in January, 1990.  Like IEEE
1003, WG15 intends that the standards it produces should
ultimately be expressed in a form which is independent of
any particular computer language.  And also like 1003, WG22
is currently drafting standards in terms of the C language.
Two questions arise: how independent, and how ultimate?

IEEE 1003.1 is working towards removing C-language
dependencies from Std. 1003.1-1988, but is stopping some way
short of using a Formal Definition Language (FDL).  While
this precludes the automatic generation of test procedures
which would be possible, were a verifiable FDL is used, it
is do-able in the short term.  Soon enough, in fact, to
allow 1003.4 to go to ballot in a language independent form.
If 1003.1 were to drop this work in favour of a FDL, results
would be postponed for some years, and 1003.4 would have to
be defined in terms of the C language, much to the distress
of the Ada community.

WG22 decided that use of a FDL was most appropriate to an
international standard.  Consequently, the group had to


                           - 6 -

decide whether it wanted

  a.  to ignore 1003.1's work (which could result in 1003.1
      dropping the activity);

  b.  to recommend that 1003.1 adopt a FDL (with a resultant
      gross delay); or

  c.  to use 1003.1's work as a basis for subsequent WG22
      progress towards a formal description of POSIX
      interfaces.

The last option was chosen, resulting in a resolution which
exhorts 1003.1 to keep up the good work.  Expect 1003.4 to
be language-independent.

For its part, WG22 is going to look into FDLs  --  a
particularly esoteric subject  --  in more detail at its
next meeting in Brussels in October.  Ultimately, its
standards will have three levels:

   - Formal description (verifiable, but almost
     incomprehensible to mere mortals);

   - Informal, but computer language-independent,
     commentary; and

   - Series of language bindings, which may or may not
     implement the whole interface.  (For example, a COBOL
     binding might well exclude the fork interface.)

This should keep us busy well into the 1990s.

ISO, in order that it can exercise adequate control of
activities dispersed both geographically and in time, tries
to compartmentalize as much as possible, making sure that
the responsibilities of each sub-committee and working group
are very well defined.  The trouble is that there are
certain topics which just cannot be pushed into a single
compartment; internationalisation is certainly one,
affecting as it does almost every aspect of information
technology; security  --  an issue which currently has many
people extremely worried  --  is probably another.  Despite
this, ISO TC1, having decided that the issue needs an
identifiable home, is thought to be about to convene a new
working group  --  probably WG27  --  to handle all aspects
of security.  (There is much vagueness here: TC1's mailing
mechanism appears to have failed, with the result that
nobody is sure exactly what will be voted on at its meeting
in Paris later this month.)


                           - 7 -

Of course, this has WG15 worried, both in its own right, and
on behalf of other groups and sub-committees affected by
issues of security.  (Most notable among these is SC18,
which manages the burgeoning ISO protocol stack.)
Consequently, a resolution has been forwarded to TC1 via
SC22 saying, in effect ``We're in this together.  Let's work
together.'' The means of working together is a rapporteur
group, a mechanism which exists to allow one group to
monitor the activities of another.  WG22 has such groups
covering verification and internationalization as well as
security.

Jim Isaak, convener of WG22, is much concerned with the
issue of functional standards for applications portability,
or Application Environment Profiles (AEPs).  Jim chairs IEEE
1003.0, which, in effect, is stocking the shelves of a
standards supermarket from which users can pick the
selection (or profile) needed to allow applications of a
particular type to be realised in a portable manner.
(X/Open, The Open Software Foundation and more than a few
governments are doing much the same sort of thing.) One
example of such a profile might satisfy the needs of
applications requiring distributed database services with
reliable transaction processing and high security.
(Continuing the supermarket analogy, these would be shopping
lists, each allowing the execution of a number of recipes
 --  applications...  Never mind.)

Already, the IEEE has working groups which are defining
AEPs: 1003.10 for supercomputing and 1003.11 for transaction
processing, and Jim is engaged in selling the idea to ISO.
Again, there are two questions: ``Are you interested?'' and
``If so, what profiles do you want to specify?''

It is early days yet: the issue is to be raised at Technical
Study Group 1's (TSG1's) meeting in Essen, Germany, in
September.  (TSGs are another ISO mechanism which is brought
into play to handle interdisciplinary issues.) TSG1 is
developing a framework for application portability, so it
should consider AEPs worth adopting.  In the mean time,
feedback concerning useful and desirable AEPs is solicited
by IEEE 1003.0.

Finally, WG15 has decided that it is time to adopt IEEE's
draft 1003.2 standard, Shell and Application Utility
Interface for Computer Operating System Environments as the
basis for its recently approved movement towards a
corresponding international standard.  A little procedural
gymnastics is involved: the first SC22 meeting that could
authorise such an adoption is in September, and it is not
clear which draft of 1003.2 will be current at that time: if


                           - 8 -

things go badly it could be draft 8; if to plan, draft 9.
Also, draft international standard 9945, which corresponds
to IEEE 1003.1, must be renamed to 9945.1, allowing 1003.2
to form the basis of 9943.2.  It took three separate
resolutions to put this particular show on the road!

Those, then, are the issues I consider important to members
of EUUG and USENIX.  Beyond them, there was much procedural
stuff  --  more, for example, than at an IEEE meeting, even
though WG22 is apparently quite informal by ISO standards
(sorry).

                              That's all, folks!


Volume-Number: Volume 16, Number 40