Re: Procedural question (Re: SIP API spec)

Frank Kastenholz <kasten@ftp.com> Wed, 27 January 1993 16:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06507; 27 Jan 93 11:37 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06503; 27 Jan 93 11:37 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa15528; 27 Jan 93 11:39 EST
Received: from Eng.Sun.COM (engmail1-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA20021; Wed, 27 Jan 93 08:37:31 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27619; Wed, 27 Jan 93 08:38:53 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA20408; Wed, 27 Jan 93 08:36:04 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA27497; Wed, 27 Jan 93 08:37:29 PST
Received: from ftp.com (babyoil.ftp.com) by Sun.COM (4.1/SMI-4.1) id AA19850; Wed, 27 Jan 93 08:35:57 PST
Received: by ftp.com id AA10868; Wed, 27 Jan 93 11:33:16 -0500
Date: Wed, 27 Jan 93 11:33:16 -0500
Message-Id: <9301271633.AA10868@ftp.com>
To: solensky@andr.ub.com
Subject: Re: Procedural question (Re: SIP API spec)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@ftp.com>
Reply-To: kasten@ftp.com
Cc: Bob.Gilligan@eng.sun.com, ip-encaps@sunroof.eng.sun.com, sip@caldera.usc.edu
Content-Length: 1429

Frank,

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. At least as far as the IETF
goes. The SIP API spec was written as a BSD-Socket interface. What about
those environments that use Streams? What about environments that use
their own interfaces -- where neither Sockets nor Streams are available?

At most, the specs for the various protocols should define what services
are available to the users (see Section 3.8 "Interfaces", pp 44, of RFC793).

 >         I've been thinking: most of the transition issues with all of the
 > major IPv7 proposals need to deal with similar changes at the API level.
 > (I had also indicated to the TUBA group at the last IETF that I'd write a
 > similar spec from a perspective outside of any one of the proposals, but the
 > day job tends to get in the way).
 > 
 >         What I'd like to suggest is that this document serve that purpose:
 > instead of referencing SIP specifically, we could refer to a "Better
 > Internet Protocol (BIP)" and only refer to specific proposals as needed.
 > 
 >         Before getting down to the details on how this would affect the spec,
 > I thought I'd just mention this idea first to see what the general consensus
 > was..
 >                                                         -- Frank
 > 


--
Frank Kastenholz