Path: utzoo!attcan!uunet!longway!std-unix From: ahby@bungia.bungia.mn.org (Shane P. McCarron) Newsgroups: comp.std.unix Subject: Standards Update, Part 11: IEEE 1003.8; Networking Message-ID: <287@longway.TIC.COM> Date: 1 Jan 89 18:01:24 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Lines: 324 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) [ 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