Dean Willis wrote:
There is a deep philosophical divide about how the SIP protocol should be formed and extended. One branch of this debate holds that SIP's role is as a transport protocol with a very few primitives and application logic handled at the data level. In this model, new applications can generally be built without changing the protocol or its syntax. The second branch holds that the SIP protocol itself should be intimately tied to the application, with new functionality represented as new message types. Yet another branch of the debate holds that SIP is only for setting up and tearing down "sessions", and that information outside of that needed to set up or tear down a "session" is rightfully part of the "session" and not in the domain of the SIP protocol itself.
I would argue that SIP *is* an application protocol - supporting 'multimedia communications'. Its implementation takes many forms - softphones, hardphones, gateways, and so on, but still it is all about multimedia communications.
Consequently, the notion of an additional layer *above* SIP, something beyond the UI, something that has behaviors that are fundamentally different (and NOT compatible) with other applications that might reside above SIP, is foreign to the design of SIP, and something that is dangerous. It is this thinking that will lead us to highly segmented uses of SIP, none of which are well defined or interoperable. Very reminiscent of the 'service ID' discussions in sipping, in fact.
-Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
