home *** CD-ROM | disk | FTP | other *** search
- 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 24
-
-