std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (05/17/89)
[ 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 domo@sphinx.co.uk. (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
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (05/18/89)
Newsgroups: comp.std.unix From: Donn Terry <uunet!hplabs!hpfcdc!donn> This report contains an error in the addressing (that CAN'T be a name) of the ISO POSIX committee. It's SC22/WG15 (not with the numbers reversed as in the report). Substituting WG15 for all occurrences of WG22 (etc.) solves the problem. For most of the readers this should not be a problem as the committee address is not really relevant, but if the topic is discussed with a standards expert who is not interested in POSIX, he will be very confused. Donn Terry Volume-Number: Volume 16, Number 45