Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!uunet.UU.NET!sef
From: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Report on 1003.12: Protocol Independent Interfaces
Message-ID: <1991Jun29.074743.17652@uunet.uu.net>
Date: 29 Jun 91 03:34:15 GMT
References: <1991Jun27.024928.6997@uunet.uu.net>
Sender: usenet@uunet.uu.net (UseNet News)
Organization: IR
Lines: 53
Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix)
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net

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