Subject: [Sip] INFO and what to do about it

From: Dean Willis <[email-masked]>
Date: Wed, 25 Jul 2007 13:51:00 -0500

We have a clear consensus in the WG that "something needs to be done  
about INFO."

In this week's SIP meeting, we discussed a draft by Eric Burger that  
proposes formally restricting the usage of INFO to the existing RFCs  
that exercise it.

Several people noted that just making this limitation in a void is  
insufficient -- that we also need to explain the fundamental  
architectural problem and give guidance on how to more effectively  
solve the kinds of problems that people have been trying to solve  
using INFO.

We also have a contingent that thinks that we should fix info by  
adding a negotiation mechanism and registration procedure for INFO  
usages, much as SIP events have been done.

Others think that rather than an extensible mechanism using one  
message type (INFO), we should instead extend SIP as needed with new  
message types, further blurring the line between protocol and  
application (which I'll admit is already pretty blurry in SIP's  
case). Note that this is a follow-on mechanism to the first step of  
documenting NOT using INFO.

It seems to me that this means we need to clarify the SIP extension  
model, which I'll come back to later.

At this week's meeting, there was a majority (at least a 2 to 1  
ratio, and more by some counts) in favor of taking the path of Eric's  
draft and declaring a formal moratorium on new usages of INFO. This  
is pretty close to "rough consensus", but not so close that I was  
willing to declare consensus without taking the question to the list.

So here's a proposal:

I suggest we accept the model of Eric's draft, but ask him to add  
more depth to the architectural discussion and ask Christer to  
contribute some text in this direction, as he has some very definite  
ideas of what needs to be addressed. This leaves us with clear  
direction on not extending INFO with new usages or a negotiation  
mechanism.

Please discuss this on-list, especially if you object or have a  
counter-proposal.

This leaves open the question of clarifying the extension model of  
SIP, which I will raise in another thread to make following the  
discussion easier.

--
Dean Willis
SIP co-chair

_______________________________________________
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