inline. Dean Willis wrote:
Just one moment. SIP is not a transport protocol as its defined in my book. Although SIP is generic in that it can support lots of applications (conferencing, IVR, gaming, etc.), it is not unbounded. SIP's messages provide semantics common to all applications which require person-to-person communications. That does NOT make it a transport prorotocol for arbitrary data communication.At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote:Orit Levin wrote:The big huge difference I have been trying to point out is that EVENTS DEFINES SEMANTICS, whereas INFO doesnt. MIME provides semantics and syntax that are independent of the type. SIP events provides semantics and syntax that are independent of the package. INFO provides nothing.INFO provides "minimal" but very important semantics: asynchronous data reliably follows the established SIP path.
Huh?
Every new SIP method is reliable, it inherits the SIP transaction state machine for non-invite. Follows the established path? Every in-dialog method would have this property, it is method independent. Asynchronous? You can send any method at any time.
Thus, nothing you have pointed out above is different between INFO and any other new method we might introduce.
I think the key point is that there is a difference between transport protocol semantic and application semantic. The transport protocol semantic expressed in INFO is "Here is some data that will be used by the application. It is not important to the transport protocol, except that the transport protocol is expected to deliver it reliably".
And as for "Just add another method to your SIP stack". Let's say I have a mobile phone and the SIP stack is burned into ROM and exposes only a simplistic transactional API. This is only likely to happen, oh, 100 million times or so over the next two years . . . Now, just exactly how is my BREW or JTME application going to go about extending the SIP stack to support another method? Will the evil wireless operator networks even pass another method? Neither is happening anytime soon, I think . . .The stack has to allow extensibility to pass unknown INFO bodies up to the application for handling. Why this is any different than having extensibility to handle unknown methods up to the application, is a mystery to me.