Re: Procedural question (Re: SIP API spec)

Steve Deering <deering@parc.xerox.com> Wed, 27 January 1993 17:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07745; 27 Jan 93 12:25 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07735; 27 Jan 93 12:25 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa17636; 27 Jan 93 12:27 EST
Received: from Eng.Sun.COM (engmail1-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26688; Wed, 27 Jan 93 09:25:34 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02749; Wed, 27 Jan 93 09:26:56 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA20425; Wed, 27 Jan 93 09:24:04 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA02623; Wed, 27 Jan 93 09:25:30 PST
Received: from alpha.xerox.com by Sun.COM (4.1/SMI-4.1) id AA26519; Wed, 27 Jan 93 09:24:00 PST
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11865>; Wed, 27 Jan 1993 09:23:40 PST
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 27 Jan 1993 09:23:30 -0800
To: kasten@ftp.com
Cc: Bob.Gilligan@eng.sun.com, ip-encaps@sunroof.eng.sun.com, sip@caldera.usc.edu, deering@parc.xerox.com
Subject: Re: Procedural question (Re: SIP API spec)
In-Reply-To: Your message of "Wed, 27 Jan 93 08:33:16 PST." <9301271633.AA10868@ftp.com>
Date: Wed, 27 Jan 1993 09:23:19 PST
X-Orig-Sender: Steve Deering <deering@parc.xerox.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <93Jan27.092330pst.12171@skylark.parc.xerox.com>
Content-Length: 1003

> Making any interface specification a part of the standard, either a
> generic one as you suggest, or a specific one as was recently posted
> to the SIP list, is a very very bad idea.

Frank K.,

I don't think Frank S. said anything about the API being a "standard",
in the sense of an IETF protocol standard.  The SIP API spec. proposes
an interface to SIP for BSD-socket-based systems, so that SIP-capable
applications might be portable from one such system to another.
Frank S. suggested that the spec be generalized for any New IP.
Sounds like a reasonable idea to me.  Similar APIs also be useful for
other types of networking systems (Streams, Mac, MS Windows, etc.).
Of course, developers are free to ignore such APIs if they don't care
about application portability among like systems from different vendors.

Note that the API is *not* the same as the "service definition".  As you
pointed out, a platform-independent service definition should be part
of any New IP protocol standard.

Steve