[Sip] INFO *is* Harmful; The Alternatives *are* Worse

["Eric Burger" <eburger@snowshore.com>]

Speaking as an acknowledged INFO abuser (step 1 of the 12-step program?)...

Dean hit the nail on the head:

> -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]
> > [snip] What does INFO give you beyond that?
> 
> The ability to define a new usage without having to make code 
> changes to one's SIP stack, just as Events allows.

What are my options when I want to *try* something new in the SIP world.  I can:

1. Write an I-D, hoping to get an RFC published, before I have any road-time or clue how my idea will work in the real-world.

2. Hack my own method into my own infrastructure, and hope I never go outside my lab or tangentially interoperate with other SIP services.  [N.B.: If those other SIP services needed to be aware of my change, they would be aware of my change BY DEFINITION.]

3. Hack my own APPLICATION payload onto a generic TRANSPORT mechanism that is well-known by the rest of the infrastructure.

I'm open for Option 4...


What we need is some way to do experiments without breaking stuff or having to hack everything.



I am firmly on the record that option 1 is EVIL.  IMHO it is a waste of resources to toss out ideas hoping to see what sticks.  There needs to be a way of trying stuff out without burning WG cycles.  Stuff doesn't need to be fully baked (in fact, it shouldn't be fully baked so when the WG sees the inevitable fatal flaw, no one is too upset to change).  However, stuff should have seen the light of the real world to both work out the obvious "oh no's!" and the not so obvious "it should work, but it doesn't!".

Option 2 is just a non-starter.

I can speak to Option 3 from personal experience.  We used INFO for information reporting from media servers.  Is that the right answer today?  No, of course not.  NOTIFY is the right answer.  However, NOTIFY didn't exist.  More to the point, we have a lot of road-time on what does work, and what doesn't (e.g., HTTP does NOT work for everyone, re-INVITE takes too long and the dialog *isn't* changing, etc.).

Now that we have real-world experience, we are in a position to publish the I-D, including using "modern" techniques, and go forward through the WG gauntlet.  


What is your proposal without INFO?


Now my turn for a bit of soap-boxing:

I absolutely, positively consider the statement that the use of INFO results in a lack of interoperability to be totally irrelevant.  I posit this for two reasons.  The first is that all of the "extensions" offered in "The Session Initiation Protocol (SIP) INFO Method Considered Harmful" as creating non-interoperable extensions actually were proposals to ENSURE INTEROPERABLE extensions.  One cannot say, "using INFO is not interoperable" at the same time one says, "we will not allow anyone to define interoperable uses of INFO."  That is like saying, "Only people that have sea duty can become an admiral, but you will never be allowed to have sea duty."

One escape for that line of thinking is Dean's proposal for INFO packages.  The problem here is that proposal would cast experiments in stone, like X-INFO.  That smells like SOAP over SIP.

The second reason I consider the statement of non-interoperability to be irrelevant is if one looks at two of the cited usages, "DTMF digits" and "media servers", *only* the client and the server are even AWARE of the capabilities.  THERE IS NO THIRD PARTY THAT NEEDS TO NEGOTIATE THE CAPABILITY, EITHER "IN" OR "OUT".  BY DEFINITION, THERE IS NO INTEROPERABILITY ISSUE.  Why?  Because the drafts describe how to interoperate, and messages will only ever originate and terminate at "aware" devices.

Again, and I'm sure I'll have to point out this paragraph when people flame about the last paragraph, I see the use of INFO for experimental stuff.  After the experiment is done, I will lay wagers that one of the following outcomes will occur.

  1.  What's being tried is really useful and fits into the SIP
      Framework.  Very likely to be a new method.

  2.  What's being tried is really useful and something else
      already covers it, e.g., NOTIFY for digit reporting.

  3.  What's being tried is really useful but isn't SIP, e.g.,
      bulk transfer of data, which is what FTP and HTTP are for.

  4.  What's being tried just doesn't work.  Don't waste WG
      time on it.

In fact, I would be one of the first to jump up and say "Whoa" when someone publishes a "we want to use INFO for..." I-D's.  Why?  Because one of the above 4 items really end up being the right answer.  As hgs says, we have an infinite method namespace.

On the other hand, let's say you don't want to use an infinite method namespace.  In that case, I would put my weight behind Dean's suggestion to have INFO packages.  Otherwise, and great apologies to Adam, but Christer is 100% correct.  Banning INFO will move the problem to MESSAGE, INVITE, and UPDATE.  We even saw a proposal to use SUBSCRIBE to change the state of the UAS as a way to "work around" the "INFO problem."  Let's not make things worse!
_______________________________________________
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