[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:George.Foti@ericsson.ca]
> Sent: Thursday, January 02, 2003 12:55
> To: 'Michael Thomas'; Eric Burger
> Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org
> 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:mat@cisco.com]
> Sent: Thursday, January 02, 2003 12:53 PM
> To: Eric Burger
> Cc: Dean Willis; Jonathan Rosenberg; sip@ietf.org
> 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:dean.willis@softarmor.com]
> > > Sent: Tuesday, December 31, 2002 1:48 AM
> > > To: Jonathan Rosenberg; Orit Levin
> > > Cc: sip@ietf.org
> > > 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 sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip