Subject: RE: [SIP] SIP Message segmentation problem over TCP

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 2 Jul 2001 13:39:55 -0400

Okay, let's rein this one in folks.

SIP is what it is, and we are not likely to change the
way it works (and it DOES work).

Unless there is anything much more substantive, let's leave
this thread die.

Brian

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Monday, July 02, 2001 1:15 PM
> To: Paul E. Jones
> Cc: [email-masked]; [email-masked]
> Subject: Re: [SIP] SIP Message segmentation problem over TCP
> 
> 
> You said "TPKT (RFC 1006) would have been the logical thing 
> to do". This
> implies SIP is doing something less logical wouldn't you say?
> 
> SIP clearly puts cleanliness and simplicity above efficiency. 
> I believe
> it's fair to say that this has proven to be a winning strategy for
> protocol design.
> 
> Anders
> 
> 
> "Paul E. Jones" wrote:
> > 
> > Anders,
> > 
> > I didn't say it was illogical: it's just inefficient.
> > 
> > Paul
> > 
> > ----- Original Message -----
> > From: "Anders Kristensen" <[email-masked]>
> > To: "Paul E. Jones" <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Monday, July 02, 2001 11:47 AM
> > Subject: Re: [SIP] SIP Message segmentation problem over TCP
> > 
> > > SIP is based on HTTP and you can blame HTTP for this 
> particular aspect
> > > of SIP. Using a Content-Length header is perfectly logical, BTW.
> > >
> > > Cheers,
> > > Anders
> > >
> > >
> > > "Paul E. Jones" wrote:
> > > >
> > > > Chandra,
> > > >
> > > > TPKT (RFC 1006) would have been the logical thing to 
> do.  However, as
> > SIP is
> > > > an ASCII-based protocol, which requires the parsers to 
> look though long
> > > > strings like "Content-Length" for information (then 
> perform expensive
> > > > arithmetic in order to actually calculate the length in 
> this case),
> > using
> > > > TPKT would look like a "kludge" in the protocol.
> > > >
> > > > While the IETF has a history of engineering more 
> efficient protocols,
> > SIP
> > > > was not engineered with processing efficiency in mind.
> > > >
> > > > Paul
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementor's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to
> > > [email-masked] with "subscribe" 
> in the body.
> > >
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip