RE: [Sip] INFO considered harmful

[Michael Thomas <mat@cisco.com>]

Dean Willis writes:
 > Mike asked:
 > > 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?
 > 
 > 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,

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
_______________________________________________
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