On Oct 2, 2007, at 4:49 PM, Francois Audet wrote:
IETF is certainly not going to come up with new INFO usages. Everytime somebody shows up with an INFO idea, he's promptly turned away. So, what is the "problem" that we are trying to solve? Why are we wasting time on this?
To paraphrase my friends at the 12-step program, the first step to fixing a problem is to admit that you have more than one problem and decide which one you're working on right now.
I was happy with the status-quo. But here's the main problem as I understand it:
People keep either showing up with INFO uses or just inventing them in the wild and propagating them until somebody ELSE shows up at IETF with a "de facto standard" usage of INFO that we have to turn away, thereby wasting our time and theirs, and hurting many people's delicate feelings in the process.
If we had an RFC that said "New uses of INFO are not being accepted by the IETF for the following reasons, please use something else (like an event package) instead" then people might be less tempted to use INFO, or at least to bring it to the IETF.
I think we have a consensus on this point. We have some debate on whether it's worth developing such an RFC, but I think everybody understands this path.
However, there's a second problem, and people keep getting these two problems confused (or at least thinking we are discussing the first problem when we're really discussing the second) hence we go around in a circle.
The second problem is "People are using INFO because it has certain advantages that make it more attractive than a new event package for some applications. If we fixed the problems with INFO negotiation without losing these advantages, the community would benefit greatly as a result."
This is the problem whose threads contain things like "KPML is a much less efficient mechanism for driving telephone applications that use DTMF than DTMF over INFO".
So, there are at least TWO PROBLEMS. Why don't we have at least two solutions?
Perhaps we could document the flaws with INFO's design and explain, as a BCP, why we don't recommend using it and why IETF should not proceed with new usages of INFO as long as those flaws persist.
This would not preclude a second standards-track effort (if we wish to pursue it) to fix INFO, or replace it with a new in-dialog contextually negotiated content transfer mechanism.
It would also not preclude standards-track efforts to replace individual INFO usages with new SIP methods (if we wish to pursue them). For example, there's no reason why we couldn't replace ISUP- over-INFO with a new SIP method "ISUP", TSIG over INFO with a new SIP method "TSIG", DTMF-over-INFO with a new SIP method "DTMF", and so on.
This gets back to my rant some months ago about the SIP community not having consensus on one extension methodology, thereby giving us multiple extension methodologies that compete (and possibly conflict) with each other. We don't agree whether SIP is an application protocol or a transport protocol, so we've made it into both at the same time. It's about time we grapple with this issue and establish a practice going forward.
-- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
