Subject: RE: [Sip] INFO considered harmful

From: "Eric Burger" <[email-masked]>
Date: Thu, 2 Jan 2003 12:34:37 -0500

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

---

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

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

---

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

> on the wire keep warmer if they're dressed in SIP?

Not only do they keep warmer, but they get to take advantage of all those
nifty SIP functions, like rendezvous, delivery delegation, security, and
MOST IMPORTANTLY, name-space correlation with the application naming
provided by SIP. In short, all of the same reasons why PUBLISH-type methods
kep getting suggested.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Fri, 3 Jan 2003 14:02:01 -0800 (PST)

> provided by SIP. In short, all of the same reasons why PUBLISH-type methods

Dean,

It's patently obvious _why_ people want to do this
not unlike Mallory and Everest ("because it's
there!"). The question is whether it's a Good
Idea. The thing that squicks me is the anything
goes attitude parading around as "application
data". Well, SIP is already chock full of various
bits and pieces of "application data" and they
have well defined syntax and semantics. Why is it
OK to have INFO bits which are completely
unspecified but all the rest are well specified?
It's just inviting interoperability problems and
ad hoc standards making. Now I have no doubt that
this is going to happen no matter what, but it
doesn't mean that IETF needs to build and maintain
its kitty litter box.

Others have brought up SMS as an example. In fact,
I think that SMS argues *exactly* the opposite:
that sort of functionality needs to be very well
specified so that interoperablity is achieved.
Leaving it up to individual vendors, or providers
or whatever would be a huge mess. For less
interesting things... well, proprietary methods,
X-blahblahblah's and all of the rest can be hacked
up without any help whatsoever from IETF. If they
become interesting, we can then standardize them.
What I just don't see any value to is an
officially sanctioned free for all. What purpose
does it serve other than people getting to point
to a nice shiny RFC number for their proprietary
extensions?

		Mike