IETF Logo Mail Archive

Re: SIP API spec

Bob Gilligan <Bob.Gilligan@eng.sun.com> Thu, 28 January 1993 00:13 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06942; 27 Jan 93 19:13 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06938; 27 Jan 93 19:13 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa06167; 27 Jan 93 19:16 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25896; Wed, 27 Jan 93 16:14:04 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05653; Wed, 27 Jan 93 16:15:20 PST
Received: from bigriver.Eng.Sun.COM (bigriver-248) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA20590; Wed, 27 Jan 93 16:13:49 PST
Received: from kandinsky.Eng.Sun.COM by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA07128; Wed, 27 Jan 93 16:07:28 PST
Date: Wed, 27 Jan 1993 16:07:28 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bob Gilligan <Bob.Gilligan@eng.sun.com>
Message-Id: <9301280007.AA07128@bigriver.Eng.Sun.COM>
To: ip-encaps@sunroof.eng.sun.com, sip@caldera.usc.edu
Subject: Re: SIP API spec
Content-Length: 1434

> Subject: Re: SIP API spec 
> Date: Tue, 26 Jan 93 18:51:18 +0100
> From: Christian Huitema <Christian.Huitema@sophia.inria.fr>
> 
> . . . Which is why I find
> Bob's spec entirely acceptable -- it merely says "here are the bits that
> should go in the next packets". A service that most implemenatations will be
> able to fulfill!

That is what I had in mind.  This option is just supposed to tell the SIP
layer how to fill in the flow ID field in transmitted packets.  The
intention here was that this option would be experimental (more experimental
than the rest of the implementation!).  I'll make the next rev of the draft
more clear about this.

Since the header field we are talking about is officially named "reserved",
perhaps we should name this setsockopt() option SIP_RESERVED_FIELD.

> Date: Wed, 27 Jan 93 18:31:20 -0500
> From: jnc@ginger.lcs.mit.edu (Noel Chiappa)
>  . . .
> I am getting the feeling that this specification is being thrown together
> in a real hurry in an attempt to 'win' some competition. I can't help but
> feel that this is the wrong road to take to produce a great design....

Actually, we felt the need to write up the API spec because we were
approaching the point where we would have two independent SIP
implementations based on BSD unix and we didn't want the two
implementors to pick different APIs.  I suspect the API will change as
we get experience converting applications to use SIP.

v2.23.0 | Report a Bug | By Email