Subject: RE: [Sip] INFO considered harmful

From: Orit Levin <[email-masked]>
Date: Sat, 28 Dec 2002 16:49:11 -0500

I (also) vote for the direction #2 from the draft (i.e. convert INFO into a
proper framework).

I don't like using neither SIP Events nor INFO as general mechanisms for
implementing applications only because they happened to be collocated with
an existing SIP stack.

I do think that both mechanisms are very useful for features closely related
to the SIP call control (once these features are well-defined and
standardized). An alternative would be maintaining an expensive separate
transport channel for each of the light and complementary to the call
control applications...

On a different note, I would like to stress out that in general events vs.
requests (when properly applied) would be different in semantics. In other
words, it doesn't make sense for certain applications to use events and vs.
versa. Each mechanism stands on its own and both are required. 

Orit Levin
Chief Architect
RADVISION
Phone: +1.201.6896330
Video: +1.201.6896430

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Saturday, December 28, 2002 1:29 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Sip] INFO considered harmful
> 
> 
> 
> Jonathan Rosenberg wrote:
> > Folks,
> >
> > For some time, I've been complaining about the continued abuse of the
> > INFO method for things that should be done other ways (frequently, not
> > using sip at all). I've written up a summary of the problems and a
> > proposed path forward. Specifically, I'd like to obsolete INFO and
> > replace it with a spec that is approved ONLY for SIP-T.
> >
> > Until the I-D appears, you can pick up a version at:
> >
> > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt
> > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html
> 
> Jonathan and I have had "extended discussions" on this. I'm more
> inclined to think that INFO needs specifications for specific usages,
> much as we use "events packages" for SIP Events (SUBSCRIBE, NOTIFY). In
> my own completely non-original way, I call these "INFO Packages".
> 
> I think that the SIP-T usage of INFO is a perfect example of an INFO
> package. However, I think it is NOT the only reasonable use for INFO.
> Unsolicited in-dialog "stuff" is pretty darned useful. All we really
> need is for the usages to be differentiable, negotiable, and
> well-documented. Admittedly, INFO doesn't have any of those three
> characteristics right now, but I think we can probably fix it without
> breaking too much existing stuff.
> 
> Anybody else have a third opinion?
> 
> --
> Dean
> Not Speaking From The Chair.
> 
> _______________________________________________
> 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
_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Mon, 30 Dec 2002 14:45:39 -0500

First, I think it is a really good idea to restrict the applicability of SIP
INFO method - I very much agree with the problem defined in Section 2 of
this draft.

That much said, when it comes to solutions I am torn between option number 3
and a more radical alternative - deprecating INFO altogether. While it is
true that INFO was inspired by some of the requirements of SIP-T, over time,
we've found less and less use for INFO. The original vision for SIP+ (an
ancestor of SIP-T) relied on INFO for sending virtually every ISUP message,
but today, there just isn't that much that we do with INFO. Practically
speaking, we could probably find alternatives to INFO for carrying ISUP data
in these cases (which include SUS/RES, INF/INR, some provisional response
cases). Using INFO to send other ISUP messages is frequently misguided, and
can potentially lead to the same sorts of interoperability problems we have
with INFO in other arenas. 

Today, however, RFC3398 does allow the use of INFO in these three cases, so
it's simplest to let the INFO method to exist (option 3) for the time being
- but we should be sure to document, even for ISUP transmissions, the cases
in which it is and is not appropriate. In the long term, though, I think we
should just get rid of it entirely.

Jon Peterson
NeuStar, Inc.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, December 26, 2002 12:12 PM
> To: [email-masked]
> Subject: [Sip] INFO considered harmful
> 
> 
> Folks,
> 
> Thanks,
> 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: "George Foti (LMC)" <[email-masked]>
Date: Tue, 31 Dec 2002 14:23:43 -0500

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:[email-masked]]
Sent: Monday, December 30, 2002 4:50 PM
To: Dean Willis
Cc: [email-masked]
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.