pc@hillside.co.uk (Peter Collinson) (06/27/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) USENIX Standards Watchdog Committee Stephen R. Walli <stephe@usenix.org>, Report Editor Report on 1003.12: Protocol Independent Interfaces Mike Karels <karels@cs.berkeley.edu> reports on the April 15-19, 1991 meeting in Chicago, IL: Summary The POSIX.12 (Protocol Independent Interfaces, PII) working group spent the April meeting planning strategy for its new direction and coordinating with other groups. The group will produce a standard encompassing both the BSD sockets and X/Open Transport Interface (XTI). Liasison meetings were held with X/Open representatives, the Name Space/Directory Services group (POSIX.17) and the Real-Time group (POSIX.4). The group discussed language independent specification issues with Paul Rabin. Report POSIX.12 (Protocol Independent Interfaces, PII) spent the April meeting adjusting to its new direction and coordinating with other groups. At the last meeting, the group decided to abandon its previous strategy of producing a new Detailed Network Interface (DNI) with the best features of both the socket and X/Open Transport interfaces (XTI). XTI is derived from AT&T's Transport Level Interface (TLI). After reviewing input from users and vendors, the group decided instead to produce a standard including both existing interfaces. In addition, the standard will include the Simple Network Interface (SNI), which would insulate the programmer from lower-level details. The April meeting included discussions of the changes or additions that were needed for the existing interfaces to become standards. A poll had been sent to several mailing lists and news groups, but few concrete suggestions were received. Most of the suggestions for extensions have come from inside the working group. Suggestions for changes in sockets have come mostly from the Berkeley representatives, and suggestions for XTI have come mainly from people active in the X/Open technical community. A fair amount of time was devoted to the proposal for extending XTI option management by Gerhard Kieselmann. The proposal allows much more flexible option management by encoding option values with types and lengths. The encoding is similar to the encoding of ancillary data in the 4.3-Reno send and receive calls. The main point of contention was whether the transport provider should maintain both current settings and default settings to be used for any future connections. The discussions of extensions to the socket interface was confined to a description of the recent Berkeley changes (4.3-Reno) to the socket interface. The meeting schedule was nearly filled with coordination meetings with other groups. Petr Janacek of X/Open reported on the status of future XTI specifications. Other than the option management proposal mentioned above, the XPG4 version of XTI has been finalized. It is hoped that the XPG5 version of XTI would be aligned with the POSIX version. At the last meeting, POSIX.12 asked X/Open for editorial assistance in producing a POSIX version of XTI. Petr replied that the budget did not allow for assistance at this time, but that an on-line version of XTI would be made available. Paul Rabin met with the PII group to discuss issues surrounding POSIX language independent specifications. The working group currently hopes to produce a single language independent specification for DNI; there would be two C language bindings, namely sockets and XTI. This should prevent the necessity of providing two interfaces for languages other than C, but makes the language independent specification more difficult to produce. The POSIX.12 group also met with members of the Name Space/Directory Services group (POSIX.17) to discuss the DNI dependency on the Directory Services interfaces. There are some problems in this area; the NS/DS group currently intends to provide an interface only to the X.500 directory service, while the PII group assumes an interface that could include other services such as the Internet Domain Name System. The NS/DS group intends to provide a full-featured low-level interface to the directory service based on the X/Open X.500 API. However, they also plan to include simplified higher-level interfaces to answer needs such as this one. The final coordination meetings were with members of the Real-Time group. The current Real-Time draft includes an interprocess communication (IPC) facility that many believe is too complex and does not extend gracefully to handle networked systems. Many hoped that the IPC interface could be replaced by the 1003.12 interface, with real-time extensions as necessary. A group is working on a straw-man proposal in time for the July meeting. Volume-Number: Volume 24, Number 26
brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) (06/29/91)
Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) People interested in protocol-independent interfaces may also be interested in UCSPI (ooks-pie), my UNIX Client-Server Program Interface Standard. It's not a standard, of course, until enough people decide it's worth using, but it does have implementations for BSD TCP sockets (with optional RFC 931 support), BSD UNIX-domain sockets (with username security), and System V named pipes (also with username security), and I'm working on DECnet and Kerberos v5 implementations. Programs written for the UCSPI interface will work properly, with no changes, over all of the above communications systems. Note that the UCSPI interface is much simpler than what I gather POSIX is looking at standardizing. Basically, you get two file descriptors for reading and writing to the other side, a protocol-independent record of who the other side is, and a variable saying what protocol you're using. It doesn't support any sort of structured data, because that wouldn't be portable---you can't pass structured data through named pipes. Another benefit to this hands-off philosophy is that you can use UCSPI from shell scripts. On the other hand, if you do want to control the communication at a low level, you can apply protocol-dependent operations to the descriptors. If UCSPI gains enough momentum, it might be worth making into an official standard in a few years. Until then, I wonder why POSIX.12 is trying to impose ``standards'' on an area where the real world has seen neither successes nor failures. Where are the bad protocol-independent interfaces in the history books? What do we know about putting good ones together? Where are all the vendors supporting a protocol-independent interface? In other words, how does POSIX.12 know it's not going to settle on a ``standard'' which forever stands in the way of interface research? If POSIX.12 merely produces a formal specification of how Berkeley and AT&T already do sockets, then the answer is clear: the industry has come to a consensus on sockets, people use sockets, and nothing's lost by stating the obvious. But sockets are not truly protocol-independent, and from the report I gather that the group aims to create a much more comprehensive interface. What, pray tell, are they basing their work on? Anyway, I just posted my clientserver package, including UCSPI-91, to alt.sources. You can also get it from stealth.acf.nyu.edu in pub/hier/clientserver/*. Please send any comments (or implementations on top of different protocols) to me at brnstnd@nyu.edu. ---Dan [ I posted this because it contains not only an objection to a POSIX document, but a codified alternative. However, it was iffy; any followups more concerned with the code than with standards should to go alt.sources.d. Thanks -- mod ] Volume-Number: Volume 24, Number 31