Subject: RE: [Sip] INFO considered harmful

From: "George Foti (LMC)" <[email-masked]>
Date: Thu, 2 Jan 2003 17:02:52 -0500

>There is no reason to bother all the
>routing proxies in the network with your e2e private chatter.

How are they bothered ?
What extra logic do they need?

/gf

-----Original Message-----
From: Don Stanwyck [mailto:[email-masked]]
Sent: Thursday, January 02, 2003 3:13 PM
To: 'George Foti (LMC)'; 'Michael Thomas'; 'Eric Burger'
Cc: 'Dean Willis'; 'Jonathan Rosenberg'; [email-masked]
Subject: RE: [Sip] INFO considered harmful

I guess I have two problems with the statement below.

1) Applications should not be protocol based - they may be protocol
aware.  Unless the SIP stack is rolled into the application, it merely
uses SIP as a lower layer tool to establish communications.  It is a
violation of good design to roll the protocol into the application
itself.
   BTW, if the SIP stack is rolled into the application, then when the
next edition of SIP comes along you will have to rewrite the app.  You
really should have an API that keeps the app from needing to know the
details of the communication establishment protocol.

2) If the apps need to talk directly to each other there are a host of
protocols that are extremely trivial that can do the job.  The apps can
even just open a port over any transport protocol and exchange
information as they please.  There is no reason to bother all the
routing proxies in the network with your e2e private chatter.

Just a thought.
don

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Foti (LMC)
> Sent: Thursday, January 02, 2003 11:55 AM
> 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

---

From: "Don Stanwyck" <[email-masked]>
Date: Thu, 2 Jan 2003 16:02:05 -0700

It increases the number of transactions they have to process.  Nothing
in life is free.  SIP Proxies, like other call routing devices, assume a
certain number of transactions per call as part of their design numbers.
This is important for traffic engineering.

If we allow SIP to become the new FTP protocol (and there is nothing
right now that would stop a UA from using SIP-INFO for FTP or FTP like
functions), then the calls/second counts and all other traffic
engineering rules that are needed for proper network operation become
meaningless.

Don

> Sent: Thursday, January 02, 2003 3:03 PM
> To: 'Don Stanwyck'; George Foti (LMC); 'Michael Thomas'; 'Eric Burger'
> 1) Applications should not be protocol based - they may be 
> protocol aware.  Unless the SIP stack is rolled into the 
> application, it merely uses SIP as a lower layer tool to 
> establish communications.  It is a violation of good design 
> to roll the protocol into the application itself.
>    BTW, if the SIP stack is rolled into the application, then 
> when the next edition of SIP comes along you will have to 
> rewrite the app.  You really should have an API that keeps 
> the app from needing to know the details of the communication 
> establishment protocol.
> 
> 2) If the apps need to talk directly to each other there are 
> a host of protocols that are extremely trivial that can do 
> the job.  The apps can even just open a port over any 
> transport protocol and exchange information as they please.  
> There is no reason to bother all the routing proxies in the 
> network with your e2e private chatter.
> 
> Just a thought.
> don
> 
> > the application of sip