Subject: RE: [Sip] INFO considered harmful

From: Orit Levin <[email-masked]>
Date: Mon, 30 Dec 2002 17:57:43 -0500

Inline.

Orit.

> 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.

Another solution would be to have each pair of UAs registered to each
other's event packages (and using EVENTs minimal semantics only).

Would it be the preferred way to go???

_______________________________________________
Sip mailing list  https://www1.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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Dec 2002 00:48:47 -0500

> 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.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Dec 2002 00:48:26 -0600

At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote:
>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