Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v22/024/text0000.txt

Text File | 1991-03-07 | 25.2 KB | 801 lines

Submitted-by: [e-mail] (Dominic Dunlop)



          Report on ISO/IEC JTC1/SC22/WG15 (POSIX)
            Meeting of 23rd - 26th October, 1990
              Orcas Island, Washington, U.S.A.

              Dominic Dunlop -- [e-mail]

                  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, [phone].  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 24