Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / reports / 1990.04 < prev next >

Wrap

Text File | 1990-05-09 | 99KB | 2,298 lines

echo intro cat >intro <<'shar.intro.11766' From uucp@longway.tic.com Wed Apr 18 09:23:09 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA19712; Wed, 18 Apr 90 09:23:09 -0400 Posted-Date: 17 Apr 90 22:49:08 GMT Received: by cs.utexas.edu (5.61/1.56) id AA10932; Wed, 18 Apr 90 08:23:05 -0500 Received: by longway.tic.com (4.22/4.16) id AA14013; Wed, 18 Apr 90 08:26:23 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, USENIX Standards Watchdog Committee Message-Id: <1990Apr17.224908.7215@ico.isc.com> Sender: ico.isc.com!std-unix@longway.tic.com (Guest Moderator, Jeffrey Haemer) Reply-To: std-unix@uunet.uu.net Organization: USENIX Date: 17 Apr 90 22:49:08 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities April 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor USENIX Standards Watchdog Committee Update Jeffrey S. Haemer <jsh@ico.isc.com> reports on winter-quarter activites of the watchdog committee: What_the_reports_are_about Reports are done quarterly, for the USENIX association, by volunteers from the individual standards committees. The volunteers are fami- liarly known as ``snitches'' and the reports as ``snitch reports''. The band of snitches and I make up the working committee of the USENIX Standards Watchdog Committee. The group also has both a financial committee: Alan G. Nemeth, Ellie Young, and Kirk McKusick; and a pol- icy committee: the financial committee plus John S. Quarterman (chair). Our job is to let you know about things going on in the standards arena that might affect your professional life - either now or down the road a ways. An official statement from John: The basic USENIX policy regarding standards is: to attempt to prevent standards from prohibiting innovation. To do that, we o Collect and publish contextual and technical information such as the snitch reports that otherwise would be lost in committee minutes or rationale appendices or would not be written down at all. o Encourage appropriate people to get involved in the stan- dards process. o Hold forums such as Birds of a Feather (BOF) meetings at conferences. We sponsored one workshop on standards. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. April 1990 Standards Update USENIX Standards Watchdog Committee - 2 - o Write and present proposals to standards bodies in specific areas. o Occasionally sponsor White Papers in particularly problemat- ical areas, such as IEEE 1003.7 (in 1989) and possibly IEEE 1201 (in 1990). o Very occasionally lobby organizations that oversee standards bodies regarding new committee, documents, or balloting pro- cedures. o Starting in mid-1989, USENIX and EUUG (the European UNIX Users Group) began sponsoring a joint representative to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards committee. There are some things we do not do: o Form standards committees. It's the USENIX Standards Watch- dog Committee, not the POSIX Watchdog Committee, not part of POSIX, and not limited to POSIX. o Promote standards. o Endorse standards. Occasionally we may ask snitches to present proposals or argue positions on behalf of USENIX. They are not required to do so and cannot do so unless asked by the USENIX Standards Watchdog Policy Committee. Snitches mostly report. We also encourage them to recommend actions for USENIX to take. John S. Quarterman, Chair, USENIX Standards Watchdog Commit- tee We don't yet have active snitches for all the committees and sometimes have to beat the bushes for new snitches when old ones retire or can't make a meeting, but the number of groups with active snitches contin- ues to grow (as, unfortunately, does the number of groups). This quarter, you've seen reports from .0, .1, .2, .3, .4, .7, .8, .11, and .12, as well as reports from 1201 and from x3j11 (not really a New Orleans report, but useful none the less). If you have comments or suggestions, or are interested in snitching for any group, please contact me (jsh@usenix.org) or John (jsq@usenix.org). If you want to make suggestions in person, both of us go to the POSIX meetings. The next set will be April 23-27 at Snowbird Resort, just outside of Salt Lake City, Utah. If the reports April 1990 Standards Update USENIX Standards Watchdog Committee - 3 - make you interested -- or indignant -- enough to want to go, the number for room reservations is (800) 453-3000. April 1990 Standards Update USENIX Standards Watchdog Committee Volume-Number: Volume 19, Number 77 shar.intro.11766 echo overview cat >overview <<'shar.overview.11766' From uucp@longway.tic.com Wed Apr 18 16:50:34 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA15537; Wed, 18 Apr 90 16:50:34 -0400 Posted-Date: 17 Apr 90 22:51:28 GMT Received: by cs.utexas.edu (5.61/1.56) id AA15313; Wed, 18 Apr 90 15:49:30 -0500 Received: by longway.tic.com (4.22/4.16) id AA14033; Wed, 18 Apr 90 08:27:39 cst From: Jeffrey S. Haemer <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, USENIX Standards Watchdog Committee Message-Id: <1990Apr17.225128.7324@ico.isc.com> Sender: ico.isc.com!std-unix@longway.tic.com (Guest Moderator, Jeffrey Haemer) Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Date: 17 Apr 90 22:51:28 GMT Apparently-To: std-unix-archive@uunet.uu.net From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX* and C Standards Activities April 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor USENIX Standards Watchdog Committee Update Jeffrey S. Haemer <jsh@ico.isc.com> reports on winter-quarter activites of various standards groups: 1003.0:_A_Guide_to_POSIX-Based_Open_Systems Dot zero, the POSIX guide group, continues to suffer from bureaucratic inertia. It complains that its forty or so attendees are insufficient to allow rapid progress, yet in a year-and-a-half they've just created a table of contents. Some people think this reflects badly on the group. I think this is completely wrong. Admittedly, the economics of producing the POSIX guide itself are unfavorable. A large fraction of the attendees are highly-placed or key employees of large corporations and influential organizations. A back-of-the-envelope calculation puts salary expenditures alone, for each one-week, dot zero meeting, close to six figures. Had the com- mittee delegated the entire task to one or two full-time people, it would be done. The fine overviews UniForum occasionally publishes are proofs-by-example. How, then, does dot zero benefit the user community? The meetings give influential people from the most important corporations in the commercial UNIX arena a way to get together in the same room (or after hours in the same city) and discuss the direction of UNIX without risking an anti-trust suit. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. * UNIX is a registered trademark of AT&T in the U.S. and other countries. April 1990 Standards Update USENIX Standards Watchdog Committee - 2 - USENIX meetings serve a similar purpose for more technical segments of the UNIX community. To some degree, UniForum meetings serve an analo- gous purpose for other segments of the industry. But where else is there such a concentration of high-level, UNIX-vendor management except, perhaps, at meetings of the Hamilton or Archer groups, or of the board of directors of X/OPEN? Attendees support POSIX, and influ- ence their companies to become involved. Because POSIX is a good thing, so are dot zero meetings. 1003.1:_System_Services_and_C_Language_Binding Dot one is well ahead of the rest of 1003; look here to see the future. The initial standard is done, published, and government- approved as FIPS 151-1. The group is now working on supplements, which come in two flavors: nit-picks and corrections (1003.1a) and real additions (1003.1b). But to speak of ``the group'' is mislead- ing; these two working groups have a strikingly different makeup from the group that created dot one. Many who were passionately and inti- mately involved in the production of the ugly green book have moved on, either to other committees or out of the standards game. The working groups are now small numbers of hard-core, dot-one devotees. For .1a, this isn't a problem -- that's exactly the kind of person needed for nit-picking. Watch .1b like a hawk, though. Any new functionality, slipped into supplements and appendices, carries the same risks as riders on congressional bills; if it can be slipped in unobtrusively enough, or with the right timing, it can be awful and still ride on the coat- tails of the main body. Bad deeds done here will both inflict irresistible harm, and diminish the credibility of dot 1. I recommend resisting any effort to add functionality for which there aren't existing implementations in wide use, and about which there isn't already general consensus. Design-by-standards-committee efforts should be deferred to other, more ignorable standards. 1003.2:_Shell_and_Utilities Dot 2 is still firmly in the dot one mold. Dot 2 Classic is balloting away, and should soon be both done, government approved, FIPS-ified, with a set of test assertions that companies like MindCraft can sell test suites for. When this is done, a large number of systems will advertise compliance with 1003.1, 1003.2, and X3.159 and provide, for most users, a standard ``UNIX''. Even the controversial UPE is mostly codifying existing practice. Arguments are over places where more than one practice is widespread, for example, source-code control, where partisans of SCCS struggle with partisans of RCS. (Actually, that's not true. What's really happening is that the group's shying away from this area because they're worried about a struggle. ``Tar wars'' seems to have spoiled April 1990 Standards Update USENIX Standards Watchdog Committee - 3 - the industry's appetite for making difficult decisions about conten- tious topics.) Parenthetically, I'll admit to being mystified by the dim view some folks take of the UPE. I actually put programmer portability above program portability, since, when I go looking for new jobs I can't take our software with me, but do want to be sure that I can still use vi. (Of course, most members of working groups are sponsored by ven- dors.) The equivalent of .1a already has a name: .2b. Even the bad of dot one is mirrored here. Truly controversial proposals are being pushed off to the as-yet unborn .2c, which should produce a deja vu feeling in those already watching .1b. ("But," you remark, "you always say that.") And, just as .1 sometimes shied away from real decisions, in order to avoid upsetting anyone, .2 occasionally reacts to vendor inconsistency by proposing solutions that avoid upsetting any vendor by penalizing all users. As an example, the committee proposes requiring a C compiler (good), and naming it c89 (bad, but I com- plained about this loud and long last time). An important motivation for the new name is that cc already invokes the K&R C compiler on many vendors' platforms, and specifying a flag to choose one behavior or the other would conflict with someone's existing implementation; any given letter is already preempted by some vendor. I'm not convinced by this argument. I have consulted the Ouija board in my office, normally used only for project scheduling, and will now predict the effects of this sidestep, if approved: - In two years, everyone will have a c89 compiler, to comply with a government FIPS. Shell scripts and makefiles will continue to invoke cc, but be less portable than they are now. - On a few conformant machines, there will be no cc command. This will break an enormous number of programs, and solutions will vary from user to user, project to project, and installation to installation. - On other machines, cc will produce one flavor or the other. Most, but not all, machines will link cc to c89. This will break a variety of things, but not consistently enough to allow a port- able solution. - On some of these machines, flags will make c89 compile K&R C. The flag will vary from vendor to vendor. In short, we who do ports will have to keep track of how to invoke the C compiler on each of our target machines; .2 will not have enhanced portability in this area of our work. Finally, like .1, my unease over a small number of problems stands in stark relief to the generally high opinion I have of the work done by April 1990 Standards Update USENIX Standards Watchdog Committee - 4 - this group. 1003.3:_Test_Methods Dot three, a tiny mirror of the overall POSIX effort, is proliferating because it has no choice. It will now have a subcommittee to develop test assertions for each of the other POSIX efforts, and has acquired a steering committee to oversee the subgroups. Whether this is a better choice than having each POSIX committee develop its own test assertions, isn't clear -- I see plusses and minuses for each approach. Still, all in all, the group seems to know what it's doing, and is willing to do it. Dot three isn't always popular; one hears complaints that they come up with interpretations that seem contrary to the intention of the original standards committees. On the other hand, that seems as good a reason as any for their existence. They form a combination system-test and quality-assurance group for the other committees, generating all the friction one expects from any such organization. A dot three member did take the time to divulge an unexpected answer to a question I raised in my last report -- what motivates someone to be in dot three? For a few folks, it's obvious: MindCraft employees attend because their company develops and sells test suites. Others are also there because they're really interested in testing. But think: if you want an overview of all of POSIX, what group should you attend? There are three candidates: dot zero, but then you'd have to buy an expensive wardrobe; the SEC, but that group is mostly institu- tional representatives, officers, and overworked committee chairs; or dot three, which examines each standard in detail as it nears comple- tion. If you're thinking of joining a working group, and want this sort of vantage point, we're certain the group has plenty of work to hand out. 1003.4:_Real-Time_Extensions The real-time group now has five PARs: .4, .4a,, .4b, .4c, and .14. The first of these went to ballot after the New Orleans meeting. Threads, controversial enough to be omitted from .4, has been pushed into .4a. (Things too controversial to go into threads will be pushed into the multiprocessor group, which should be a lot of fun.) The threads subgroup (1003.4A) has attempted to kill the .4 ballot by a block vote for rejection. One correspondent says they are doing this because .4 is no good without threads. (I'm told that two ``large, non-vendor organizations'' are part of the coalition against the 1003.4 ballot. There is rumored to be a special, invitation-only, threads-strategy meeting by these two groups immediately preceding the Utah meeting. Can anyone confirm this and supply more details?) University of California's Computer Science Research Group (the folks who bring us Berkley UNIX) is also voting against the .4 ballot as a April 1990 Standards Update USENIX Standards Watchdog Committee - 5 - block. This stand has nothing to do with the lack of a threads propo- sal; the vote objects to the working group's addition of completely new and (their words) ``lame'' features to UNIX. An amusing twist, this. To a traditional standards activity, one vendor block voting against another, POSIX adds one research group voting against another. The threads group itself is divided over whether they are doing an interface to OS-kernel services or an applications library. They are also divided about whether they are doing an interface to language- independent, concurrent programming services, or just a C-language extension. In general, .4A seems to be a small core of activists pushing ahead with a clear agenda, with an opposition that complains but appears incapable of putting together a detailed, unified counter-proposal. Both the rush to go to ballot, and the move to tie success of the rest of 1003.4 to threads, should be causes for scrutiny. Interestingly, if threads are forced back into the base .4 standard, it may end up causing another problem. The ACM's ARTEWG (the special interest group on Ada's runtime environment working group) is likely to vote in a block against 1003.4 if it contains a threads proposal that does not support Ada in a natural way. The Ada folks are concerned that there be an underlying, OS-level model of concurrency consistent with both the C-threads and Ada task- ing models. This seems especially important to them if Ada applica- tions want to use standard services written using C libraries which are implemented using C-threads (e.g., windowing and database access). Such a model would also be important for support of Ada compilation systems, which are typically produced by independent software houses to operate on a variety of operating systems and machine architec- tures. Dot 4b is a language-independence effort. What's interesting here is that real-time was one of the groups that the SEC grandfathered out of the requirement that POSIX standards be language-independent. (Other exemptions included other standards well along, like .1, and standards that were intrinsically language-dependent, like .9, FORTRAN bind- ings). Despite that exemption, real-time may be the first group to write a language-independent binding. Real-time also has PARs for .4C, a place to put stuff that didn't make it into .4 (i.e., .4 is to .4C as .1 is to .1B), and .14, the real- time profile. April 1990 Standards Update USENIX Standards Watchdog Committee - 6 - Language-independence_Study_Group I want to straighten out something I was confused about in the last summary report. (Thanks to Jeff Kimmel, of the language-independence study group, for taking the time to explain this.) Language- independence is a sop to ISO. Two prices we pay to gain rapid inter- national approval of the POSIX standards are an agreement to hand ISO standards formatted in their preferred style, to which end the IEEE is providing editorial assistance, and a commitment to a direction ISO intends to take for all its standards: language independence. And, to clear up another misconception, Steve McDowell worried, in his last .7 snitch report, that ISO requires language-independent specifi- cation languages to themselves be standardized. This would force POSIX to use something frightening like VDL. Fortunately, that turns out only to be true for formal specification languages: languages from which one can derive correctness proofs. ISO isn't interested in proofs, only in divorcing specifications from specific programming languages. They don't want to give an unfair advantage to languages in which the things being standardized are likely to be initially implemented, like C or FORTRAN, over more international languages, like ALGOL-66. In other words, POSIX will probably produce specs in ASN.1 or even English. (That's ``language independent.'' Get it?.) 1003.5:_Ada_Bindings Dot five didn't officially meet in New Orleans, partly to give .5 members more time to attend other groups. Dot five members kept say- ing things to puzzled members of other committees like, ``We're not really meeting,'' ``I'm not really here,'' and ``Well, I am here, but don't tell our chair, Steve Deller.'' One member graciously volunteers this short, but timely, update: The Ada binding group (P1003.5) just finished an intensive work- ing meeting at Florida State, in Tallahassee. The meeting went very smoothly. We resolved all the issues brought up by the recent mock ballot, and expect to have a revised draft ready for the April POSIX meeting. That draft is supposed to be given some finishing touches at the meeting, and then sent out for formal ballot. 1003.8:_Transparent_File_Access As expected, what used to be dot 8 has split into several groups. There was a meeting on the last day, in which chairs of each of the newly-formed POSIX networking-related groups gave status reports. At that meeting, one attendee objected that the models and APIs that come out of these groups increase portability, but do little or nothing to insure interoperability. Surely, networking standards should have interoperability as a primary goal, he complained. While the current groups don't have solving this problem as part of their charter, many attendees agreed that the complaint is valid, and something should be April 1990 Standards Update USENIX Standards Watchdog Committee - 7 - done on this front. Keep your eye on this problem. While the other subgroups have new numbers, the group standardizing transparent file access (TFA) retains the dot 8 name. Six months ago, TFA was torn between a faction wanting to canonize NFS, and another insisting on something that supports full dot 1 semantics. Now, the group has achieved consensus. They'll provide several standards: a core subset with which FTAM will comply, a set of extensions to the core with which various versions of NFS will com- ply to various degrees, and a full standard that will support full dot 1 semantics. This compromise recognizes the de facto international standard without sacrificing a commitment to dot 1. 1003.9:_FORTRAN_Bindings Dot 9 is in the middle of editorial cleanup in preparation for ballot- ing. Emphasis until now has been on content, so the draft developed with many styles and formats. Much of the last meeting was spent try- ing to even things up. Since things are drawing to a close, you might expect meetings to be sedate. If you read the .9 postings in comp.std.unix, you'll know that's not true. When I walked in on the .9 meeting the group was in the middle of a heated discussion. Someone had proposed adding several functions to increase portability of FORTRAN programs. One specific example was a function that would return the maximum real for the implementation. While there is little question of the utility of such a function, there were two sorts of illuminating objections: 1. Some members of the group objected that the standard was not intended to increase portability of FORTRAN programs, only to provide FORTRAN bindings to the .1 standard. (Indeed, unlike .5, .9 makes no attempt to be a stand-alone document. It freely uses pointers into .1.) Others countered that the section being discussed corresponds to section 8, Language-Specific Service for the C Programming Language, of the ugly green book; that the group's goal is improving application portability; and that additions that further that goal are completely within the group's charter. 2. One member objected strenuously that many of these additions required REAL support. I was utterly mystified by this objec- tion, until the group patiently explained that, though .9 is an F77 binding, it won't require F77 compliance, and won't use all the features of F77. For example, these new functions were .9's first use of REALs. What the member was objecting to was that without the added functions, a vendor could advertise .9 compli- ance with an integer-only FORTRAN compiler. Adding these new functions would require that the vendor's FORTRAN compiler actu- ally handle REALs. Think about that. April 1990 Standards Update USENIX Standards Watchdog Committee - 8 - The ultimate (and, in my opinion, correct) decision was to add the functions, but you can see that there are interesting philosophical divisions in this group. Similar divisions actually exist in all the groups, but the discussions in .9 seem to be more direct and get resolved more quickly. Chalk it up to more programmers, fewer politi- cians. 1003.10:_Study_Group_on_Supercomputing Dot ten has two subgroups, Profile and Batch, each working on a docu- ment. The Supercomputing Application Environment Profile specifies a set of standards, along with options and parameters needed for supercomputing application environments. The current draft, 1.0, is still rough, but specifies most of the required standards. At the April meeting, the Profile subgroup will hold a joint session with dot 0 and the other profile working groups (.11, .14, and the multiprocessing study group) to discuss profiles. Batch Extensions for Portable Operating Systems describes a standard batch management system based on NQS (the Network Queuing System, available from NASA Ames). The batch subgroup began its work within /usr/group's supercomputing working group, has been meeting eight times a year, and is now on draft 1.2. When complete, the document will specify required extensions to POSIX, including interfaces for checkpoint/restart and resource control, utilities for job submission/management and batch system administration, and a network, application-level protocol. The subgroup has submitted a PAR for the batch work, which the SEC will consider at their April meeting. 1003.11:_Transaction_Processing_Study_Group Good news in transaction processing. Dot 11 has been trying to work out what model of transaction processing to adopt. Because many com- mittee members are also active in other committees specifying other TP models, the committee had a running start, but progress has been slowed somewhat because there are at least three camps: those who favor the ISO model, those who favor the X/OPEN model, and those who believe that discussion of concrete models is premature. Part way through the New Orleans meeting the committee took a break from modeling to explore what an API to a transaction processing sys- tem might look like. This, finally, provided a fairly uncontentious topic on which all members could collaborate, and the committee seems to have been able to generate real agreement rather quickly. Success breeds success, and this may smooth the way to find other areas that the committee can make progress. One warning: Working out a sample API may serve only to clarify the committee's thinking about the requirements of their application April 1990 Standards Update USENIX Standards Watchdog Committee - 9 - profile, but I wouldn't be shocked to see the committee eventually submit a PAR for the work. If that happens, ask yourself whether the committee should be designing APIs for an area where there isn't yet industry consensus. 1003.12:_Protocol_Independent_Application_Interfaces Dot 12, process to process communication, is one of the groups derived from the division of the old dot 8 group. The big news from this group is that they've made a real decision in the struggle between XTI and sockets. The group has decided to invent a new interface, which they hope will combine the best of both and avoid the mistakes of each. This is important. It is the first time since the beginning of the committee (several years ago, counting its origins in /usr/group) that it has actually taken a stand on the question. The issue has come up often in past meetings, but until now been deferred by the group. On other fronts, the group is still trying to produce two API's: a detailed network interface and a simple network interface. I worry a bit about having two, disjoint interface standards in the same area. Are two standards better than none? (On the other hand, having two raises the possibility of splitting the group into two separate, num- bered groups at some later date, a popular POSIX pastime.) Recogniz- ing the danger in this split approach, some members of the group are considering whether it might be possible to specify a single, expand- able interface. 12xx:_Protocol-Dependent_Interfaces_for_OSI This new dot 8 spin-off, chaired by Kester Fong, is looking at protocol-dependent networking interfaces. They'll begin by concen- trating on FTAM. We predict this group will make rapid progress, because its composition is dominated by users. To help prevent its work from being an Aristotelian exercise in abstract design, the group has begun to collect all the examples it can find of applications based on FTAM. If you have, or know of, any such examples, please pass them on. Kester's e-mail address is <FONG%AESv01.GM@HAC@ARPA.HAC.COM>. 1201:_User_Interface 1201 is growing to four groups: .1 (Applications Programming Inter- face), .2 (Graphical User Interface), .3 (Human-Computer Interaction), and .4 (XLib). This serves as a focus for an interesting philosophi- cal issue. As many readers realize, there is widespread sentiment outside of these groups that 1201 should, instead, shrink to zero groups -- that standards in this area are premature. Even more interesting is that April 1990 Standards Update USENIX Standards Watchdog Committee - 10 - the same sentiment is widespread inside the groups. The level of dis- satisfaction does vary from group to group. Out of curiosity, I requested a vote for dissolution at the first New Orleans meeting of 1201.3. Fewer than one-third of the attendees voted to dissolve. This contrasts with a similar vote in Brussels in 1201.2, where nearly half of the attendees voted to dissolve. With this much anti-1201 sentiment, isn't there a way to get the IEEE to reconsider the activity? Apparently not. At the last USENIX, in Washington D.C., Jim Isaak, the SEC chair, explained to the well-attended standards BOF that there is really no easy way to dissolve a committee. If volunteers show up to staff the working group, follow the IEEE rules, and eventually circulate a bal- lot that passes, they've created an IEEE standard. This means, if you don't like the idea, you currently have only three options. 1. Join the balloting group and vote any proposal down. Not easy; you have to have a good reason for voting no. Of course, "This standard is premature; the direction of industry is too unclear" may be good enough. 2. Join the working group and filibuster until the direction the standard should take does become clear. (Of course, that would be expensive, and lose you popularity points.) 3. Let the group declare a standard and hope everyone ignores it. This one's dangerous because NIST won't. which means the ven- dors can't, which means users probably won't be permitted to, and will, at least, have to carry the code around as excess bag- gage. So, I'm curious. If you don't like what's going on here, which do you intend to do? (Okay, we're not that picky. If you like what 1201's doing but object to some other portion of what Doug Gwyn calls ``the standards juggernaut,'' what are you doing about it?) x3j11:_C_Language_Standard Closing on an upbeat note, we have a C standard. What more newsworthy item could you ask for? April 1990 Standards Update USENIX Standards Watchdog Committee Volume-Number: Volume 19, Number 78 shar.overview.11766 echo 1003.0 cat >1003.0 <<'shar.1003.0.11766' From jsq@longway.tic.com Fri Apr 13 00:29:03 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA22663; Fri, 13 Apr 90 00:29:03 -0400 Posted-Date: 13 Apr 90 04:28:25 GMT Received: by cs.utexas.edu (5.61/1.56) id AA04990; Thu, 12 Apr 90 23:27:28 -0500 Received: by longway.tic.com (4.22/4.16) id AA01041; Thu, 12 Apr 90 22:29:12 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.0: POSIX Guide Message-Id: <626@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 13 Apr 90 04:28:25 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.0: POSIX Guide Update Charles Severance <crs@convex.cl.msu.edu> reports on the January 8-12, 1990 meeting in New Orleans, LA: Dot zero is producing a guide to the POSIX Open System Environment (OSE). The guide will bring existing and evolving standards together to provide specifications for all aspects of an OSE -- everything from application programming interfaces to user interfaces and system management. It will give users an overview of the 1003, and other, related standards, describe their interrelationships, and help them select the subset of available standards necessary for any particular application. Draft Six Review This meeting, the group reviewed draft six. Points of special interest were: + the formal definition of ``open system'' + internationalization + an editorial review of the entire document to insure a consistent style + a review of some high-level architecture diagrams, proposed to make Chapter 3 (``Overall Architecture'') easier to understand, The only one of these discussed by the entire group was the definition of ``Open System.'' To simplify the definition we created a definition for ``Open Standard'' which was used in the Open System definition. Here is the definition we finally agreed on: Open System: A system that implements sufficient Open Specifications for interfaces, services, and supporting formats which enable properly engineered applications software: a) to be __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.0: POSIX Guide - 2 - ported across a wide range of systems with minimal changes, b) to interoperate with other applications on local and remote systems, and c) to interact with users in a style which facilitates user portability. Open Specification: A public specification which is maintained by an open, public, consensus process to accommodate new technologies over time and consistent with international standards. The group won't define ``user portability'' until next meeting, but the idea is that users should see a consistent interface from application to application, both within and across systems. Public user-interface standards should simplify both user training and vendor documentation. The other issues were handled in small working groups. 1. Internationalization The internationalization group identified parts of the document affected by internationalization and other ``cross-component'' issues, such as system management and security. They promise to present new, draft text for the internationalization sections by the next meeting. 2. Editorial review The editorial review group tackled the no-fun jobs of reviewing the entire draft for style and identifying areas that had too much, or too little detail. Along the way, they proposed a style guide and template for sections of Chapter 4. 3. Architectural overview The architecture group continued work on Chapter 3 to complete the text of the chapter. Also the group worked to simplify the chapter to make it easier to understand. The CCTA (UK) presented a high-level classification scheme called ``MUSIC'' (Management, User Interface, System Interface, Information Interchange, and Communication) as a potential contribution to chapter 3. The chapter will have extensive modifications and additions for the next meeting. Application profiles Next meeting we'll discuss exactly what must be in a POSIX Application Environment Profile (AEP). Profiles will affect and generate procurement issues, so this will be a key discussion. January 1990 Standards Update IEEE 1003.0: POSIX Guide - 3 - Profiles specify a set of standards for specific computing areas, such as supercomputing. Not all standards will be required for all areas; a profile lists the subset of the standards necessary for a particular area. The biggest point of contention in this discussion will probably be whether 1003.1 [Editor: the system interfaces set out in the Ugly Green Book] will be required for all profiles. Should vendors be allowed to advertise compliance to, say, 1003.11 (transaction processing), if they've implemented that standard on an underlying system that doesn't support lower-level POSIX calls like fopen()? (There isn't a standard for 1003.11 yet, but you get the idea.) One argument advanced for requiring 1003.1 is that it will force vendors to adopt it more quickly. I don't think that 1003.1 needs any help in that area. Another is that requiring compliance will insure that vendors who want to advertise POSIX-compliant systems are following the general POSIX direction and not just implementing the simplest standard so they can claim that their system implements ``some POSIX.'' An argument made against the requirement is that it may damage implementations. For example, real-time systems may lack even a file system, and may want a very limited subset of the POSIX interface to keep the implementation as small as possible. If all of 1003.1 is required, vendors may have to add costly and unnecessary features just to claim POSIX compatibility. When the dust settles, I think 1003.1 will be strongly suggested but not required, because 1003.1 is a pretty arbitrary subset of any list of ``required system interfaces.'' [Editor: We disagree. 1003.1 is a set of applications programming interfaces carefully chosen to be necessary and sufficient to make an operating system UNIX-like for the C programmer. Providing standards for a UNIX-like operating system should be the goal of the POSIX standards, and attempts by vendors uncomfortable with UNIX to dilute the effort should be cut off at the pass.] [Author: POSIX must evolve a set of independent standards that have UNIX as their heritage. POSIX standards are all evolving as UNIX-like standards. Why discourage a vendor from implementing some subset of UNIX-like standards just because the vendor is not ready to provide a complete 1003.1 implementation? ] January 1990 Standards Update IEEE 1003.0: POSIX Guide - 4 - Want to go to a POSIX meeting? This was my first POSIX meeting. In case you haven't been and are thinking of going, here are a couple of things you'll want to know. New people and their new ideas, are welcomed. As a practical matter, it helps to stick with a group for the entire week. It's tough to understand much if you come into an advanced discussion, cold, It would help if each group summarized its purpose and listed the big issues at the beginning of each meeting, to get everyone in the proper frame of mind, but that doesn't always happen. Still, you'll be granted a sort of first-time armor to protect you when you ask naive questions or need clarification. For extra insurance, use the phrase ``I will take an action item...'' often. January 1990 Standards Update IEEE 1003.0: POSIX Guide Volume-Number: Volume 19, Number 56 shar.1003.0.11766 echo 1003.1 cat >1003.1 <<'shar.1003.1.11766' From jsq@longway.tic.com Wed Apr 4 02:03:57 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA12365; Wed, 4 Apr 90 02:03:57 -0400 Posted-Date: 4 Apr 90 06:52:48 GMT Received: by cs.utexas.edu (5.61/1.54) id AA20584; Wed, 4 Apr 90 01:03:49 -0500 Received: by longway.tic.com (4.22/4.16) id AA27362; Wed, 4 Apr 90 00:53:39 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.1: System services interface Message-Id: <619@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 4 Apr 90 06:52:48 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.1: System services interface Update Mark Doran <md@inset.co.uk> reports on the January 8-12, 1990 meeting in New Orleans, LA: Most published standards inevitably require updating through corrective supplements. P1003.1 has now reached that stage. The first supplement, P1003.1a, is at an advanced stage and was the central issue at the New Orleans meeting. Also on the agenda were - further talks with the group working on transparent file access; - more language-independent-specification work; and - a run-through of the material in the embryonic second corrective supplement, P1003.1b. P1003.1a Ballot Resolution The first corrective supplement to IEEE 1003.1-1988 (POSIX.1) is intended to correct errors and oversights in the first publication with a view to clarifying the intent. It is definitely not meant to introduce new functionality or behavior into the standard. This work received its second recirculation ballot during the week preceding the New Orleans meeting. Donn Terry, chair of P1003.1, hopes that one, or at most two, more recirculations will bring the document to a publishable state. Accomplishing this will send it off to ISO, who will ballot it for six months. (That's right, six months; an IEEE recirculation ballot lasts ten days -- does this seem a little lop-sided to you?) The details of the content of P1003.1a and its ballot resolution are long and complex, so I won't repeat them here. However, there is one issue worth raising which the ballot brought to light. On the subject __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.1: System services interface - 2 - of changes relating to the support of split baud rates, one balloter commented: While we do not agree with the direction this issue is obviously taking, we will abide with the decision of POSIX insofar as split baud rates are concerned. But we would be remiss in our responsibilities if we did not express our complete outrage with the provincial attitudes expressed by a number of the ballot comments we have had the pleasure to review during this recirculation period. Split baud rates ARE NOT uncommon with a great number of the community of users of these standards. Obviously, many of those submitting ballots have not had the opportunity to consider the needs or requirements of users outside their own immediate view. We abhor such a limited, irresponsible scope, especially considering the nature of the tasks we are charged with resolving. It is our hope that we shall do better in the future. Only rarely are standards meetings graced with such florid language, and the balloter clearly has at least the tip of his tongue in his cheek; however there is, underneath this bonhomie, a serious point being made... The IEEE is an ANSI-accredited standards-developing body, responsible enough to make standards pronouncements for use in the USA. All POSIX standards are being passed to ISO for potential adoption as international standards. The POSIX steering committee (SEC) has declared that POSIX would like to think of itself as an internationally accessible organization. If POSIX is indeed to be internationally accessible then the attitudes of some of those who attend will have to change. Take for instance, the split-baud-rate issue mentioned above. Working group discussions revealed that split-baud-rate support, though a non-issue in the USA, is important in Europe. (The reasons for this stem from the way the PTTs in Europe structure their charges for communications lines -- PTTs are Europe's little AT&T equivalents.) To cut a long story short (and I do mean long; this particular debate has been going on for over a year...), the P1003.1 working group decided that split baud rates are not important enough to require explicit support for them in the standard. And of course this may be quite reasonable. What is unacceptable is the apparent scorn with which these proposals were regarded by a minority of the participants in the discussions. If POSIX proceedings are to lead toward internationally useful standards then all participants should be mindful of the fact that there is a flourishing community of users who do not live in the USA. January 1990 Standards Update IEEE 1003.1: System services interface - 3 - Split baud rates are, when all is said and done, not of earth- shattering importance, nor even terribly interesting; were this an isolated incident, it would not even be worth mentioning. Unfortunately, I have encountered this type of attitude on many occasions. Let's hope that ballot comments like that presented above reduce this frequency. (``What are split baud rates?'' the American reader is asking. Serial lines like those plugged into the back of ``dumb'' terminals can be set to transmit at high-speed while receiving at a lower speed, e.g., 9600 and 75 baud; this can be useful if you regularly send screenfuls of data to a terminal but only expect the odd character or two back in the other direction. POSIX supports this by supplying cf{set,get}{i,o}speed() and tc{get,set}attr() -- that's six interfaces, see? :-) Transparent File Access (TFA) The TFA group (now P1003.8) presented several detailed questions about and the behavior that P1003.1 would like to see from a TFA implementation in several ``corner cases.'' Dot one's response is that a few compromises can be made where there are serious performance issues, but the spirit of the original POSIX.1 should be retained wherever possible. On a more interesting note, at a TFA BOFF (Birds OF a Feather session -- that's a cozy chat after hours), it was suggested that a subset TFA specification might be produced before the full TFA specification. Such a specification would not provide full POSIX.1 behavior but would probably be enough to allow POSIX implementations to connect with existing FTAM and NFS file server machines, which should suffice for many applications. Language-Independent Specifications Last report, I said I hadn't heard a worthwhile justification for this work or the approach being taken. I still haven't. P1003.1b This supplement, still being formed, will be the first to introduce new functionality into POSIX.1. Highlights so far include symbolic links, and file-tree walking (more ways to find files and directories in file systems). If you have a favorite interface which has not yet made it into a POSIX standard, you might be able to get it in by proposing it for inclusion in P1003.1b. The cut-off date is likely to be the April POSIX meeting, so hurry. January 1990 Standards Update IEEE 1003.1: System services interface Volume-Number: Volume 19, Number 49 shar.1003.1.11766 echo 1003.2 cat >1003.2 <<'shar.1003.2.11766' From jsq@longway.tic.com Wed Apr 4 02:04:21 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA12539; Wed, 4 Apr 90 02:04:21 -0400 Posted-Date: 4 Apr 90 06:59:32 GMT Received: by cs.utexas.edu (5.61/1.54) id AA20658; Wed, 4 Apr 90 01:04:12 -0500 Received: by longway.tic.com (4.22/4.16) id AA27444; Wed, 4 Apr 90 01:00:50 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.2: Shell and tools Message-Id: <620@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 4 Apr 90 06:59:32 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.2: Shell and tools Update Randall Howard <rand@mks.com> reports on the January 8-12, 1990 meeting in New Orleans, LA: Background on POSIX.2 The POSIX.2 standard deals with the shell programming language and utilities. Currently, it is divided into two pieces: + POSIX.2, the base standard, deals with the basic shell programming language and a set of utilities required for application portability. ``Application portability'' essentially means portability of shell scripts and excludes most interactive features. In an analogy to the ANSI C standard, the POSIX.2 shell command language is the counterpart of the C programming language, while the utilities play, roughly, the role of the C library. POSIX.2 also standardizes command-line and function interfaces of some POSIX.2 utilities (e.g., popen(), regular expressions, etc.) This document is also known as ``Dot 2 Classic.'' + POSIX.2a, the User Portability Extension or UPE, supplements the base POSIX.2 standard; it will become a non-normative (optional) chapter of some future draft of the base document. The UPE standardizes commands, such as screen editors, that might not appear in shell scripts but that users must learn on any real system. An interactive standard, it attempts to reduce retraining costs incurred by system-to-system variation. For utilities that have interactive as well as non-interactive features, the UPE defines extensions from the base POSIX.2 utility. One example is the shell, for which the UPE defines job control, history, and aliases. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.2: Shell and tools - 2 - In my previous report, I noted two serious strategic problems with the UPE: - lack of coherence, and - lack of support. The problems haven't disappeared. (See the previous report for further information.) Features used both interactively and in scripts tend to be defined in the base standard. Status of POSIX.2 Balloting ``Dot 2 Classic'' remains in its second round of balloting on Draft 9. Hal Jespersen, the POSIX.2 Technical Editor, thinks the forthcoming Draft 10 will go to ballot in June or July, Some early subsets of Draft 10 were in evidence at the working group meeting, but circulation is still restricted to those feeding changes into the Technical Review Process (so, no, you won't be able to get one yet...). Draft 10 involves fewer people than the ten or so technical reviewers that produced Draft 9. On one hand, fewer people means fewer ulcers for Hal Jespersen, who must co-ordinate myriad changes from as many quarters. On the other, too few people produces a closed process, which extends the number of rounds of balloting required for final resolution. Because the first round of balloting (Draft 8) produced many objections that were only partially resolved by Draft 9, and because issues often have several sides to consider, the Draft 10 balloting, starting this summer, has only a slim chance of creating the final standard. That said, Dot 2 Classic's contentious areas appear to be narrowing to a small set of new inventions (create, hexdump, locale, localedef, etc). I expect the objections to Draft 10 to be far fewer, and that the process is likely to converge to a full-use standard by Draft 11, late in 1990 or early in 1991. On the UPE front, Draft 4 is scheduled to appear in February or March, so that a mock ballot may be held for the April meeting. A mock ballot is a rehearsal for the real ballot -- real comments and objections are both prepared and resolved by the working group. A real ballot shifts the focus from the working group to the balloting group. The mock ballot is an excellent exercise, but communications within the working group tend to be excellent. The process becomes more obscured once formal balloting begins, as shown by the extended balloting on Dot 2 Classic. None the less, having distinct balloting and working groups ensures that the process has comments from all parties. Formal (real) balloting for the future Draft 5 of the UPE should commence this fall. A much smaller standard, the UPE is approaching the level of review that Dot 2 Classic had before it entered formal balloting. January 1990 Standards Update IEEE 1003.2: Shell and tools - 3 - Status of the New Orleans Meeting Apart from a status report on the balloting of Dot 2 Classic, the New Orleans meeting focused on readying all UPE utility descriptions for mock balloting. The working group reviewed existing utility descriptions in small groups of between three and six persons. One group spent much of the week fleshing out arcane details of vi, only occasionally relieved by work on simpler utilities. A group I worked in made the surprising discovery that uuencode, a utility traditionally used to convert binary files to a printable form to pass through mailers, is a utility to ``encode a binary file into a different binary file.'' This complexity arises from internationalization, where there are always several ways of looking at any problem. Delve deeply into POSIX and ANSI C internationalization issues, and you'll always discover topics that the committees have not yet dealt with. This is not a criticism of the internationalization standardization groups; much work is still needed and solutions to many problems remain elusive. In the uuencode example, we felt the output of uuencode should be code-set invariant. I.e., uuencode on an EBCDIC system should produce the same results as uuencode on an ASCII or ISO 646 character system. To achieve this, ' ' through '_' must be expressed as 0x20 through 0x5F and begin must be expressed as 0x62 0x65 0x67 0x69 0x6E (the hex equivalents of `b' `e' `g' `i' `n' in ASCII). POSIX appears to offer no standard way to convert a file from one code set to another. Attendance at the UPE working group was, again, relatively small -- around a dozen people. One reason is PAR proliferation. Most companies cannot afford to send one committee member to each working group. (I, for example, also had to cover TFA, POSIX.1b, and the internationalization efforts.) [Editor: Readers should note that that being spread thin didn't stop Randall from turning out a clear, thoughtful report. Thanks, Randall.] Another reason is that there is less enthusiasm for the UPE than for Dot 2 Classic. Even Hal Jespersen has said that ``...basically the NIST put our feet to the fire to do the UPE.'' Some people want the UPE to include an EMACS editor description as well as one for vi. Unfortunately, although there was talk of an EMIN proposal, none was submitted to the working group. If you EMACS fans want it included in the ever-expanding UPE, then submit a proposal. [Editor: Listen up, folks. He's serious.] (Of course, some devotees feel that standardization would be inappropriate for an extensible environment like EMACS.) ``Revision/Source Code Control Software'' is a much-shuffled area of future standardization within the overall POSIX.2 PAR. Fearing another Tar Wars-like clash between fanatic supporters of of SCCS and RCS, the topic was removed from Dot 2 Classic and deferred to the UPE. The Source Code Control System (SCCS) is the original UNIX source code January 1990 Standards Update IEEE 1003.2: Shell and tools - 4 - control system which was implemented in the mid-1970's, modeled after mainframe systems of the time. The more modern (no bias here...) Revision Control System, (RCS), by Walter Tichy of Purdue University, claims to have improved on SCCS. Each has its proponents; SCCS appears to have a stronger following, because of commercial support by vendors, but RCS appears to have a more devoted underground following. The working group is divided between those who want either SCCS or RCS and those who want neither, arguing that source control is a vendor- specific application. Unfortunately, the UPE working group has had problems resolving the controversy and Hal Jespersen has proposed that POSIX.2c (yes, you heard it right, .2c) be assigned as a PAR for working on this topic. (What happened to .2b? POSIX.2b is the working group that will prepare revisions and clarifications of Dot 2 Classic -- which isn't even finished balloting.) The next meeting will be in Snowbird, Utah (oops, we're supposed to say ``Salt Lake City''), the week of 23-27 April, 1990. January 1990 Standards Update IEEE 1003.2: Shell and tools Volume-Number: Volume 19, Number 50 shar.1003.2.11766 echo 1003.3 cat >1003.3 <<'shar.1003.3.11766' From jsq@longway.tic.com Fri Apr 13 00:30:07 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA23128; Fri, 13 Apr 90 00:30:07 -0400 Posted-Date: 13 Apr 90 04:35:22 GMT Received: by cs.utexas.edu (5.61/1.56) id AA05056; Thu, 12 Apr 90 23:30:03 -0500 Received: by longway.tic.com (4.22/4.16) id AA01201; Thu, 12 Apr 90 22:36:35 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.3: Test Methods Message-Id: <627@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 13 Apr 90 04:35:22 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.3: Test Methods Update Doris Lebovits <lebovits@attunix.att.com> reports on the January 8-12, 1990 meeting in New Orleans, LA: Dot three's job is to do test methods for all of the other 1003 standards. This was the working group's fifteenth meeting. We reviewed the ballot status of P1003.1 test methods, worked on P1003.2 test methods, and created a steering committee. Review of ballot status and Dot two verification The P1003.3 standard will consist of several parts: Part I is generic test methods, and part II is test methods for measuring P1003.1 conformance, including test assertions. Part III of P1003.3 will contain test methods and assertions for measuring P1003.2 conformance. As other P1003 standards evolve, they will be covered as separate parts in the P1003.3 standard. Each day was divided into two sessions: mornings, we did technical review of parts I and II, afternoons were spent writing assertions for part III. AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General, Cray Research, Unisys, Perennial and Unisoft Ltd. were represented. [Editor's complaint: I see no user representation at all.] It took twelve meetings of the previous P1003.3 working group to prepare the draft that is now balloting. The technical review for the Draft 10 ballot was completed. Draft 11 was re-circulated late February 1990 and closed March 23, 1990. The balloting group is approximately ninety members. X/OPEN submitted a list of assertions for P1003.1a. This list was included as an appendix to Draft 11. Balloters were expected to review this appendix as part of their ballot. We anticipate an approved P1003.3 standard in the third quarter of 1990. This is the third meeting for developing a verification standard against the P1003.2 standard. The P1003.2 assertion writing and review were done in small groups. Some of the assertions were based upon P1003.2 Draft 9. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.3: Test Methods - 2 - A steering committee and some new officers The chair, Roger Martin, instigated the creation of a test-methods steering committee to help alleviate the increasing dot-three work load all the other, proliferating groups are creating. The committee will coordinate the activities of all test-methods groups, monitor the groups' conformance to test methods, and write and approve Project Authorization Requests (PARs). Membership will be dynamic, limited to four to six, and new members will be chosen based on long term commitment, new ideas, and technical/managerial skills. Roger suggested an initial makeup -- Roger Martin (NIST, Steering Committee Chair), Anita Mundkur (HP), Andrew Twigger (Unisoft), Bruce Weiner (Mindcraft), and Lowell Johnson (Unisys) -- and the working group approved. It's a non-controversial mix of established P1003.3 members. The Standards Executive Committee (SEC) has approved both the committee and its membership. Their first assignment is to document procedures. In addition, new officers were chosen for the P1003.2 Test Methods activities. Ray Wilkes, of Unisys, is Chair, Jim Moe, of Cray Research, is Co-chair, Lowell Johnson of Unisys is Secretary, and Andrew Twigger of Unisoft Ltd is Technical Editor. January 1990 Standards Update IEEE 1003.3: Test Methods Volume-Number: Volume 19, Number 57 shar.1003.3.11766 echo 1003.4 cat >1003.4 <<'shar.1003.4.11766' From jsq@longway.tic.com Fri Jan 19 19:01:06 1990 Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP id AA22523; Fri, 19 Jan 90 19:01:06 -0500 Posted-Date: 19 Jan 90 23:44:55 GMT Received: by cs.utexas.edu (5.59/1.46) id AA10122; Fri, 19 Jan 90 18:00:45 CST Received: by longway.tic.com (4.22/4.16) id AA01984; Fri, 19 Jan 90 17:45:46 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.4: Real-time Extensions Message-Id: <511@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.UU.NET Date: 19 Jan 90 23:44:55 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.4: Real-time Extensions Update Rick Greer <rick@ism.isc.com> reports on the January 8-12, 1990 meeting in New Orleans, LA: 1003.4 goes to ballot The big news in 1003.4 is that some of it is ready for balloting. My copy of the dot-4 ballot was waiting for me when I got back from New Orleans. The current draft is a 330-page, eclectic collection of real-time features. Some (e.g., asynchronous event notification) address significant deficiencies in the dot-1 base, but others (e.g., IPC message passing) seem to be of limited value. It remains to be seen whether the limited applicability of some of the proposed features is enough to shoot down the entire ballot. One area that may cause trouble is the shared-memory model in the Language-Specific Requirements section. While this language- independent model addresses a real need--serialization of reads and writes in the presence of simultaneous updates to a common store--it does so rather formally; people uncomfortable with formal, mathematical models may be put off by it. The fact remains, however, that both dot 1 and the ANSI C standard failed to address this problem, which is critically important in shared-memory multiprocessor architectures. Threads The threads proposal is only an appendix in the current draft, and won't be subject to formal ballot. Though there were too many loose ends in the threads proposal to send it to ballot in this round, most of them were tied up in New Orleans. We should have a ballotable draft ready after the April meeting. Meanwhile, the active membership in the threads "small group" is changing. Representation from the Ada community has grown from two to six; almost a quarter of the active membership is now familiar with __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.4: Real-time Extensions - 2 - Ada and its multitasking model. Most threads people, including me, are also becoming active in the new multiprocessor study group. Discussion within the multiprocessor group promises to be quite lively, since the threads group's more contentious issues (e.g., signals) were skirted by defining high-level interfaces, leaving details of low-level behavior unspecified. The multiprocessor group, on the other hand, must deal with the low-level behavior of multiprocessor configurations, and many of the old arguments have already re-surfaced (e.g., should signal state be maintained per- process or per-thread?). Using high-level interface specifications to dodge low-level implementation issues does have its problems, though. People unaware of more subtle implementation issues tend to view new, high-level interfaces as unnecessary complications. It's difficult to convince them that, even if consensus could be reached regarding the behavior of primitive functions, we would still need high-level interfaces (or rigid coding disciplines) to guarantee that independently developed routines use primitives consistently when addressing common problems. The real sticker here has been how to asynchronously terminate a thread and cause it to execute cleanup code. Everyone agrees that this is necessary. Some members, particularly those from AT&T/USO, feel that the best way to provide this facility is by minor enhancements to traditional UNIX signals, but most of the group feels that the best way to deal with notorious signal races in a uniform, language-independent manner, is to adopt a high-level interface, modeled after one used by DEC/SRC. 1003.4 turns into .4, .4A, .4B, .4C, and .14 There are three other major, on-going efforts in dot 4: language- independent specification of the real-time extensions, identification and specification of other, important, non-threads, real-time extensions that didn't make it into the current ballot, and specification of a real-time application profile. The first is farthest along, but none is anywhere near completion. Recognizing that these efforts were separate from the current proposal, and from one another, the working group submitted four new Program Action Requests (PARs). The Sponsor Executive Committee (SEC) approved all four, and decided that the application-profile effort was so distinct that it needed a new number. The working group's five PARs are now the current ballot 1003.4 threads 1003.4A language independence 1003.4B further real-time extensions 1003.4C real-time application profile 1003.14 January 1990 Standards Update IEEE 1003.4: Real-time Extensions Volume-Number: Volume 18, Number 24 shar.1003.4.11766 echo 1003.8 cat >1003.8 <<'shar.1003.8.11766' From jsq@longway.tic.com Sun Feb 11 22:18:41 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA16039; Sun, 11 Feb 90 22:18:41 -0500 Posted-Date: 11 Feb 90 20:33:51 GMT Received: by cs.utexas.edu (5.59/1.50) id AA15193; Sun, 11 Feb 90 14:59:20 CST Received: by longway.tic.com (4.22/4.16) id AA03534; Sun, 11 Feb 90 14:34:31 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.8: Transparent File Access Message-Id: <539@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 11 Feb 90 20:33:51 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.8: Transparent File Access Update Jason Zions <jason@cnd.hp.COM> reports on the January 8-12, 1990 meeting in New Orleans, LA: 1003.8 breaks up The networking work has been reorganized; what was one committee is now five. At this meeting, the Sponsors' Executive Committee (SEC) approved all the networking Project Authorization Requests (PARs) and forwarded them to the IEEE Standards Board for final approval. In the past, 1003.8 was responsible for half-a-dozen types of networking issues. From now on, 1003.8 will restrict itself to transparent file access (TFA); the other work will be distributed to four new groups. The new structure is Project Name Description _____________________________________________________ 1003.8 TFA Transparent File Access 1003.12 PII or P2P Protocol Independent Interfaces, or Process to Process 1003.13 RPC Remote Procedure Call 12xx PDI Protocol Dependent Interfaces, a.k.a. OSI FTAM and ACSE 12yy NS/DS Name Spaces and Directory Services, maybe X.500 The SEC tentatively assigned 1200-series numbers to NS/DS and PDI, because they intend these standards to apply to any operating system, not just one that's UNIX-like. (There's one exception: NS/DS must identify the name spaces required by the 1003 standards and determine some means of managing them.) __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. - 2 - TFA decides what to do about NFS The meeting was a landmark for TFA. Until now, no consensus on overall direction had been achieved. We spent a great deal of time discussing the philosophy and goals for a Full TFA and Subset TFA, but no common understanding had been reached in the minds of all members; we wandered between extremes of, "Full means 1003.1!" and, "But NFS sure seems to be good enough for users; after all, they're still buying it." It became clear that some agreement had to be reached for progress to be made. Many TFA attendees had never worked on a POSIX committee before and didn't quite understand the POSIX consensus process, but after a joint meeting of 1003.1 and TFA, the exact scope and structure of work were finally hashed out. The group's work items are described below. 1. Full TFA This piece will contain minor additions and changes to 1003.1- 1988 to specify its behavior when operating on remote files. Work will include extending already-defined interfaces (e.g., new stat() information), defining new errors, defining failure and recovery semantics, and so on. Semantically, a remote file accessed under Full TFA will be indistinguishable from a local file. A strictly conforming POSIX application will run completely unaltered in a Full TFA environment. 2. Subset TFA This piece will define both a core subset of 1003.1-1988 that can work correctly over a variety of remote-file-access protocols ("the Core") and a number of additional, optional feature sets. The specification will form additional text for IS 9945-1 (ISO's version of 1003.1). The intent is to have Subset TFA work on the widest variety of protocols consistent with a useful Core; if a remote-file-access protocol is so constraining that any Core based on it would be too small to support useful applications, it will be excluded. FTAM, the International Standard File Transfer and Access Method (IS 8571), will shape decisions about what will go into the Core, for a variety of reasons. + It is the weakest common mechanism for remote file access. - 3 - + The standard has little chance of success at the ISO level unless it is clearly cognizant of FTAM. + Nothing weaker than FTAM is likely to prove useful to application writers. + People are clamoring for a simple interface to FTAM; the open/read/write/close style of Subset TFA meets that need. The difference in functionality between the Core and Full interfaces will be divided into blocks of capabilities (the "feature sets" mentioned above), which might be provided by other commonly used file-sharing mechanisms. A Core-conforming application will be able to inquire (via pathconf()) what functionality, over and above the Core, is available on a per- file basis, and alter its behavior accordingly. The Core will meet an expressed need to know "what doesn't work right" over common file sharing protocols. For example, Sun might define NFS's functionality in terms like, "NFS provides Core Subset functionality, plus the _PC_LOCKING, _PC_DIRECTORIES, and _PC_TIMES capability sets." An application programmer could use such a specification to determine exactly what features of 1003.1-1988 were safe to use in an NFS environment. This scheme also permits continued development of remote-file- access protocols. Any mechanism that supports at least the Core will conform to the standard. This encourages vendors and researchers to develop mechanisms that combine the Core and its options with other advantages (very high performance, very high robustness, good behavior over WANs, etc.), while giving users a well-defined interface for applications that will work in all such environments. 3. A Data-Stream Encoding (DSE) supporting the Full TFA Interface This will provide the mechanism necessary for interoperation of client and server systems. 1003.8 will only develop the encoding; no binding to any particular protocol stack or suite is planned. (Such bindings will be done by working groups chartered to develop profiles to satisfy particular needs.) Work on the DSE will probably not begin for at least another six months. There are now two existing, proprietary mechanisms that provide the appropriate functionality: SVR4 RFS and the Andrew File System (AFS v.3 from Transarc). The committee hopes at least one (if not both) of these products' DSEs will be released to POSIX for standardization. If both are, there will probably be a gun-battle over which to base the standard on. - 4 - There was good progress on the first two work items. The group hopes to have a meaningful draft available by April, and would like to go to ballot by the end of the year. This quick ballot will help compensate for the small working group by bringing major ballot objections to the surface early. (Much coordination with other 1003 working groups, especially 1003.1, will also help.) The balloting process will probably be quite lengthy: on the order of 12-15 months. Volume-Number: Volume 18, Number 52 shar.1003.8.11766 echo 1003.11 cat >1003.11 <<'shar.1003.11.11766' From jsq@longway.tic.com Mon Mar 19 16:59:12 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA09085; Mon, 19 Mar 90 16:59:12 -0500 Posted-Date: 19 Mar 90 21:51:53 GMT Received: by cs.utexas.edu (5.59/1.52) id AA17753; Mon, 19 Mar 90 15:53:01 CST Received: by longway.tic.com (4.22/4.16) id AA10469; Mon, 19 Mar 90 15:53:26 cst From: Jeffrey S. Haemer <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.11: Transaction Processing Message-Id: <578@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 19 Mar 90 21:51:53 GMT Apparently-To: std-unix-archive@uunet.uu.net From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.11: Transaction Processing Update Bob Snead <bobs@ico.isc.com> reports on the January 8-12, 1990 meeting in New Orleans, LA: Context Our charter is to develop an application profile for POSIX Transaction Processing (TP). We're wrestling with both the content of our profile and the idea of a profile, since the profiles are new to POSIX. [Editor: Jim Isaak reviews application profiles in the February IEEE Computer.] The content is influenced by two other TP efforts: OSI's DTP and X/OPEN's XTP. We must handle OSI DTP, just to gain ISO acceptance--a goal of all the 1003 efforts. In theory, XTP is just another proprietary concern. In fact, XTP's ongoing deliberations are currently confidential. Moreover, X/OPEN isn't an official standards body so we can't officially reference XTP in our profile. Nevertheless, XTP will carry considerable weight, since it will be a multi-vendor consensus on how to do UNIX TP. Models As at previous meetings, we spent much time discussing TP models. For the most part these discussions were based on a snapshot of XTP's model released to non-X/OPEN members some time ago. Each model we discussed consisted of three or four of the following elements: Application Programs (APs), Resource Managers (RMs, like database managers), Communications Managers (CMs, like TCP/IP), and Transaction Managers (TMs, which enforce the transaction protocol among APs, CMs and RMs). Here, in chronological order, were the major topics of discussion. We discussed whether a CM might just be an instance of an RM (viewing an instance of a communications protocol or link as a resource), but concluded that attributes of CMs make them fundamentally different beasts (though, to be honest, it's still not clear to me why). __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1003.11: Transaction Processing - 2 - We considered several models based on XTP, but differing from one another in the roles of the CM and the interfaces between the AP and CM. We concluded that each communications protocol would have to have its own CM, and that our model must support multiple concurrently active CMs. A CM, though, is more than just its protocol support. It has to include support for additional functionality required for DTP. We never concluded whether or not an AP should talk directly to a CM, or to a CM via the TM. Requirements In the course of the model discussions, it became clear that many of us had different requirements in mind, so we shifted our focus to requirements to try to reach some consensus. Ultimately, we decided that POSIX TP must: - be mappable onto OSI DTP, - support global (distributed) transactions, - support chained and unchained transactions, - support a conversational mode, - provide data conversion (e.g., ASN.1), - ensure that POSIX RPC supports DTP semantics, - ensure that DTP can be accomplished through RPC, - provide for location independence via directory services, and - provide for security of data. Exercises We decided to break the modeling deadlock by focusing on the AP/TM interface and ignoring communication. We worked several examples, following ISO DTP services but using an RPC paradigm, and concluded that an API based in RPCs would need at least four services: - one for a caller to start a transaction, - one for a callee to find out if it is participating in a transaction, - one for a callee to abort a transaction, January 1990 Standards Update IEEE 1003.11: Transaction Processing - 3 - - one for a caller to commit or abort a transaction. We also identified the following assumptions for TP via RPC: - A thread of control (TOC) can be in at most one transaction at any given time. - If one TOC communicates with another, the latter joins the former's transaction by default. - No nested transactions are permitted. - A GTRID (Global TRansaction ID) can be associated with multiple TOCs and multiple RMs. - A transaction has only one initiator and only the initiator can issue commit. Any TOC may abort. January 1990 Standards Update IEEE 1003.11: Transaction Processing Volume-Number: Volume 19, Number 9 shar.1003.11.11766 echo 1003.12 cat >1003.12 <<'shar.1003.12.11766' From jsq@longway.tic.com Tue Mar 20 02:33:39 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA08572; Mon, 19 Mar 90 16:55:51 -0500 Posted-Date: 19 Mar 90 21:43:24 GMT Received: by cs.utexas.edu (5.59/1.52) id AA17731; Mon, 19 Mar 90 15:52:48 CST Received: by longway.tic.com (4.22/4.16) id AA10285; Mon, 19 Mar 90 15:43:54 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.12: Inter-Process Communication Message-Id: <577@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 19 Mar 90 21:43:24 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.12: Inter-Process Communication Update Steve Head <smh@hpda.HP.COM> reports on the January 8-12, 1990 meeting in New Orleans, LA: OVERVIEW P1003.12 is the IEEE POSIX Network Inter-Process Communication (IPC) committee (formerly P1003.8/2). The committee is currently working on two potential interfaces, a detailed interface (DNI) and a simple interface (SNI). At this meeting, the group arrived at a high-level description of a name-to-address translation facility, and decided the question of XTI versus sockets versus ``something else'' in favor of ``something else.'' The group began discussing connection setup, and continued discussing SNI. Finally, the POSIX steering committee (SEC) changed the group's name to P1003.12. There were about twelve attendees. DETAIL 1. SNI reviewed A UC Berkeley SNI proposal is gradually taking shape. The proposal describes both objects and functions that act on them. Some of these objects and functions have analogues in the socket world, while most of the others are composites. The most recent additions are sni_save() and sni_restore(). sni_save() takes a snapshot of an endpoint and saves it in a string, suitable for passing to a child process through an argument or the environment. sni_restore() restores the library state of an endpoint from that string. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication - 2 - The committee has had two goals for SNI. For naive users, it should simplify the networking interface. For vendors, it should allow implementation of interfaces over complex protocol stacks (such as ACSE--or something above ACSE--over OSI-7). One issue that came up was what the application programmer would target for. If DNI and SNI retain distinct differences, SNI- based applications risk outgrowing SNI's capabilities. One alternative would be to combine DNI and (the current) SNI to allow seamless expansion into protocol-specific hooks, without recoding of applications. Next meeting, UNISYS is expected to present an alternative SNI proposal. 2. Naming The group discussed name-to-address translation for DNI in detail, specified an interface at a high level, and intends to pass it to the naming group. The specification is: given: hostname/``entity'' service/``facility'' type/``context'' protocol or protocol family return: set of { address any input parameters that were completely or partially wild-carded } SNI might need something similar, but without the protocol/protocol-family/address-family parameter. (SNI is protocol-independent.) The interface lets applications defer deciding which protocol- or address-family to use until after the query. It will also permit load-balancing, a technique to optimize data-transfer performance over slower interfaces (such as multiple, serial, point-to-point links). The group deferred discussing both performance (time and memory), and which input parameters could be wild-carded. 3. XTI versus sockets The XTI-versus-sockets issue came up briefly while discussing passive-endpoint functions. The group resolved to incorporate January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication - 3 - the best of XTI, sockets, and possibly other extensions, into DNI. The group decided not to require full XTI-type functionality, and accepts the risk that porting XTI-based applications to DNI may require source-code changes. A potential advantage of this decision is that the standard can leave out the mistakes of XTI and sockets. Also, vendors remain free to supply the older interfaces on the side. A UCB representative will prepare a new DNI proposal between now and the next meeting. 4. P1003.8/2 -> P1003.12 The SEC gave network IPC its own separate number: P1003.12. This change will be formally approved at the IEEE standards board meeting, a couple of months from now. 5. Potential overlaps with P1003.4 For several meetings, both P1003.12 and P1003.4 have been aware of their potentially overlapping coverage of process-to-process communication on a single, local system. Since there should be only one interface for common functions, and any characteristics peculiar to local IPC can be supported by protocol-specific options under DNI, P1003.12's position is that it should handle all IPC. The group has asked the networking steering committee chair, Tim Baker, to relay this position to the SEC. FUTURE MEETINGS AND SIGNIFICANT DATES: The Spring 1990 meeting will address SNI/DNI connection setup/tear- down and SNI/DNI data transfer. January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication Volume-Number: Volume 19, Number 8 shar.1003.12.11766 echo 1201 cat >1201 <<'shar.1201.11766' From jsq@longway.tic.com Thu Mar 29 14:53:17 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA26594; Thu, 29 Mar 90 14:53:17 -0500 Posted-Date: 29 Mar 90 17:56:18 GMT Received: by cs.utexas.edu (5.61/1.54) id AA06711; Thu, 29 Mar 90 13:49:50 -0600 Received: by longway.tic.com (4.22/4.16) id AA05547; Thu, 29 Mar 90 11:57:28 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1201: User Interface Message-Id: <604@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 29 Mar 90 17:56:18 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities January 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1201: User Interface Update Peter H. Salus <peter@uunet.uu.net> reports on the January 8-12, 1990 meeting in New Orleans, LA: What's happening? P1201 purports to concern itself with the user interface. As of the New Orleans meeting, P1201 comprised .1 (Applications Programming Interface), .2 (Graphical User Interface), .3 (Human-Computer Interaction), and .4 (XLib) subgroups. Working backwards through these, 1201 has recommended that XLib go to ballot directly, a proposal which seems to have so shocked the SEC that they put off deciding on balloting till April. Steve Jobs told the USENIX audience in Phoenix, in June 1987, that X was ``brain- damaged''. Whether that's true or not, X has won, and just putting XLib to a vote makes good sense. 1201.3, under the chairmanship of Richard Seacord, has had a number of interesting discussions and presentations (of which I attended several, though not all). The major problem here is that we are nowhere near knowing what the ``standard'' for an interface might really require. However, the explorations are valuable, and a forum like this can be informative. This leaves me with the GUI and the API. Both in Brussels and in New Orleans were skirmishes in the GUI wars: battalions of employees of OSF its member companies arrayed in opposition to those of UI or USO and theirs, with a pair of observers from NeXT and Apple taking and placing bets on the sidelines. I assure readers that have never attended these meetings, acrimonious backbiting and vituperation are the order of the day in both camps. Though a former employee of OSF, I wouldn't hesitate to condemn the behavior of both sides, but the blame rests elsewhere. Where? In the tourists. See below, but for my money, too many folks like to travel and too many people have caught the ``open systems/open standards'' bug. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update IEEE 1201: User Interface - 2 - So long as the market remains unsettled about Motif, NeXTStep, OPEN LOOK, and Presentation Manager (to say nothing of Apple's MacIntosh interface and IBM's CUA) [Editor: That's ``Common User Application'', a part of SAA.], the meetings of 1201.1 and 1201.2 will serve as tilting grounds, not occasions for useful discussion. >From my point of view, until the market (which means the big boys and the users) has a shake-out, .1 and .2 can only serve as debate platforms or end up recommending standards that are either the intersection of OPEN LOOK and Motif or their union. It might be that .2 can come to some sort of conclusion on the various style guides without .1, but I see the products being waved, not the function banners. Why is it turning out this way? All of this is prologue (``The past is prologue,'' writes Shakespeare in The Tempest) to a commentary on the TCOS-standards industry. [Editor: TCOS, the Technical Committee on Operating Systems, is the IEEE organization under which both 1201 and 1003 fall.] Over the past 40 years, ISO has approved or accepted over 20,000 standards, which concern almost everything imaginable from hockey masks to medical prostheses to the hinging of radar masts on inland- waterway vessels. The standards have arisen in a variety of ways, most emanating from one of the regional or 70-odd national standards bodies. Typically, it has taken from four to ten years to progress from raising a committee to approving a standard. The result of this has been general agreement within the concerned industry prior to the issuance of an international standard. Wall plugs are an excellent example of what happens when the engineers and bureaucrats issue a standard without industry consensus. I am far from convinced that the ever-increasing number of 1003 and 1201 (sub)committees is productive or useful, and embarrassed and appalled at their continuing proliferation. There are currently at least six or seven standards for diskettes. Do we really need that many for graphical user interfaces? I think not. Might we get what happened in the record industry (i.e., 45s for short cuts; 33s for long works and anthologies) if we wait? I think so. Moreover, does the standards process really require more than two or three folks per company? There were 38 in attendance at the ISO/IEC Joint Technical Committee on Application Portability meeting in September (including the secretariat); there were nearly 300 in New Orleans. My perception is that going to a POSIX meeting is a perk. Holding the meetings in Hawaii, New Orleans, and Snowbird does little to dissuade me. The New Orleans host was OSF; the Snowbird host is Unisys. Though the new Unisys is a big entity, I didn't realize they had a site in Snowbird; nor OSF one in New Orleans. January 1990 Standards Update IEEE 1201: User Interface - 3 - C'mon, lets get back to work, not meetings for the holiday or for the sake of meetings. 1003.1 did good, solid work. Some of the other groups are doing work, too. Partying ain't part of it. Bah! January 1990 Standards Update IEEE 1201: User Interface Volume-Number: Volume 19, Number 34 shar.1201.11766 echo X3J11 cat >X3J11 <<'shar.X3J11.11766' From jsq@longway.tic.com Mon Mar 12 08:56:07 1990 Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP id AA01596; Mon, 12 Mar 90 08:56:07 -0500 Posted-Date: 12 Mar 90 13:32:09 GMT Received: by cs.utexas.edu (5.59/1.52) id AA28277; Mon, 12 Mar 90 07:56:01 CST Received: by longway.tic.com (4.22/4.16) id AA07840; Mon, 12 Mar 90 07:32:55 cst From: <usenix.org!jsh@longway.tic.com> Newsgroups: comp.std.unix Subject: Standards Update, ANSI X3J11: C Programming Language Message-Id: <554@longway.TIC.COM> Sender: std-unix@longway.tic.com Reply-To: std-unix@uunet.uu.net Date: 12 Mar 90 13:32:09 GMT Apparently-To: std-unix-archive@uunet.uu.net From: <jsh@usenix.org> An Update on UNIX* and C Standards Activities March 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor ANSI X3J11: C Programming Language Update Doug Gwyn <gwyn@brl.MIL> reports on the state of ANSI C: There is now a C standard After the one appeal of CBEMA X3's approval of the proposed ANSI C standard was eventually voluntarily withdrawn by the appellant, the ANSI Board of Standards Review approved the proposed standard on December 14, 1989. (CBEMA is the Computer and Business Equipment Manufacturers' Association, the organization that sponsors X3.) No appeals were received by ANSI within the time allotted, so there is now an official American National Standard for Programming Language C: ANS X3.159-1989. The technical content of the ANS is identical to that of the December 1988 X3J11 draft. The X3J11 technical committee will enter an "interpretations" mode at the March 1990 meeting in New York City. During this phase, the committee will be considering requests for clarification and interpretation of the standard. It is anticipated that Technical Information Bulletins will be issued from time to time when it is felt that clarification of the intent of the standard needs to be published. Such bulletins would not technically be considered part of the official standard; however, they should provide valuable guidance to both C implementors and C programmers. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1990 Standards Update ANSI X3J11: C Programming Language Volume-Number: Volume 18, Number 66 shar.X3J11.11766 exit