jsh@usenix.org (02/12/90)
From: <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
January 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.8: Transparent File Access Update
Jason Zions <jason@cnd.hp.COM> reports on the January 8-12, 1990
meeting in New Orleans, LA:
1003.8 breaks up
The networking work has been reorganized; what was one committee is
now five. At this meeting, the Sponsors' Executive Committee (SEC)
approved all the networking Project Authorization Requests (PARs) and
forwarded them to the IEEE Standards Board for final approval. In the
past, 1003.8 was responsible for half-a-dozen types of networking
issues. From now on, 1003.8 will restrict itself to transparent file
access (TFA); the other work will be distributed to four new groups.
The new structure is
Project Name Description
_____________________________________________________
1003.8 TFA Transparent File Access
1003.12 PII or P2P
Protocol Independent
Interfaces, or Process to
Process
1003.13 RPC Remote Procedure Call
12xx PDI
Protocol Dependent Interfaces,
a.k.a. OSI FTAM and ACSE
12yy NS/DS
Name Spaces and Directory
Services, maybe X.500
The SEC tentatively assigned 1200-series numbers to NS/DS and PDI,
because they intend these standards to apply to any operating system,
not just one that's UNIX-like. (There's one exception: NS/DS must
identify the name spaces required by the 1003 standards and determine
some means of managing them.)
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
- 2 -
TFA decides what to do about NFS
The meeting was a landmark for TFA. Until now, no consensus on
overall direction had been achieved. We spent a great deal of time
discussing the philosophy and goals for a Full TFA and Subset TFA, but
no common understanding had been reached in the minds of all members;
we wandered between extremes of, "Full means 1003.1!" and, "But NFS
sure seems to be good enough for users; after all, they're still
buying it."
It became clear that some agreement had to be reached for progress to
be made. Many TFA attendees had never worked on a POSIX committee
before and didn't quite understand the POSIX consensus process, but
after a joint meeting of 1003.1 and TFA, the exact scope and structure
of work were finally hashed out. The group's work items are described
below.
1. Full TFA
This piece will contain minor additions and changes to 1003.1-
1988 to specify its behavior when operating on remote files.
Work will include extending already-defined interfaces (e.g.,
new stat() information), defining new errors, defining failure
and recovery semantics, and so on.
Semantically, a remote file accessed under Full TFA will be
indistinguishable from a local file. A strictly conforming
POSIX application will run completely unaltered in a Full TFA
environment.
2. Subset TFA
This piece will define both a core subset of 1003.1-1988 that
can work correctly over a variety of remote-file-access
protocols ("the Core") and a number of additional, optional
feature sets. The specification will form additional text for
IS 9945-1 (ISO's version of 1003.1).
The intent is to have Subset TFA work on the widest variety of
protocols consistent with a useful Core; if a remote-file-access
protocol is so constraining that any Core based on it would be
too small to support useful applications, it will be excluded.
FTAM, the International Standard File Transfer and Access Method
(IS 8571), will shape decisions about what will go into the
Core, for a variety of reasons.
+ It is the weakest common mechanism for remote file access.
- 3 -
+ The standard has little chance of success at the ISO level
unless it is clearly cognizant of FTAM.
+ Nothing weaker than FTAM is likely to prove useful to
application writers.
+ People are clamoring for a simple interface to FTAM; the
open/read/write/close style of Subset TFA meets that need.
The difference in functionality between the Core and Full
interfaces will be divided into blocks of capabilities (the
"feature sets" mentioned above), which might be provided by
other commonly used file-sharing mechanisms. A Core-conforming
application will be able to inquire (via pathconf()) what
functionality, over and above the Core, is available on a per-
file basis, and alter its behavior accordingly.
The Core will meet an expressed need to know "what doesn't work
right" over common file sharing protocols. For example, Sun
might define NFS's functionality in terms like, "NFS provides
Core Subset functionality, plus the _PC_LOCKING,
_PC_DIRECTORIES, and _PC_TIMES capability sets." An application
programmer could use such a specification to determine exactly
what features of 1003.1-1988 were safe to use in an NFS
environment.
This scheme also permits continued development of remote-file-
access protocols. Any mechanism that supports at least the Core
will conform to the standard. This encourages vendors and
researchers to develop mechanisms that combine the Core and its
options with other advantages (very high performance, very high
robustness, good behavior over WANs, etc.), while giving users a
well-defined interface for applications that will work in all
such environments.
3. A Data-Stream Encoding (DSE) supporting the Full TFA Interface
This will provide the mechanism necessary for interoperation of
client and server systems. 1003.8 will only develop the
encoding; no binding to any particular protocol stack or suite
is planned. (Such bindings will be done by working groups
chartered to develop profiles to satisfy particular needs.)
Work on the DSE will probably not begin for at least another six
months. There are now two existing, proprietary mechanisms that
provide the appropriate functionality: SVR4 RFS and the Andrew
File System (AFS v.3 from Transarc). The committee hopes at
least one (if not both) of these products' DSEs will be released
to POSIX for standardization. If both are, there will probably
be a gun-battle over which to base the standard on.
- 4 -
There was good progress on the first two work items. The group hopes
to have a meaningful draft available by April, and would like to go to
ballot by the end of the year. This quick ballot will help compensate
for the small working group by bringing major ballot objections to the
surface early. (Much coordination with other 1003 working groups,
especially 1003.1, will also help.) The balloting process will
probably be quite lengthy: on the order of 12-15 months.
Volume-Number: Volume 18, Number 52