Subject: RE: [Sip] INFO considered harmful

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jan 2003 16:56:30 -0600

A new method would be okay for new SIP-related functionality.

But that's not what you proposed.

You said, "The application is SIP based, we dont need yet
another protocol to convey what needs to be conveyed e2e,"
which is an argument that we should use SIP as a general
purpose RPC mechanism for any application that already has
a SIP stack.

Doing what you propose with INFO is inappropriate.

Doing what you propose with a new method is inappropriate.

Doing what you propose with SIP is inappropriate.

Since you keep harping on technical, as opposed to
philosophical, arguments, here's a couple:

  - The SIP protocol was designed for session initiation,
    negotiation, and teardown. The timing characteristics
    are not generally appropriate for application control.
    For example, with typical SIP networks, latency and
    jitter of messages are too high to provide any sort
    of reasonable user experience for floor control
    or DTMF transport.

 - Many proxies stay in the signalling path for the purposes
   of providing services. By sending unnecessary application-
   level information throught these proxies, you reduce the
   capacity and increase possible congestion of the network.

I could go on, but this topic has had extensive airing on
the list in years past. There's really no reason to beat
this particular dead horse any longer.

/a

> -----Original Message-----
> From: George Foti (LMC) [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 16:05
> To: 'Adam Roach'; George Foti (LMC); 'Michael Thomas'; Eric Burger
> Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
> Subject: RE: [Sip] INFO considered harmful
> 
> 
> This should not be a philosophical discusion.
> If a new SIP method is okay, why is INFO not okay.
> 
> What is the difference?
> Please explain in technical terms?
> 
> /gf
> 
> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 2:36 PM
> To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger
> Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
> Subject: RE: [Sip] INFO considered harmful
> 
> 
> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 2 Jan 2003 15:56:09 -0800 (PST)

Right, but my personal bugaboo is modularity.
Like Don's FTPoSIP example, the more junk you
throw into one protocol, the more entangled it
becomes to the point that you have a deep dark
morass. In any case, we already have a real live
kitchen sink protocol: HTTP; you even run IP over
HTTP these days. I'd be surprised to hear that
just about anything that runs SIP doesn't also
have web kruft in it as well.

	 Mike

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 03 Jan 2003 08:19:37 -0500

I have nothing substantive to contribute to this discussion, except to 
observe that among my silly "Oran's laws of protocols", about five years 
ago I coined the following law:

"any application protocol which works sufficiently well to be widely 
deployed eventually gets hijacked and used as a transport protocol"

The fact that we are having this discussion is a testament to the success 
of SIP. History also seems to tell us that we may be fighting a losing 
battle in attempting to ban INFO and friends.

Happy New Year, to the whole SI community.

Dave.

--On Thursday, January 02, 2003 3:56 PM -0800 Michael Thomas 
<[email-masked]> wrote:

>  > > >  > Use [email-masked] for questions on current
> sip  > > >  > Use [email-masked] for new developments on the
>  > > application of sip

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 11:20:50 -0500

> deployed eventually gets hijacked and used as a transport protocol"

Definitely true.

Please do enumerate the others... would make a nice I-D I think.

-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: Michael Thomas <[email-masked]>
Date: Fri, 3 Jan 2003 08:30:59 -0800 (PST)

> Please do enumerate the others... would make a nice I-D I think.

   I don't think anybody should be under the
   illusion that SIP won't be misused. What's at
   issue here specifically is whether the WG
   actually sanctions a free for all. One distinct 
   downside is that there may actually be some
   gems that ought to be salvaged from the fetid
   swamp, but that will be extremely difficult if
   they work well enough. It just seems like a 
   poor idea and precedent.

	     Mike

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 3 Jan 2003 15:37:29 -0600

Adam said:
> purpose RPC mechanism for any application that already has a 
> SIP stack.
> 

The key point is that we already have two applications talking to each other
on a SIP dialog. The SIP intermediaries are providing the routing function
between those applications. The ONLY routing knowledge those applications
have about each other is that expressed in the SIP channel. Therefore, the
existing SIP dialog makes an awfully handy mechanism for exchanging data
between those two aplications.

--
Dean

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 03 Jan 2003 17:18:13 -0600

>would make a nice I-D I think.

This whole discussion would make a very USEFUL I-D. Anyone contemplating
to do the work?

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Friday, January 03, 2003 10:21 AM
> To: David R. Oran
> Cc: Michael Thomas; Adam Roach; 'George Foti (LMC)'; Eric 
> Burger; Dean Willis; [email-masked]
> sip Use [email-masked] for new developments on the 
> application of sip
>