Dan Shia <dset!> Wed, 01 April 1992 01:58 UTC

Received: from by ietf.NRI.Reston.VA.US id aa03136; 31 Mar 92 20:58 EST
Received: from by NRI.Reston.VA.US id aa02906; 31 Mar 92 21:01 EST
Received: from by NRI.Reston.VA.US id aa02902; 31 Mar 92 21:01 EST
Received: from relay1.UU.NET by with Internet SMTP id <>; Tue, 31 Mar 1992 07:36:36 +0100
Received: from (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14743; Tue, 31 Mar 92 01:35:17 -0500
Received: from dset.UUCP by with UUCP/RMAIL (queueing-rmail) id 013422.424; Tue, 31 Mar 1992 01:34:22 EST
Received: by dset (4.1/SMI-4.0) id AA17461; Tue, 31 Mar 92 00:10:35 EST
Date: Tue, 31 Mar 1992 00:10:35 -0500
From: Dan Shia <dset!>
Message-Id: <9203310510.AA17461@dset>
To: uunet!!
Subject: RE: APLI
Cc: uunet!!, uunet!!, uunet!

On March 17, 1992, Michael A. Petonic wrote:
>I've seen all of these messages dealing with ACSE and the presentation
>layer.  Are people taking into account the APLI (ACSE/Presentation Layer
>Interface) put out by Unix International?

APLI was designed to expose all the capability of ACSE and Presentation layer
protocols. While it is rich in functionalities, it fails to attract
software developers to build useful OSI applications. The complexity of
the APLI requires an in-depth understanding of OSI protocols on the part of
application developers. (I encourage you to read the APLI manual and
try to write a simple program with it.)
Comparing to Socket interface, APLI is an order
of magnitude more complex to use. I don't know how many programmers today
feel comfortable with writing distributed applications using Sockets.
Requiring all application developers to
become OSI protocol experts are simply too demanding.
(I do agree that APLI is a perfect candidate for OSI experts
to implement FTAM and CCR protocols, where all ACSE and Presentation layer
features are needed.)

>It would be yet another mistake if similar functionality were offered
>with differing APIs.  Not that I'm necessarily advocating APLI, but
>it *is* an API.

I totally agree with you that we should not create another API,
which duplicates APLI's functionality.
However, a programmer-friendly API sitting on top of APLI is urgently needed
if we ever want to see many off-the-shelf applications running on top of OSI.
Dan Shia