Subject: Re: [Sip] INFO considered harmful

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Jan 2003 16:05:19 -0500

inline.

Dean Willis wrote:
> 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". 

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.

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

-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

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Fri, 3 Jan 2003 15:37:29 -0600

> transport prorotocol for arbitrary data communication.

Well, I think that's exactly where we disagree, and I believe that the vast
majority of people using SIP think of it a lot more like I do. At least the
ones in 3G-space seem to.

Here's what I think I believe:

SIP provides for the establishment of a session (dialog) between two or more
end points, optionally intermediated by proxies, and the exchange of
information between those end points. This information is applied by
applications to provide application functionality. SIP provides several
methods for relaying application information, including relaying a text
message, requesting notification of changes in the state of a named element,
reporting a change in the state of some named element, and so on. It is
either a historical accident that the dialog-initiation request (INVITE) is
non-transparently overloaded with media session negotiation OR that the
media session negotiation method (INVITE) establishes a dialog on which
other requests may be relayed. 

> extensibility to handle unknown methods up to the application, is a 

Nope. There's no extension required to the protocol stack to deliver one
type of MIME body versus deliverying another type of MIME body. It's just a
vyte-vector in a buffer. Otherwise, we'd be rewriting sendmail and httpd
every 47 minutes to support a new body type.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 17:13:29 -0500

INFO = BEEP-like functionality over SIP :-)?

To amplify one part of what Dean said: Part of the functionality that an 
SDP-negotiated channel does not (readily) provide is different degrees 
of specificity. In SDP, I have to include a single IP address or an 
A-record. In SIP, Contact can be significantly more general, since it 
allows different degrees of binding detail and much more resolution 
functionality (SRV, NAPTR), including using the same old generic address 
that started the session and thus redoing the resolution with every 
request. This makes life much easier for sparse sessions with user 
mobility (same user, different device). This matters less when you 
already have a set of media sessions that need to be re-negotiated 
anyway when things change.