Subject: RE: [Sip] INFO considered harmful

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 02 Jan 2003 15:33:04 -0500

I think that there is another way to phrase the issue which at least raises 
a fair question.
I have an application.  It uses SIP, and then (sometimes) establishes a 
media session.
However, none of those exchanges provide the IP address of the controlling 
remote application.

Hence, if one application control entity wants to send (or receive) 
information to (from) the other application control entity, the only 
clearly available path is through SIP messages.  Preferably SIP messages 
tied to the existing session.
Presumably, one could mandate a single header for carrying a "control 
entity IP address / port / protocol" but that seems pretty silly.

Yours,
Joel M. Halpern

At 01:35 PM 1/2/2003 -0600, Adam Roach wrote:
>The argument of "but I'm already holding a hammer and *want*
>to treat everything like a nail!" comes up on about an annual
>basis, and is rejected outright each time.
>
>Just because you have a SIP stack in your application does
>*not* mean that it is appropriate to use that stack for
>all general network access. You're allowing laziness to
>overwhelm good application design.
>
>/a
>
> > -----Original Message-----
> > From: George Foti (LMC) [mailto:[email-masked]]
> > Sent: Thursday, January 02, 2003 12:55
> > To: 'Michael Thomas'; Eric Burger
> > Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
> > Subject: RE: [Sip] INFO considered harmful
> >
> >
> > The application is SIP based, we dont need yet another
> > protocol to convey what needs to be conveyed e2e.
> > No need to go around the bush.
> > Lets find *real* arguments against using INFO for that
> > purpopse rather than philosphical  ones.
> >
> > /gf
> >
> >
> >
> >
> > -----Original Message-----
> > From: Michael Thomas [mailto:[email-masked]]
> > Sent: Thursday, January 02, 2003 12:53 PM
> > To: Eric Burger
> > Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
> > Subject: RE: [Sip] INFO considered harmful
> >
> >
> >
> > I don't get it. If you want "100% application
> > specific", why not pick an unused port and roll
> > your own protocol? Then all of the crufty SIPism
> > don't get in the way, and the hue and cry from
> > this working group ceases immediately. Do the bits
> > on the wire keep warmer if they're dressed in SIP?
> >
> >        Mike
> >
> > Eric Burger writes:
> >  > I fully agree with Dean on this one.
> >  >
> >  > One point to consider (I'm on the fence on this one) is
> > whether we would say that INFO is 100% application-specific.
> > That is, the WG will not publish standard body types.
> >  >
> >  > A reason for doing that is to let people know that INFO
> > really is just, as Dean points out,
> > application-to-application communication.  If you want
> > applications to interoperate, take it either to an
> > Application Area WG or take it outside the IETF.
> >  >
> >  > One reason to not do this is SIP-T should use a method
> > other than INFO.  That said, I don't think there are that
> > many SIP-T implementations extant.
> >  >
> >  >
> >  > > -----Original Message-----
> >  > > From: Dean Willis [mailto:[email-masked]]
> >  > > Sent: Tuesday, December 31, 2002 1:48 AM
> >  > > To: Jonathan Rosenberg; Orit Levin
> >  > > Cc: [email-masked]
> >  > > Subject: Re: [Sip] INFO considered harmful
> >  > >
> >  > >
> >  > > 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". 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
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > 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
> > _______________________________________________
> > 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
> >
>_______________________________________________
>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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Jan 2003 15:45:30 -0500

Joel,

I am not entirely sure I follow you here. As I started reading, I 
thought you were proposing what I do believe is the right answer here.

If people want to exchange proprietary data between applications that 
are set up using sip, we have a way to do that. This application data 
can just be considered another session type (along with audio and video) 
which SIP can set up and manage for you. So, roll your own protocol 
(say, foo) that does just what you want, and then use SDP to exchange 
the IP/ports and protocol identification infomration needed to make it work.

This way, proxies don't see any of it, and SIP is not being abused in 
any way.

-Jonathan R.

Joel M. Halpern wrote:
> I think that there is another way to phrase the issue which at least 
> raises a fair question.
> However, none of those exchanges provide the IP address of the 
> controlling remote application.
> 

-- 
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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 02 Jan 2003 15:56:53 -0500

Using an SDP extension to set up the control entity communication path 
would be reasonable.  My point is that simply saying "the applications can 
already communicate" (as some respondents on the list have said) is not 
true, as the normal usage does not permit the entities to communicate.
If the communication is going to be extended, it would seem that the SDP 
based approach is correct.
However, it would seem sensible to have a method to carry smaller pieces of 
information.
This could possible be done with alternative content, or with extended 
headers.  In either case, it would be for the low rate communication that 
would not warrant and SDP exchange to establish the session.  Obviously, 
this is a slippery slope.  We do not want to turn the control plane into a 
generic communication channel.  (I've been there, and been unhappy doing that.)

Yours,
Joel

At 03:45 PM 1/2/2003 -0500, Jonathan Rosenberg wrote:
>Joel,
>
>I am not entirely sure I follow you here. As I started reading, I thought 
>you were proposing what I do believe is the right answer here.
>
>If people want to exchange proprietary data between applications that are 
>set up using sip, we have a way to do that. This application data can just 
>be considered another session type (along with audio and video) which SIP 
>can set up and manage for you. So, roll your own protocol (say, foo) that 
>does just what you want, and then use SDP to exchange the IP/ports and 
>protocol identification infomration needed to make it work.
>
>This way, proxies don't see any of it, and SIP is not being abused in any way.
>
>-Jonathan R.
>
>Joel M. Halpern wrote: