Re: Procedural question (Re: SIP API spec)

Frank T Solensky <solensky@andr.ub.com> Thu, 28 January 1993 15:56 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06284; 28 Jan 93 10:56 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06280; 28 Jan 93 10:56 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa14288; 28 Jan 93 10:58 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10368; Thu, 28 Jan 93 07:55:33 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA24966; Thu, 28 Jan 93 07:56:56 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA07702; Thu, 28 Jan 93 07:55:21 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA13553; Thu, 28 Jan 93 07:56:58 PST
Received: from ub-gate.UB.com by Sun.COM (4.1/SMI-4.1) id AA10358; Thu, 28 Jan 93 07:55:19 PST
Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA04123; Thu, 28 Jan 93 07:54:51 PST
Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA19246; Thu, 28 Jan 93 10:55:01 EST
Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA09418; Thu, 28 Jan 93 10:54:47 EST
Date: Thu, 28 Jan 93 10:54:47 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank T Solensky <solensky@andr.ub.com>
Message-Id: <9301281554.AA09418@fenway.andr.UB.com>
To: Bob.Gilligan@eng.sun.com, beame@ns.bws.com, ip-encaps@sunroof.eng.sun.com, sip@caldera.usc.edu
Subject: Re: Procedural question (Re: SIP API spec)
Content-Length: 1129

>From: Carl Beame <beame@ns.bws.com>
>
>	One reason I have decided to back and impliment SIP/IPAE is the
>fact that the "(BIP)" was a fixed length and not a veriable length address.
>This is very important when implimenting in a PC-DOS environment. If we try
>to use a general specification we will have to make the calling structures
>more complex then they would need to be for just SIP.

Carl --
	I should clarify: the RFC would describe the API issues in generic
terms (as opposed to describing "a generic API") -- basically a suggestion
for the things that people should start looking for in the code without
telling them exactly what it'll be changed to.  It might also include
sub-sections that describe how the APIs would differ under each proposal,
rather than "one API fits all".  While it might be nice to be able to
accomplish the latter for maintenance's sake,  I'd agree with you: the "real
world" wouldn't appreciate taking a performance hit for it every time.
	Once there's consensus on what IPv7 will be, the RFC would be 
obsoleted by another that would have the details of the others removed.
							-- Frank