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

From: "Eric Burger" <[email-masked]>
Date: Mon, 30 Dec 2002 17:29:55 -0500

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:[email-masked]]
> > [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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Dec 2002 18:27:17 -0500

I don't see the major problem of defining new methods. There seem to be 
two issues: programming and naming.

I believe that modern stacks, like those based on the JAIN SIP API, have 
no problems dealing with new methods. (Somebody who has more day-to-day 
experience with this should confirm this...)

Stack writers (for UA stacks) need to get used to the idea that new 
methods come along, so they should make it easy to register support for 
new (non-INVITE) methods. After all, this is pretty much just a table 
lookup.

In terms of naming, there are at least two sensible approaches:

- If you believe that the method may at some point be more generally 
applicable, give it a regular-looking SIP method name. If it doesn't get 
standardized but is deployed on a proprietary basis, your only 'problem' 
is that you may need to monitor the WGs to protest should somebody pick 
that name for something different. I suspect nobody wants to cause 
completely unnecessary interop problems, given that there is no scarcity 
of names. (We could have solved this problem differently and less 
informally, with the aid of IANA, but I've said my piece on that.)

The best solution is clearly to not deploy stuff until there is some 
generally-agreed upon sense that this is stable. (Presumably, this means 
that it's past the IESG, at least.) Since that can take a few years, 
unless your affiliation reads 3GPP, this is asking a bit, but that's a 
different discussion...

- If you believe that this is strictly your own proprietary thing that 
you don't want to bother documenting for whatever reason, make up your 
own name, such as "SNOWSHORE-EXPLODE-TERMINAL". Again, I wish there was 
a better mechanism for this, but that's a different discussion. 
Obviously, interoperability isn't going to be in the cards, but at least 
it is very obvious and obvious immediately that this is a non-standard 
extension, with a very well-understood error message (501) and 
negotiation mechanism (Allow). (No need to peek deep inside some generic 
INFO message and try to figure out what error indication would fit and 
no need to invent another Allow-* mechanism.)

I'm not advocating the second approach; the INFO abuse seems to 
indicate, however, that the current approach leaves implementors short.

(I don't think the approach in 
draft-narten-iana-experimental-allocations-03.txt is particularly 
applicable here since it assumes scarcity and advocates re-use of a 
small number range, which we don't need or want. We really don't want to 
designate INFO1, INFO2, INFO3, ..., INFO63 here...)

Henning