So, what is missing, or what should be taken out, of draft-burger-sip-info? I think what you propose is what the document says. Help me out here!
On 10/4/07 11:56 AM, "Audet, Francois (SC100:3055)" <[EMAIL PROTECTED]> wrote: > 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. > > 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. > > Any attempt at inventing complex reasons will just encourage people to > find flaws in the arguments. > > 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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
