ahby@bungia.bungia.mn.org (Shane P. McCarron) (01/02/89)
[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information. -mod ]
An update on UNIX|= Standards Activities - Part 11
POSIX 1003.8 Update
December 18, 1988
Shane P. McCarron, NAPS International
1003.8 - Networking Extensions to POSIX
IEEE P1003.8's charter (not yet formally approved by IEEE,
but pending) is to help develop an IEEE POSIX networking
standard. This was the committee's first formal meeting,
and it was devoted mostly to organizational matters,
particularly on setting specific technical goals and how to
divide the work into subcommittees.
This working group has emerged out of the work done by the
/usr/group Technical Committee's subcommittee on networking.
Once this committee has been formally formed, the /usr/group
networking committee will be considered to merge with the
P1003.8 committee, and meet concurrently whenever P1003.8
does. Ultimately, the /usr/group committee is likely to
disband completely in favor of P1003.8.
The charter ("project authorization request", or PAR) was
reviewed briefly:
SCOPE
1. Define Network Services required by portable
applications consistent with existing and emerging
standards such as OSI.
2. Define interfaces to the network services defined
above, and where possible, language and protocol
independent programming interfaces.
3. Identify the requirements for new network
services/protocols and liason with appropriate
standards bodies (national and international) and
interested organizations when appropriate.
__________
|= UNIX is a registered trademark of AT&T in the U.S. and
other countries.
- 2 -
PURPOSE
Define and/or adopt a set of paradigms to permit the
implementation of portable applications in a network
environment.
Areas to be addressed by this committee include:
A. Interoperability between POSIX applications and non-
POSIX applications.
B. Bindings to OSI application layer services.
C. Identification of language requirements not
appropriate to applications portability, and liason
with appropriate standards bodies to ensure that
action is taken where appropriate.
D. The evaluation and definitions, where require, of
binding to lower layer OSI services.
E. The requirements to ensure interoperability among
POSIX-based distributed applications and services.
F. Network Services profile definitions for portable
applications (POSIX).
Subcommittee Organization
A poll was held to find out what the most important topics
were as far as the group was concerned. These turned out to
be: process to process communication, directory services,
network management, transparent file access, and remote
procedure call. Three main subcommittees were formed to
look at some of these tasks. Roughly, these committees were
"interprocess communication", "remote procedure call", and
"transparent file access".
Directory services and network management were recognized as
important, but also as cutting across other functional
areas. Also, it was noted that there were not in attendance
enough people with sufficient expertise in these topics to
form a useful body of opinion on proposals in these areas.
Transaction processing was generally felt to be within the
domain of the committee, but as a special case of remote
procedure call. It was noted that others who were not on
the committee may feel otherwise.
The committee split up into subcommittees for a day to
refine the definitions of the most important end products
- 3 -
identified for the committee to concentrate on.
Specific Technical Goals
The following is a summary of what the committee as a whole
agreed on as a result of the input from the individual
subcommittees.
o+ Transparent File Access
It was decided that the products should be client-only
interfaces. Three products were identified:
1. Full POSIX-semantic transparent file access
interface. This would include previous
/usr/group DFS Committee work on DFS (distributed
file system).
2. Administrative interface to support (1).
3. Subset-semantic transparent file access
interfaces. This could be vendor (e.g., MS-DOS,
Apple, etc.) or protocol (e.g., FTAM) specific.
Work items identified so far include:
1. Definition of file operations
2. Liason to system administration; definitions of
transparent file access specific system
administrative utilities and/or interfaces
3. Liason with directory working group
4. "Appropriate approach" to the protocol invention
problem
This group expects to finish relatively quickly (6
months or so was the estimate given), because it was
felt that a significant amount of the work needed to
produce standards in this area is already done by
definition (the P1003.1 standard).
o+ Remote Procedure Call:
The RPC folks apparently did not define their charter
so much as identify issues that need to be addressed.
The following was their list of issues along with
tentative resolutions (if any):
- 4 -
1. Level of service
2. POSIX-to-POSIX versus POSIX-to-other (address
POSIX-to-other)
3. Language binding (initial target: C)
4. TP support
5. Connection re-use
6. Call-back/recursion
7. Compiler language
8. Data canonicalization
9. Authentication
10. Our scope versus X.500
11. Standard suite of services need to confer with
X3T5 on possible charter issues
12. Idempotency - execute once only guaranteed
13. Long running processes - keepalive/timeouts
probably needed
14. Crash recovery
15. Real Time issues - no real time interface
16. Directory services
17. Multiple protocol stacks
The subgroup chose not to identify the next step in the
process (apparently meaning that they will wait for
proposals).
o+ Interprocess Communication:
Four products were identified:
1. Simple Protocol-Independent Network Interface
Features:
* Bidirectional byte stream virtual circuits
- 5 -
* Connectionless message exchange
* Read/write support
* Protocol-independent naming
* Asynchronous communication services
* Support for both client and server processes
* POSIX-to-non-POSIX support
Issues:
* How to resolve names in a protocol-independent
manner?
* What should the individual functions look like?
2. Simple Structured Data Network Interface
Features:
All of (1), with extensions for data description
and machine-independent representation.
* Description of the syntactic structure of the
data; when you send the data, you reference the
structure.
* Not all functions from (1) may work (such as,
read/write)
Issues:
* Structure alternatives: ASN.1, ...
* C data structures (stub compilers)
3. Protocol-Option-Extended Network Interface
Features:
* Provides the ability to access protocol
dependent options
* Migration path to potential future protocols
* POSIX-to-any
- 6 -
* Virtual circuits, datagrams
Issues:
* Limited lifespan (?)
* Limited utility
* Usefulness as a migration tool
* Relationship to (1)
4. OSI application level interface
Features:
* A family of interfaces with consistent style and
syntax which provides OSI application level
services, e.g. FTAM, VT, ACSE, ROSE, ...
Issues:
* Complexity
* Prioritization (which ones to focus on first)
One issue that surfaced very quickly in the network IPC
discussions was the differences and relative merits of
sockets and XTI. Some went as far as to say that the
differences were significant enough to guarantee
"religious wars" over the issue, and/or make any kind
of progress impossible in the area of product (3).
Whatever the cause, a majority (8/0/3/3) of
participants expressed interest in working on product
(1), with products (3) and (4) having a relatively weak
level of interest.
The committee will get down to serious business at the
next meeting (in January; 5 days). For the next
meeting, proposals are being solicited in all areas.
The Usenix Standards Watchdog Committee contact on this
committee is Stephen Head. He can be reached at:
Stephen Head
Hewlett Packard
263 Mackintosh St.
Fremont, CA 94539
+1 (408) 447-2740
smh@hpda.hp.com
uunet!hpda!smh
Volume-Number: Volume 15, Number 54