RE: [Sip] INFO considered harmful

["Eric Burger" <eburger@snowshore.com>]

I fully agree with Dean on this one.

One point to consider (I'm on the fence on this one) is whether we would say that INFO is 100% application-specific.  That is, the WG will not publish standard body types.

A reason for doing that is to let people know that INFO really is just, as Dean points out, application-to-application communication.  If you want applications to interoperate, take it either to an Application Area WG or take it outside the IETF.

One reason to not do this is SIP-T should use a method other than INFO.  That said, I don't think there are that many SIP-T implementations extant.


> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, December 31, 2002 1:48 AM
> To: Jonathan Rosenberg; Orit Levin
> Cc: sip@ietf.org
> Subject: Re: [Sip] INFO considered harmful
> 
> 
> 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". INFO 
> says NOTHING 
> about the APPLICATION level semantic -- that's up to what 
> goes IN the INFO 
> payloads. The question is -- do we try to rigidly define 
> application-level 
> semantics here? Do we define that there ARE no such 
> applications possible? 
> Or do we design a framework by which application-level 
> semantics can be 
> expressed outside of the protocol definition?
> 
> 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 . . .
> 
> --
> Dean
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip