> -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Thursday, October 04, 2007 10:56 AM > To: Dean Willis > Cc: IETF SIP List > Subject: RE: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > There is a missing point in here. > > When you say "new uses of INFO are not being accepted by the > IETF for the following reasons", the problem is that people > are overstating their case when discussing the "reasons". > This in turn is annoying people who find the "reasons" not > technically accurate. > > I'd rather we try to avoid "inventing" reasons and getting > into silly long arguments.
Yes, exactly. > > We could say something very simple in that draft. Something > like, INFO was created as a general transport mechanism in > SIP. As SIP evolved, new mechanisms for different usages were > created (then we can list them, and give KPML as an example > for keypress). And then just say that new usages beyond the > existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated. > > And leave it to that. I personally would support such a document. > > Any attempt at inventing complex reasons will just encourage > people to find flaws in the arguments. People like me. I'd rather there be no reason than a bad reason. Bad reasons tend to get exploited and extended to other support further bad ideas/reasons down the road. > > But, again, I'm happy with the status quo. > > > 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 > _______________________________________________ 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
