Standards Update, IEEE 1003.8: Transparent File Access

[jsh at usenix.org]

From: <jsh at usenix.org>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.8: Transparent File Access Update

Jason Zions <jason at cnd.hp.COM> reports on the January 8-12, 1990
meeting in New Orleans, LA:

1003.8 breaks up

The networking work has been reorganized; what was one committee is
now five.  At this meeting, the Sponsors' Executive Committee (SEC)
approved all the networking Project Authorization Requests (PARs) and
forwarded them to the IEEE Standards Board for final approval.  In the
past, 1003.8 was responsible for half-a-dozen types of networking
issues.  From now on, 1003.8 will restrict itself to transparent file
access (TFA); the other work will be distributed to four new groups.
The new structure is

Project   Name         Description
_____________________________________________________
1003.8    TFA          Transparent File Access
1003.12   PII or P2P

                       Protocol Independent
                       Interfaces, or Process to
                       Process
1003.13   RPC          Remote Procedure Call
12xx      PDI

                       Protocol Dependent Interfaces,
                       a.k.a. OSI FTAM and ACSE
12yy      NS/DS

                       Name Spaces and Directory
                       Services, maybe X.500

The SEC tentatively assigned 1200-series numbers to NS/DS and PDI,
because they intend these standards to apply to any operating system,
not just one that's UNIX-like.  (There's one exception: NS/DS must
identify the name spaces required by the 1003 standards and determine
some means of managing them.)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.



                                - 2 -

TFA decides what to do about NFS

The meeting was a landmark for TFA.  Until now, no consensus on
overall direction had been achieved.  We spent a great deal of time
discussing the philosophy and goals for a Full TFA and Subset TFA, but
no common understanding had been reached in the minds of all members;
we wandered between extremes of, "Full means 1003.1!" and, "But NFS
sure seems to be good enough for users; after all, they're still
buying it."

It became clear that some agreement had to be reached for progress to
be made.  Many TFA attendees had never worked on a POSIX committee
before and didn't quite understand the POSIX consensus process, but
after a joint meeting of 1003.1 and TFA, the exact scope and structure
of work were finally hashed out.  The group's work items are described
below.

  1.  Full TFA

      This piece will contain minor additions and changes to 1003.1-
      1988 to specify its behavior when operating on remote files.
      Work will include extending already-defined interfaces (e.g.,
      new stat() information), defining new errors, defining failure
      and recovery semantics, and so on.

      Semantically, a remote file accessed under Full TFA will be
      indistinguishable from a local file.  A strictly conforming
      POSIX application will run completely unaltered in a Full TFA
      environment.

  2.  Subset TFA

      This piece will define both a core subset of 1003.1-1988 that
      can work correctly over a variety of remote-file-access
      protocols ("the Core") and a number of additional, optional
      feature sets.  The specification will form additional text for
      IS 9945-1 (ISO's version of 1003.1).

      The intent is to have Subset TFA work on the widest variety of
      protocols consistent with a useful Core; if a remote-file-access
      protocol is so constraining that any Core based on it would be
      too small to support useful applications, it will be excluded.

      FTAM, the International Standard File Transfer and Access Method
      (IS 8571), will shape decisions about what will go into the
      Core, for a variety of reasons.

         + It is the weakest common mechanism for remote file access.



                                - 3 -

         + The standard has little chance of success at the ISO level
           unless it is clearly cognizant of FTAM.

         + Nothing weaker than FTAM is likely to prove useful to
           application writers.

         + People are clamoring for a simple interface to FTAM; the
           open/read/write/close style of Subset TFA meets that need.

      The difference in functionality between the Core and Full
      interfaces will be divided into blocks of capabilities (the
      "feature sets" mentioned above), which might be provided by
      other commonly used file-sharing mechanisms.  A Core-conforming
      application will be able to inquire (via pathconf()) what
      functionality, over and above the Core, is available on a per-
      file basis, and alter its behavior accordingly.

      The Core will meet an expressed need to know "what doesn't work
      right" over common file sharing protocols.  For example, Sun
      might define NFS's functionality in terms like, "NFS provides
      Core Subset functionality, plus the _PC_LOCKING,
      _PC_DIRECTORIES, and _PC_TIMES capability sets." An application
      programmer could use such a specification to determine exactly
      what features of 1003.1-1988 were safe to use in an NFS
      environment.

      This scheme also permits continued development of remote-file-
      access protocols.  Any mechanism that supports at least the Core
      will conform to the standard.  This encourages vendors and
      researchers to develop mechanisms that combine the Core and its
      options with other advantages (very high performance, very high
      robustness, good behavior over WANs, etc.), while giving users a
      well-defined interface for applications that will work in all
      such environments.

  3.  A Data-Stream Encoding (DSE) supporting the Full TFA Interface

      This will provide the mechanism necessary for interoperation of
      client and server systems.  1003.8 will only develop the
      encoding; no binding to any particular protocol stack or suite
      is planned.  (Such bindings will be done by working groups
      chartered to develop profiles to satisfy particular needs.)

      Work on the DSE will probably not begin for at least another six
      months.  There are now two existing, proprietary mechanisms that
      provide the appropriate functionality: SVR4 RFS and the Andrew
      File System (AFS v.3 from Transarc).  The committee hopes at
      least one (if not both) of these products' DSEs will be released
      to POSIX for standardization.  If both are, there will probably
      be a gun-battle over which to base the standard on.



                                - 4 -

There was good progress on the first two work items.  The group hopes
to have a meaningful draft available by April, and would like to go to
ballot by the end of the year.  This quick ballot will help compensate
for the small working group by bringing major ballot objections to the
surface early.  (Much coordination with other 1003 working groups,
especially 1003.1, will also help.) The balloting process will
probably be quite lengthy: on the order of 12-15 months.

Volume-Number: Volume 18, Number 52