Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1990.04

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

echo intro
cat >intro <<'shar.intro.11766'
From [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: ico.isc.com![e-mail] (Guest Moderator, Jeffrey Haemer)
Reply-To: [e-mail]
Organization: USENIX
Date: 17 Apr 90 22:49:08 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>
From: <[e-mail]>


           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 <[e-mail]> 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    ([e-mail]) or John
       ([e-mail]).  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 [phone].

       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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: ico.isc.com![e-mail] (Guest Moderator, Jeffrey Haemer)
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 17 Apr 90 22:51:28 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


           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 <[e-mail]> 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@[e-mail]>.

       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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Apr 90 04:28:25 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Apr 90 06:52:48 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Apr 90 06:59:32 GMT
Apparently-To: [e-mail]

From: <[e-mail]>

            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Apr 90 04:35:22 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Jan 90 23:44:55 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8: Transparent File Access
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 11 Feb 90 20:33:51 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11: Transaction Processing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Mar 90 21:51:53 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.12: Inter-Process Communication
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Mar 90 21:43:24 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 29 Mar 90 17:56:18 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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 [e-mail]  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![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3J11: C Programming Language
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 12 Mar 90 13:32:09 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            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 <[e-mail]> 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