RE: [Sip] INFO considered harmful

["George Foti (LMC)" <George.Foti@ericsson.ca>]

The requirement is to be able to send application data transperently e2e via the SIP proxies, without impacting the SIP state machine.
It is as simple as that.

INFO fulfills that requirement.

1) To suggest that this is an abuse of INFO as it permits SIP to be used as transport is simply bogus.

This will be the case with any other proprietary method, anyways. So there is simply no teeth in this argument. 
No wireless device will maintain X methods simply to be able to communicate with x ASs belonging to X vendors.
It is simply not a workable solution. This is not about coding. 
This just does not make sence, and serves no purpose other than shear control of what goes in INFO, or the likes.

2) To claim that INFO has no semantics so it is useless simply does not work either.
The requirment calls precisely for that.
We *dont want* semantics associated with INFO. It is e2e and transperent.
Any suggestion to try and standardize what should be carried in INFO or whatever else is doomed to failure.

3) To suggest that MESSAGE can be used instead of INFO, so what have we solved ???

So far, the so claimed harm has not been spelled whatsoever.
It sounds like a philosophical harm.

Deprecating INFO or limiting its use, will create more interoperability problems, without solving anything.
Bodies like 3GPP will not buy into that.

I think that before we shoot ourselves in the leg, come up with the requirements and proposals.
Then and only then we can decide what should be done with INFO.

Rgds/gf  


 



 



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, December 30, 2002 4:50 PM
To: Dean Willis
Cc: sip@ietf.org
Subject: Re: [Sip] INFO considered harmful


inline.

Dean Willis wrote:
>>The point I was making in the draft was - why bother? INFO by itself 
>>provides nothing. If you want differentiable, negotiable and 
>>well-documented things, define them as new methods. What does 
>>INFO give 
>>you beyond that?
> 
> 
> The ability to define a new usage without having to make code changes to
> one's SIP stack, just as Events allows.

Code to handle INFO goes somewhere.

> 
> SIP, as you may have noticed, is a fairly complicated protocol. This has
> given rise to the distribution of reusable (even open source) SIP stacks.
> Personally I'm not up to hacking a new method (into, say, the Vovida stack)
> everytime I want to deliver a new type of blob. INFO, constructed as I've
> proposed, would let me implement a new INFO package on a stack without
> having to rewrite the stack. 

How is this different from allowing new methods, and passing off 
handling of that method to registered callbacks for each method?? Not 
different at all.


> We'd just need an API to tell the stack what
> INFO packages we handled at the application layer, 

Or, you could have an API to tell the stack what methods are handled.

> and it could do the rest
> of the work without caring what data is being transported in the INFOs.

What work?? There is no semantics associated with INFO. None. Zero. 
Nada. Zip.

> Events, you may have noticed, has exactly this property.

The big huge difference I have been trying to point out is that EVENTS 
DEFINES SEMANTICS, whereas INFO doesnt.



> 
> At some level, this is comparable to the "Why do we use MIME instead of
> defining a new transport protocol for each and every possible type of data"
> argument.

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.

> 
> At its heart, INFO is for delivering APPLICATION SPECIFIC DATA within a
> dialog. The SIP state machine does not have to care about that data, just
> its delivery (although, as with SIP-T, the application itself may use the
> data to influence the SIP state machine via the stacks's APIs). If SIP were
> a proper transport protocol, we wouldn't have to define protocol extensions
> for every application-specific datum.

SIP is not a protocol for shipping data between applications. I do not 
think we should encourage the arbitrary transport of stuff in SIP.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     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 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