[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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