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 1993 10:54:47 -0500
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
- Procedural question (Re: SIP API spec) Frank T Solensky
- Re: Procedural question (Re: SIP API spec) Frank Kastenholz
- Re: Procedural question (Re: SIP API spec) Frank T Solensky
- Re: Procedural question (Re: SIP API spec) Steve Deering
- Re: Procedural question (Re: SIP API spec) Paul Tsuchiya
- Re: Procedural question (Re: SIP API spec) Carl Beame
- Re: Procedural question (Re: SIP API spec) Frank T Solensky
- Re: Procedural question (Re: SIP API spec) Paul Tsuchiya